http://oss.sgi.com/projects/ogl-sample/registry/EXT/wgl_depth_float.txt
it’s sounds like it enables w-buffering but what card has this extension?
It also says
“If
the near clipping plane is set to 1.0, and the far clipping plane is
set to 0.0, a much greater resolution of objects can occur.”
shouldn’t that be 1.0 for the far plane and 0.0 for the near plane or it doesn’t matter?
zw (z window) coordinates are normally 0 to 1 from near to far, default depth func it GL_LESS.
Now if you store floating point depth values inversely using 1 - zw and use depth func GL_GREATER you win precison in the far case, that is in the environment of the new 0 z window coordinate.
[This message has been edited by Relic (edited 06-04-2003).]
The wording of the text in this extension preamble is unfortunate.
Let’s remember that you still need to resolve more precision in the foreground, you might think objects are denser in the distance (on the shore) but in the boat you need to resolve your bait against the hook, on the distant shore you only need to resolve one tree against another.
The idea behind this extension AFAIK is to counter the non linear z mapping of conventional depth buffering with the oppositely nonlinear distribution induced by the floating point exponent and therefore get something in between the two. Just exactly what you get will depend on the ratio of near to far. It is about getting better precision in the distance and less in the foreground, but it is not about getting better precision in the distance than the foreground.
Someone please modify the text in the extension spec to reflect it’s intent.
Originally posted by Relic:
[b]zw (z window) coordinates are normally 0 to 1 from near to far, default depth func it GL_LESS.
Now if you store floating point depth values inversely using 1 - zw and use depth func GL_GREATER you win precison in the far case, that is in the environment of the new 0 z window coordinate.
[This message has been edited by Relic (edited 06-04-2003).][/b]
Does that mean all your objects z values have to be changed as well?
I’ve not seen an implementation of that extension. My description was how znear and 1 fit together. The main difference and benefit is storage of the depth value as a float. You can change the mapping of depth values with glDepthRange.
I guess it’s a concept extension, like one of those concept cars.
I think that changing the mapping would not help.
What needs to be done is inverting far for near and near for far and change the mapping to 1.0(near) to 0.0(far) and also changing the z-test to GREATER.
That should work without this extension I think.
I dont completly understand what this extensions is suppose to do. Maybe it does the needed operation automatically?
It looks like it needs some work.
A float w buffer or a reverse float z buffer makes some sense, but not much else. The preamble is complete nonsense though and makes me wonder if it wasn’t written by someone who didn’t really understand the problem (at the application level).
If you look at the precision of your types the reverse float z probably only makes sense if you have something significantly less than the fragment computational precision for storage.
Scarily enough it even mentions fixed point in there which is completely useless from what I can tell. The whole point is the variable precision induced by the changing exponent.