I’m going through the Red Book and camera positions
have me confused??
other articles have said “it is impossible to move the camera in opengl”
in chapter 3 of the Redbook it talks about gluLookAt and the diagram clearly shows a picture of a camera that has been moved
so which is it, does the camera move or not?? 
thanks
the camera is a metaphor, it doesn’t actually exist. The opengl matrices transform the vertices, and thus the world. We tend to simulate moving a camera by doing the inverse transformations on the world. Funtions like gluLookAt simply make this transparent to the programmer. The distinction is unimportant for what the redbook is talking about, but it is important to understand what is actually happening.
Yep it is a metaphor, however people who say it is impossible to move the camera in OpenGL don’t understand OpenGL or at best aren’t being very helpful with their descriptions. OpenGL actually supports camera transformation very simply and easily with the modelview matrix and of course the fact that this matrix exists as a stack and things like lights and other more advanced features support transformation through this matrix.
The OpenGL modelview matrix holds as the viewing transformation and the model transformation concatenated, this is by far the most efficient way to implement 3D transformation.
Your viewing transformation is loaded onto the modelview matrix first. There is only a conceptual difference between moving the viewing matrix and the model matrix in OpenGL. Subsequent modeling transformations are multiplied with the modelview matrix.
glulookat is merely a utility function to easily compute a viewing matrix and load it onto the modelview matrix stack.
To further help you understand this consider the following:
Imagine the camera at the origin, the default position when the modelview matrix is loaded with an identity matrix. Now draw a unit cube in front of the viewer by sending appropriate vertex numbers. Next repeat drawing the cube scene but after you place a translate of 1.0, 0.0, 0.0 on the modelview matrix. Now look at the results. The cube will have moved to the right, but what actually happened? Did you move the cube to the right or did you move the eye to the left? The point is either scenario would be a fair description of the result. What you choose to call a transformation on the modelview stack it merely matter of application structure, it’s really up to you what you call that translation and how you push and pop the matrix stack.
This is important when you consider positioning light sources in world space for example, they are transformed through the modelview matrix to eye space so world space lights (and a few other things) should be positioned when the viewing matrix is on the modelview matrix stack. It is an important distinction but a relatively simple concept to understand.
Loading a viewing matrix onto the modelview stack then pushing the matrix and multiplying model transformations on the modelview stack and popping the modelview matrix stack back to the viewing matrix is how a camera transform is implemented in OpenGL. It is very simple, and it is very efficient.
From the perspective of openGL it is not the camera that movies, but the world moves around the camera.
Everything thing is openGL is it respect to the origin of 0,0,0. Rotations, translations, etc.
When you use gluLookAt you are not moving the camera, but the world as if the camera had been moved.
That is why you can not use things like glLoadidentity after useing your camera transformations, since it resets your view to 0,0,0. So you use glPush/PopMatrix, to keep you camera transforms from being effected by an objects transforms.
gluLookAt // Our camera view placed in the model view matrix.
glPushMatrix(); //Save matrix
glTranslate // Place object in space
glRotate
Draw_object()
glPopMatrix(); // Restore matrix with with gluLookAt camera settings
repeat for each new object
Originally posted by not_yet:
[b]I’m going through the Red Book and camera positions
have me confused??
other articles have said “it is impossible to move the camera in opengl”
in chapter 3 of the Redbook it talks about gluLookAt and the diagram clearly shows a picture of a camera that has been moved
so which is it, does the camera move or not??
thanks[/b]
Now I’m confused. I thought projection matrix tranforms were the best way to ‘move the camera’. This seems to work. Am I doing something wrong?
in general the only thing that should be done to the projection matrix is to set an orthagonal or perspective view. Transforming the projection matrix otherwise can screw up fog or lighting. That said there may be occasions where this is what you want to do, but if you are unsure you probably don’t have to.
thanks everyone
interesting reading
just to see if I’m on the right track let me run this by you
if I’m looking straight down the ‘y’ axis, ie: the ‘y’ axis is coming out of the screen
what I see are the ‘z’ and ‘x’ axis
the camera is located at the default 0,0,0 pointed in the neative ‘z’ direction
now I create a sphere at 0,0,5
to help me visualize whats going on, is it fair to say that to see the sphere the camera and grid system ie: ‘x’ and ‘z’ axis are “moved” as a unit such that I can see the sphere
so the camera never leaves 0,0,0 but the x/z axis to which the camera is “attached” is floated in such a way that the object can be seen
thanks
You guys have lost your mind! You can have big harry gorillas hurling giant fire-breathing coconuts on mars, and there is no camera sitting on a stand somewhere to view it all? This is simply a question of semantics, it’s how you choose to think about it - it’s all relative. Just like the “Up” vector, what the heck does that mean? Doesn’t mean much when you’re upside down… relative to what?
If there is no camera, then what is there? The camera is simply a point and a basis. The point can be anywhere in the world, just like anything else. The basis represents a rotation, just like any other rotation. The act of putting this information into a matrix does not make it any less real. All the matrix does is make the world relative to the camera, so that it is the center of the universe. I personally think it is far more intuitive to think of it this way.
Normally in openGL you have x/y axis as right/left and up/down, the z axis is you depth with -z moving into the monitor and z moving out from the monitor.
If you want to switch this to something like x/z with y requires you to rotate everything 90 degrees.
Let’s look at your sphere at 0,0,5, since the camera is at 0,0,0. The sphere is now located behind us, 5 units and can not be seen.
Note also we must have a X/Y projection set correctly to see the object also. For this the X/Y must be greater then 5/-5 x and 5/-5 y, for the sphere to be seen when rotated. also if your sphere is greater the 1 unit in diameter, you will need a z-depth greater then 1/-1 to view it correctly.
// Rotate everything on the y 90 degrees
glRotate(90, 0, 1, 0);
or
glLookAt(0,1,0,0,0,0,0,1,0) // set’s the view to
look at the x/z view.
glPushMatrix();
glTranslatef( 0.0, 0.0, 5.0);
Draw_sphere();
glPopMatrix();
Just remember that openGL works with transformations in reverse.
Here is what happens when we draw the sphere:
Originally posted by not_yet:
[b]thanks everyone
interesting reading
just to see if I’m on the right track let me run this by you
if I’m looking straight down the ‘y’ axis, ie: the ‘y’ axis is coming out of the screen
what I see are the ‘z’ and ‘x’ axis
the camera is located at the default 0,0,0 pointed in the neative ‘z’ direction
now I create a sphere at 0,0,5
to help me visualize whats going on, is it fair to say that to see the sphere the camera and grid system ie: ‘x’ and ‘z’ axis are “moved” as a unit such that I can see the sphere
so the camera never leaves 0,0,0 but the x/z axis to which the camera is “attached” is floated in such a way that the object can be seen
thanks