Quote:the man page for glOrtho seems to hint that you should pass near and far as negatives, or in your example near as 1, far as -1 which would result in the identity matrix |

Hm, I don't read it that way. It says, 'These values are negative if the plane is to be behind the viewer', which I take to mean that negative values (e.g. -1) correspond to planes that are behind the viewer. Therefore, a near value of -1 and a far value of 1 would make sense.

Also,

`gluOrtho2D()` sets 'near' to -1 and 'far' to 1, so I think it's pretty safe to say that negative distances are intended to be behind the viewer and positive distances in front.

Quote:Anyway, there is a solution to settle this, implement what szecs suggested, that is set projection to identity, make no mirror transformations or negative scales in modelview draw the axes at the origin with 0.1 lengths and see in which direction z points when y is up and x is right, that's it. |

This isn't quite the same thing, but I put together the following little test program:

#include "SDL.h"

#include "SDL_opengl.h"

int main(int, char*[])

{

SDL_Init(SDL_INIT_EVERYTHING);

SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 16);

SDL_SetVideoMode(400, 400, 0, SDL_OPENGL);

glEnable(GL_DEPTH_TEST);

bool quit = false;

while (!quit) {

SDL_Event event;

while (SDL_PollEvent(&event)) {

if (event.type == SDL_QUIT) {

quit = true;

}

}

glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

glColor3f(1, 0, 0);

glBegin(GL_TRIANGLES);

glVertex3f(-.75, .25, .5); glVertex3f(.75, 0, .5); glVertex3f(-.75, -.25, .5);

glColor3f(0, 1, 0);

glVertex3f(-.25, -.75, .75); glVertex3f(0, .75, .75); glVertex3f(.25, -.75, .75);

glEnd();

SDL_GL_SwapBuffers();

}

SDL_Quit();

return 0;

}

All transforms are left at identity. A red triangle is drawn at z = .5, and a green triangle is drawn at z = .75. Here's the output:

Note that the red triangle is in front of the green one, which would seem to suggest that z is increasing away from the viewer. In other words, the coordinate system in this example is left-handed.

So, that's the empirical (assuming the example isn't flawed in some way), but let's go ahead and look at the theoretical.

In OpenGL, normalized device coordinates are left-handed. Obviously just because it says so on the internet somewhere doesn't make it true, but for what it's worth, it's stated

here that the NDCS is left-handed.

Now, if all transforms are left at identity, after the projection transform, all vertices will have a w value of 1; therefore, the division by w can be disregarded.

What we are left with is that all vertices are passed unchanged (except for clipping) to NDC space, which is left-handed. So if anything, it seems to me that if OpenGL has an 'inherent handedness', it would be

*left-*handed, not right-handed.

So why is OpenGL said to be right-handed? The only reasons I can think of right now are that front faces are CCW by default in OpenGL (it has to be one or the other, after all), and that the convenience functions for which handedness matters (

`gluLookAt`,

`glFrustum`, etc.) build right-handed transforms.

As for Direct3D, the only reason I can think of for it being considered left-handed is that front faces are CW by default. Again though, if there's going to be a default, it has to be one or the other.

So for now at least, I'm going to stick with my assertion that aside from minor details such as default winding order (which are more or less incidental), neither API is any more right- or left-handed than the other. In fact, if one were forced to assign a 'default' handedness to each, it seems that they should both be considered left-handed, since if all transforms are left at identity, the geometry ends up in a left-handed coordinate system.

That said, I'm ready to be proven wrong (maybe one of our resident graphics gurus will step in and put this whole thing to rest).