On 09/15/2011 03:01 PM, Mik Wells wrote:
This isn't quite true as the projection matrix (which determines X-right, Y-up, Z-out) is non-invertible and so can't be treated as just another transfom in the stack.
I don't see what that has to do with my statement. My point is that adding another transform isn't difficult, and doesn't cost anything. Invertible or not, it's still just another matrix. Also, the projection matrix doesn't "determine" X-right, Y-up, Z-out any more than any other transform does. You can change what's up/right/out in the modelview just as easily.
Indeed, in the brave new world of shaders, the projection and modelview matrices really don't even exist anymore. All that matters is what you do with your vertices in the vertex program.
I think the salient point is that Matrix_implementation::getLookAt() uses Y-up (the up-vector is (0,1,0). Sure you could rotate the OpenGL projection matrix to allow getLookAt() to use Z-up but I've never seen this happening in the wild and it would only serve to confuse.
The only reason OSG does that is because the window system uses the Y coordinate as the vertical axis of the screen, and OSG made the design decision to follow that. Again, none of this has anything to do with OpenGL. OSG could have just as easily used Z as the up vector, and the osg::Camera would be following a Z-up convention. Sure, there would need to be another transform internally to get the what GL draws to line back up with the window system, but that's trivial.
The point of this whole thread is that there is no reason to worry about what is the "natural" direction of up. It makes a lot more sense to adopt a coordinate system that works best for you application because getting OpenGL/OSG/whatever to follow that convention is trivial.
For example, most of the terrain databases in our simulators are relatively small and use a convention that X is east, Y is north, and Z is up. This isn't OpenGL's "natural" orientation, but how often do we worry about that? Never! We don't even do any kind of camera transform to handle it. The databases are modeled Z-up, so our camera just implicitly inherits the Z-up convention. When we want to move the camera up, we increment the Z coordinate and it just works. Everything is relative.
Larger simulations need to use whole-earth databases which will pick a convention where the origin of the world coordinate system is the center of the earth, the X axis projects out the prime meridian and the Y axis is 90 degrees east (or something similar). Near the surface of the earth, the orientation isn't even axis aligned, but it really doesn't matter, because it's just another transform.
Worrying about what OpenGL implicitly calls "up" is not useful, it's limiting. Worry about what your application would prefer to call "up" instead.
--"J" _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
