On Tuesday 01 February 2005 16:59, Timothy Miller wrote:
Nicolai Haehnle wrote:
Orthographic means that there is no perspective foreshortening (sp?). Everything that is parallel in world coordinates will also be parallel
on
the screen, and all lines that have the same length in world coordinates will also have the same length in screen coordinates.
This mode of projection is essential for everything related to 2D
graphics,
and it is often a useful mode to work in in modelling programs - think
of
building the model of a house which has many parallel planes (unless
you're
Hundertwasser, that is).
Since parallels and lengths are retained in the projection, there is no perspective correction going on (actually, the perspective correction
just
vanishes because both the OpenGL W and the W in the software model end
up
as 1) - but you obviously still want to use a depth buffer.
This is where your assumption that Z and W can be easily interconverted using a fixed formula simply breaks down.
Huh... you make a good point. I hadn't thought of that. Well, I guess it's good that we catch such things now rather than when it's too late,
eh?
Anyone got suggestions? Does Z need to be computed separately? Can we just "turn off" W divide (but still use it for depth)?
Anybody else who thinks about this should consider this: I chose orthographic projection as the example in my earlier mail because it is both easy on the imagination and easy on the math. But there are more tricks that one can play with Z and W within OpenGL (using the OpenGL meaning of Z and W here), for example projections using a far plane at infinity. This technique is described in e.g.
http://www.gamasutra.com/features/20021011/lengyel_02.htm
In particular, look at the normal OpenGL projection matrix P, and the modified matrix P_\inf. Note that W is calculated as the same value in both cases, however Z is not. This is why problems are very likely occur, and I don't believe this can be fixed in the current software model without adding a Z interpolant in the sense that OpenGL uses it.
I obviously don't know how the hardware works internally, but consider this: Maybe I missed something, but I believe the current "W" in the software model will only be used for the perspective divide. So while the additional interpolant is necessary, a) you don't need to multiply this interpolant with 1/W (because Z is linear in screen space) and b) you don't need to keep both W and Z around in later stages of the pipeline, so the number of registers you have to shift along stays the same (of course I might eat my words later when it turns out that this assessment was incorrect, but...).
cu, Nicolai
Ok, this is cause for some thinking.
Just one note: The Z used by OpenGL in geomertry is NOT linear in screen space. There is, however, a "screen Z" which is linear in screen space.
And in fact, it's not clear to me which of those OpenGL wants to see in the depth buffer.
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
