On Tuesday 01 February 2005 14:20, Timothy Miller wrote: > > It's never world Z in the screen buffer, Z always has to at least > > be rotated to view coordinates. > > Terminology problem. My understanding is this: > > - Object Z -- Z coordinates in space, before camera transform > - World Z -- Z coordinates in space, AFTER camera transform
World coordinates are prior to the viewing (camera) transformation. You can think of these as coordinates of things on a map of the real world. Object coordinates are something else, they're object-relative coordinates that are supposed to make it easy to insert movable objects in a scene. In my opinion, they're mainly confusing and useless. You can safely forget about them because they are handled way up higher in Mesa's transformation stack (see "modelview matrix"). They are combined into a single matrix by the time the driver sees it. It's a matter of taste (and numerical stability) whether this single matrix takes you all the way from object coordinates to physical device coordinates or stops somewhere short of that so that further scaling and offsets are required. I need to read more Mesa code to know exactly what it does here. > - Screen Z -- Z coordinate that underwent the same perspective > transform as X and Y. There isn't really any such thing as screen Z, unless you are talking about the physical organization of the depth buffer. OpenGL defines "normalized device coordinates" in the range [-1, 1], which are transformed to "window coordinates" which are relative to some window on the physical display device and measured in screen pixels. To confuse matters further, OpenGL doesn't actually define "world coordinates" but only a modeling transformation and viewing transformation to "eye" coordinates that imply world coordinates somewhere along the line. Goodness knows why they did this. Anyway, here is a useful FAQ on the subject: http://www.opengl.org/resources/faq/technical/transformations.htm and here it is explained in programmer's terms (red book): http://rush3d.com/reference/opengl-redbook-1.1/chapter03.html It's somewhere in the blue book as well, but it's distributed in a bunch of different places and hard to decipher. I don't blame anyone for needing time to sort this out, I certainly haven't memorized it myself. It all ends up quite sensible, but there are a lot of terminology hurdles to jump to get there. Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
