Re: [osg-users] Cameras View Matrix - I am perplexed
(I want to correct my own post here, because, as this thread has shown, things I say in the distant past stick around in search engines forever...) On 9/15/2011 2:33 PM, Paul Martz wrote: 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. This is wrong on two points. 1. A close read of the spec shows that it doesn't actually define these coordinate systems, and where the +y = up convention comes from might be a good topic for discussion in the OpenGL forums. I'm sure I knew the full story back in 1994, but it's lost in the fog of my memory. Perhaps it stems from simple Cartesian math: origin in lower-left corner of the window, +x = right, +y = up, and everything else is inferred from back-transforming. (Regardless, I still think the getLookAt code is correct, as it is just performing the inverse of osg::Matrix::lookat.) 2. The projection matrix usually performs a negative scale on z, to support right-handed world coordinates in conjunction with a +z = into the screen depth buffer convention. So I was wrong about eye coordinates above. Eye coordinates generally have -z = into the screen, not +z. The projection performs a negative scale on z, producing clip coordinates with +z = into the screen. I don't see where the spec actually prohibits setting up a different convention, though. Again, it might just be implicit in the math. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
Paul Martz wrote: How many first-person rendering systems use the ModelView matrix unmodified? The fact that the ModelView matrix is often modified isn't the correct way to look at the problem - we need to consider how the system behaves when it is the identity. Paul Martz wrote: How many first-person rendering systems use the ModelView matrix unmodified? The answer is none, they all set the ModelView matrix to something, and when app software sets that matrix, the app _must_ make a choice about what _it_ wants for a coordinate system. The OpenGL default is therefore irrelevant. An app or SDK can indeed make a choice about which coordinate system to use. However the Y-up OpenGL default is still irrelevant. To illustrate this, consider the OSG implementation of Matrix_implementation::getLookAt(). The code for calculating the up-vector is: Code: up = transform3x3(*this,osg::Vec3d(0.0,1.0,0.0)); which very much relies on the fact that the coordinate system is Y-up. If we pretended that Z-up had equal footing to Y-up then we'd be prone to writing incorrect code such us: Code: up = transform3x3(*this,osg::Vec3d(0.0,0.0,1.0)); Regards, Mik Wells -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42800#42800 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
On 09/15/2011 11:03 AM, Mik Wells wrote: However the Y-up OpenGL default is still relevant. What page of the OpenGL spec specifies that the default coordinate system is Y-Up? --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
Hi, As far as I know it's not explicitly specified but is implicit in the projection transforms. Assuming the ModelView matrix is the identity, the matrices generated by the traditional Ortho/Frustum functions would result in a vertex's Y value determing its height on the screen. That scenario is enough for me to adopt Y as the natural up axis. Also, according to the OpenGL Red Book there is a default coordinate-system orientation: The frustum has a default orientation in three-dimensional space. You can perform rotations or translations on the projection matrix to alter this orientation, but this is tricky and nearly always avoidable. Cheers, Mik[/url] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42806#42806 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
On 09/15/2011 01:23 PM, Mik Wells wrote: Hi, As far as I know it's not explicitly specified but is implicit in the projection transforms. Assuming the ModelView matrix is the identity, the matrices generated by the traditional Ortho/Frustum functions would result in a vertex's Y value determing its height on the screen. That scenario is enough for me to adopt Y as the natural up axis. The point is that the x-right, y-up convention has nothing to do with OpenGL. It comes from the transformation from world space to screen space. The 2D screen is where the x-right, y-up comes into play. If you adopt a right-handed coordinate convention (which you don't have to, but it makes certain things in OpenGL more convenient), then the identity modelview and projection matrices will give you a projection where x is right, y is up and Z is toward you (out of the screen). Some window systems might even tack their own transform onto the end of this (XRandR, for example will change the x-right, y-up convention so you can rotate your monitor). Paul's original point is that nothing in OpenGL is enforcing this, and once you start manipulating the modelview and projection matrices, it doesn't really mean anything anyway. There's no reason to pay any attention to the default orientation, since you can change that with a simple transform concatenated into the dozens of transforms you're already doing anyway. There are no absolutes when it comes to coordinate systems, everything is relative. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
Hi, There's no reason to pay any attention to the default orientation, since you can change that with a simple transform concatenated into the dozens of transforms you're already doing anyway 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 2D screen is where the x-right, y-up comes into play. Yes, until we project on to a display device up means very little. It's like a map of the World - which way is up isn't very important until the planet's surface is projected on to a piece of paper. But once it is printed on to that piece of paper, the direction of up takes on real meaning. 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. Cheers, Mik[/i] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42809#42809 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
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
Re: [osg-users] Cameras View Matrix - I am perplexed
Hi, It isn't the window system (e.g. Microsoft Windows) which uses the Y coordinate as the vertical axis of the screen. It's OpenGL. (On my windowing system Y is down). Worrying about what OpenGL implicitly calls up is not useful It may not be useful at the app level, but it's essentail if you're trying to calculate the up-vector. Invertible or not, it's still just another matrix The projection matrix has a very different role to the ModelView matrix, which is one reason why it has its own matrix stack. Cheers, Mik -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42811#42811 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
On 09/15/2011 03:59 PM, Mik Wells wrote: Hi, It isn't the window system (e.g. Microsoft Windows) which uses the Y coordinate as the vertical axis of the screen. It's OpenGL. (On my windowing system Y is down). That is accounted for in the viewport transform, not inside OpenGL itself. Worrying about what OpenGL implicitly calls up is not useful It may not be useful at the app level, but it's essentail if you're trying to calculate the up-vector. The up-vector is a relative concept. It doesn't mean anything on its own. Invertible or not, it's still just another matrix The projection matrix has a very different role to the ModelView matrix, which is one reason why it has its own matrix stack. That doesn't mean it isn't just another matrix. It's certainly useful and advisable to separate them conceptually, but nothing forces you to do so. In OpenGL 3.1+ (core profile) there isn't even a glMatrixMode() anymore (or a glMatrix-anything for that matter). You just do whatever you want in your vertex shaders. If you wanted to, you could calculate a separate projection for each vertex and then move them all around in clip space. It would be ugly, sure, but there's nothing stopping you. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
On 09/15/2011 04:33 PM, Paul Martz wrote: 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. You're right, Paul, I neglected the FFP lighting issue. There is a fundamental difference between the projection and modelview transforms for this purpose, and since lights are in eye space, there is an inherent coordinate system as well, so I stand corrected on those points. Still, in OpenGL 3.1+, that's all out the window :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
On 09/15/2011 04:33 PM, Paul Martz wrote: 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. You're right, Paul, I neglected the FFP lighting issue. There is a fundamental difference between the projection and modelview transforms for this purpose, and since lights are in eye space, there is an inherent coordinate system as well, so I stand corrected on those points. Still, in OpenGL 3.1+, that's all out the window :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org but which window did it go out of :) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
I think that makes a lot of sense, Paul. After learning about this yesterday, it took me about a half hour to think it all through, and realize that it's all pretty much equivalent and boils down to arbitrary choices about how you want to orient your scene. Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18333#18333 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
Thanks Thomas, Yeah, I think you are right. I don't have it all worked out in my head how the coordinate system switch from osg and OpenGL occur. But I notice, now, that when I try to get getLookAt() on an identity matrix, I get: eye: 0, 0, 0 center: 0, 0, -1 up: 0, 1, 0 Instead of what I expected: eye: 0, 0, 0 center: 0, 1, 0 up: 0, 0, 1 i.e., the identity matrix still has me looking down the -z axis, just like OpenGL, even though in the osg World, I'm looking downwards. Thanks again, Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18313#18313 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cameras View Matrix - I am perplexed
Frank Sullivan wrote: i.e., the identity matrix still has me looking down the -z axis, just like OpenGL, even though in the osg World, I'm looking downwards. I don't know whether this will clarify or muddy the concept, but I'll throw it out anyway. I've been on somewhat of a crusade to rid people of the notion that OpenGL has a default coordinate system. Here's my reasoning behind that idea... OpenGL has a ModelView matrix. By default, it's the identity, and in that case, object coordinates are effectively eye space coordinates, so therefore the eye is looking along the -Z axis with +Y up. That's all true, BUT... How many first-person rendering systems use the ModelView matrix unmodified? The answer is none, they all set the ModelView matrix to something, and when app software sets that matrix, the app _must_ make a choice about what _it_ wants for a coordinate system. The OpenGL default is therefore irrelevant. All too often, this notion of a default coordinate system seems to restrict our thinking and make us believe that there are limitations on how we can orient the world. I just want to point out that the idea of a default coordinate system is really a myth. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
