On Sunday 30 January 2005 07:47, Daniel Phillips wrote: > On Saturday 29 January 2005 18:35, you wrote: > > The fact is, *all* 3D APIs expose their depth buffer. OpenGL (and > > Direct3D) specify a Z-buffer. Applications can read this Z-buffer - > > for example using glReadBuffer, but there are probably less > > straightforward ways to do it. So we *MUST* be able to produce > > compliant Z values. There's simply no way around it. > > OK, it occurs to me that the way glReadPixels is defined we don't have a > problem. For each render frame, W differs from Z only by a simple > offset, so we can recover Z from 1/W with some simple arithmetic on the > host side where we've got access to plenty of divide power. Unless > I've missed something else, this allows us to rely on 1/W buffering if > that is the superior approach.
Hmm, I'm still not entirely convinced. The problem is that OpenGL specifies two values where the current model has only one, and unlike your assumption, OpenGL does not force the constant relation between those two values. Consider, for example, rendering with an orthographic projection. In OpenGL, the coordinates before the perspective divide will always have w = 1, but their z will vary. So perspective correction has no effect, but the depth value in the depth buffer will not be uniform. I don't see how this could be implemented in the current model, where the value written to the depth buffer is invariably tied to the value used in perspective correction. And orthographic projection is not an obscure technique. I am sure that there are more obscure techniques out there that would collide with the current model. Basically anything that doesn't use the default glFrustum() to set up its projection matrix is very likely to fail, including for example the far plane elimination that is often found used in conjunction with stencil shadows. Other techniques that use different ranges in the depth buffer for different areas of the scene are problematic, too. Also, rendering techniques that involve sending vertices with W != 1 to the GL come to mind - I'm not sure whether those will work in the current model. cu, Nicolai > Regards, > > Daniel
pgpf00nA6eFeB.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
