Coming into this thread rather late, and didn't read all the posts, but it's
clear that there's a fundamental misunderstanding of the FFP transform here...
On 9/15/2011 1:25 PM, Jason Daly wrote:
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.
The OpenGL FFP projection matrix transforms from eye coordinates into clip
coordinates. Those two coordinate systems are defined in the spec (see section
2.11 / figure 2.6 in the 2.1 spec). +x = right, +y = up, +z = into the screen,
and eye = origin are already the eye coordinate definition prior to transform by
the projection matrix.
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.
You're free to put whatever transform you want in either matrix as long as
transform by the two produces clip coords, but for correct FFP lighting
computations, your modelview matrix *must* produce eye coordinates. OpenGL FFP
lighting is computed in eye space. So, if you did something crazy like have an
identity modelview, but a full object-to-clip transform in the projection, then
vertices would be transformed correctly, but your lighting would be way wrong.
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.
Yes. When you use a vertex shader, transformation is one of the operations your
shader owns, so you are no longer constrained to the FFP transform model, same
with lighting, fog, tex coord generation, and any other vertex ops I might have
missed.
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.
I believe you're misinterpreting the getLookAt() code.
The output of the view matrix is eye coordinates (it must be, for correct
lighting -- see above). Eye coordinates have +y = up by definition. getLookAt()
simply does a back-transform on the eye coordinate up vector to produce the
actual up vector that your application is using for its world coordinate system.
Real applications use completely arbitrary up vectors. Rotate any model to some
arbitrary orientation using the TrackballManipulator, then call getLookAt(),
just as one example. OpenGL doesn't enforce a default world coordinate
orientation. OSG's osgGA manipulators have a default home position orientation
that uses +z = up, but this doesn't mean that an OSG app needs to use this world
orientation, and I'd wager that any application that isn't a flat-map GIS
application probably doesn't use +z = up.
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.
[...]
On this point, I think you're mistaken. OSG's getLookAt() function is written
with the very logical assumption that it's working on a view matrix -- the
"view" half of the "modelview" matrix, who's output must be in eye coordinates,
as I've explained above. So, the fact that it back-transforms (0,1,0) to compute
the world up vector is *all* about OpenGL eye coordinates.
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.
100% agreement here. Too many people lose sleep because they think that some
type of default is restricting what their application can do, when, in fact,
neither OSG nor OpenGL enforce a default on your app's coordinate space.
If you must use FFP, there is no substitute for becoming intimately familiar
with the FFP transformation pipeline. The OpenGL red book (and even OpenGL
Distilled) provide excellent overviews.
-Paul
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
