I’ve been trying to decode the meaning of the “up” vector in the gluLookAt() but I seem to be getting nowhere
If I understand this right, by specifying the three vectors as input arguments for the gluLookAt, one defines the camera coordinate system’s location and orientation, so the first vector is the coordinate system centre, the second vector is the view direction which is basically the camera c. sys. z-axis direction, and the third one is the “up” vector, which locks the angle at which the camera is tilted when looking in the view direction. Can this third vector be interpreted as the y-axis of the camera’s c. system?
It seems intuitive but the problem is that from the Redbook example I studied I found that the view direction vector and up vector are not necessairily perpendicular, which ruins my theory about the up vector and the y-axis…
Apologies for the length… Does anyone have a more intuitive explanation about the connection between the up vector and camera’s coordinate system?
Originally posted by Spela:
[b]Can this third vector be interpreted as the y-axis of the camera’s c. system?
It seems intuitive but the problem is that from the Redbook example I studied I found that the view direction vector and up vector are not necessairily perpendicular, which ruins my theory about the up vector and the y-axis…
[/b]
You are correct when you say that the up-vector is the Y-axis of the camera. It is the direction, in world space, the camera’s up is.
However, as you say, the up-vector need not be perpendicular to the view vector, and that can be confusing. The reason is that the up-vector is not really the final up-vector.
Behind the scene, gluLookAt calculates a right-vector (or left, doesn’t really matter), a vector similar to the up-vector but pointing to the right. That vector is calculated by the cross product of the front- and up-vector, and thus will be perpendicular to the front-vector. Using that right-vector, again using the cross product, the final up-vector is calulated. Now you have three orthogonal vectors; front, right and up.
You can think of this in another way. If you only specify position and look-at target, the transformation matrix is not fully defined as the camera can rotate about it’s front axis and still meet the requirements of position and look-at target. The rotation for which the true up-vector is closest to the specified up-vector is the final transformation.
That way you can specify a non-perpendicular up-vector, as gluLookAt will make the true up-vector as close as possible to the specified up-vector.
I have a better idea now. If the final up vector will be the perpendicular one at the end, why is one allowed to use a non-perpendicular one anyway? Is it for the reasons of speed etc. or just to make things more convenient?
Is it possible to have a look at the OpenGL source code? E.g., if I wanted to see for myself how gluLookAt works, can I find the implementation anywhere? As far as I could see the installation on our system contains only .h and .so files (I am working in Linux).
You can use a non-perpendicular up-vector because the final result is still well defined. You tell gluLookAt where you want the up-vector, and gluLookAt makes its best to make it point in that direction.
If it was required to be perpendicular to the front-vector what should happen when it isn’t? Should it return without modifying any matrices, or should it modify it anyway, resulting in a non-orthogonal transformation? What tests should be made to make sure it is perpendicular? Floating-point arithmetics are not exact and round-off errors are always there due to limited precision. So even though you make your best to pass a perpendicular up-vector, the test may still fail (and probably will in most cases for any non-trivial case) because some tiny error got into the calculation, either on your side or in gluLookAt. Should a tolerance be used to protect from rounding errors, and if so, of what magnitude?
It just isn’t practical to require the up-vector to be perpendicular, especially since the result is well defined anyway. And if the current behaviour isn’t the one you want, it’s always possible to write your own.
As for the source, you can download Mesa . It’s an open source implementation of OpenGL, and it comes with a GLU implementation aswell, so you can find gluLookAt there.
OK. So in other words the best solution for the specification of the up vector is the closest vector in the desired direction (lying in the plane which has the future right vector for a normal) that can be described by e.g. integers and so avoiding the round-off errors at the input already (instead of trying to compute the exact perpendicular vector and coming up with coordinates that are too precise to always be interpreted in the same way)?
I am sorry if I am going on about this a bit too much
You don’t have to specify the up-vector as a vector with integer coordinates only and are as close as possible to the true up-vector. This would imply that you have the true up-vector to begin with (or you wouldn’t be able to find the closest vector with integer components), so just pass it directly to gluLookAt.
There are no precision issues (in practice) in gluLookAt, so you souldn’t care about round-off errors. The precision issues I talked about in my last post had to do with, assuming gluLookAt required a perpendicular vector, verifying the vector was perpendicular or not. But since that’s no the case, there are no precision issues.
I’ve been trying to decode the meaning of the “up” vector in the gluLookAt() but I seem to be getting nowhere
If I understand this right, by specifying the three vectors as input arguments for the gluLookAt, one defines the camera coordinate system’s location and orientation, so the first vector is the coordinate system centre, the second vector is the view direction which is basically the camera c. sys. z-axis direction, and the third one is the “up” vector, which locks the angle at which the camera is tilted when looking in the view direction. Can this third vector be interpreted as the y-axis of the camera’s c. system?
It seems intuitive but the problem is that from the Redbook example I studied I found that the view direction vector and up vector are not necessairily perpendicular, which ruins my theory about the up vector and the y-axis…
Apologies for the length… Does anyone have a more intuitive explanation about the connection between the up vector and camera’s coordinate system?
Thank you!
Spela[/b]
gluLookt doesn’t take 3 vectors. It takes 2 points in space and a vector.
The eye is where you are.
The view is a point in space the eye will be looking at.
These 2 define a view direction.
So for example your eye can be at 0, 0, 0
and you can look at a point at 0, 0, 1
or your I can be at 10, 20, 40
and you can look at 10, 20, 45
