Why was the negative z axis chosen as the axis the camera points down by default in OpenGL? If I want to move to the eyepoint to a specific location in the model, I have to negate both the x and z coordinates because of this view. Also math is all jacked up becuase of this. It just seems that everything would have been much simpler if they would have chosen the positive z axis. I'm considering reorienting my view to point down the positive z axis. There is the gluLookAt command, but it doesn't have the parameters necessary to create the frustum, so I guess that a call to gluLookAt must precede a call to glFrustum or gluPerspective? Would I do something like this: glMatrixMode(GL_PROJECTION); glLoadIdentity(); gluLookAt(0,0,0,0,0,1,0,1,0); gluPerspective(fovy, aspect, zNear, zFar); It seems that the math would be less cumbersome this way, but has anyone tried this? Is the grass really greener on that side? Are there problems that come by doing it this way that aren't present when looking down the negative z? Thanks for any help!

Quote:
Why was the negative z axis chosen as the axis the camera points down by default in OpenGL? If I want to move to the eyepoint to a specific location in the model, I have to negate both the x and z coordinates because of this view. Also math is all jacked up becuase of this. It just seems that everything would have been much simpler if they would have chosen the positive z axis.

It's just a choice they made. It cannot be a 'right' or 'wrong' choice in general, it can only differ from choices made in other graphics systems. The choice is unfortunate for you perhaps, since apparently you are used to a system using the positive z-axis.

Quote:
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluLookAt(0,0,0,0,0,1,0,1,0);
gluPerspective(fovy, aspect, zNear, zFar);

gluLookAt creates a 'view'-matrix and should not be called on the projection matrix stack but on the modelview stack. To clear up the matrix stuff for you, I copy paste some text I posted in a different thread a few days ago...

Quote:Shameless self-quote
Traditionally the graphics pipeline uses three separate matrices for transforming a point from object coordinate system (vertices of an object are normally defined around a local coordinate system) to 2D screen coordinate system:

point_in_obj_coords * model_matrix -> point_in_world_coords
The model matrix is object specific. It transforms each vertex to world space. If your object is a car, the matrix will contain the position and orientation of the car in the world.

point_in_world_coords * view_matrix -> point_in_camera_coords
The view matrix depends on the position and orientation of your camera. It transforms points in world coordinate system to camera coordinate system. The matrix contains the translation and rotations of the camera but inversed.

point_in_camera_coords * projection_matrix -> point_in_screen_coords
The projection matrix depends on the properties of the camera (orthogonal or perspective projection) and defines the viewing volume. I'm not going to explain what's in it, glFrustum/glOrtho will do that for you. Or you can read it here.

OpenGL combines the model and view matrices in the modelview matrix. That's why the view matrix should always be the first thing to load on the modelview stack as the order in which the matrices are applied is crucial.

Tom

EDIT:
On the actual problem: if I remember correctly, I believe you can reverse camera direction by calling glScalef(1,1,-1) after setting up the view matrix.

[Edited by - dimebolt on August 31, 2005 10:46:24 AM]

Once you map +x to right and +y to up in view space (the standard convention), the handedness of the coordinate system dictates whether + or - z is forward. I'm not sure historically why OpenGL went with RH, although I believe RH is standard in most (perhaps) all other fields other than graphics.

I agree that it's a pain to think of -z as forward in model/world space. To counter this, I treat my camera as a regular object with +z forward. After the view transform, the 'visible' part of the world is on the +z side, with +x left rather than right. As a final step, I apply a 180-degree y rotation, which puts everything where OpenGL expects it to be.

You can make your own LH lookat and projection matrices if you wish. It may even be that by loading your own matrices and setting the winding appropriately, you can make OpenGL left-handed. Although this is on my list of things to try, I haven't done it yet and so don't know for sure that this would work.