On Tuesday 01 February 2005 11:30, Timothy Miller wrote: > 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.
We don't actually have to follow the edicts of OpenGL exactly so long as glReadPixels can recover what OpenGL wants to see. For ortho projection we essentially want to have transformed Z's in the depth buffer instead of 1/W. By the way, is 1/W in the depth buffer going to be fixed point or floating point? I suggest keeping things simple and always using 24 or 32 bit fixed point. If 24 bit, the left over 8 bits can be used for stencil or alpha. Again, what the hardware does doesn't have to reflect the OpenGL state exactly, so long as the driver can make it appear to. In my experience, a 16 bit depth buffer is not useful for much more than contrived demos. With a 1/W depth buffer, planes start to interpenetrate horribly as soon as the viewpoint recedes only a short distance, or else you have to place the front clipping plane unacceptably far away. This problem could be alleviated by using floating point 1/W in the depth buffer, though I suspect that would introduce a different and nastier plethora of precision artifacts, not to mention bloating up the hardware. 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)
