Hi!

I'm writing an application which needs to write depth information to the 
depth buffer. AFAIK is there no linear mapping from depth to the value, I 
must write to the buffer. Therefore: How can I compute the depth 
buffer-value from the depth value?

thx

Markus Doerschmidt

Markus D�rschmidt wrote:
> Hi!
> 
> I'm writing an application which needs to write depth information to the 
> depth buffer. AFAIK is there no linear mapping from depth to the value, I 
> must write to the buffer. Therefore: How can I compute the depth 
> buffer-value from the depth value?
> 

It's not easy...

You could use gluProject() to generate a table
of depth values to use as a base for a table
based lookup.

-- 
<\___/>          For email, remove my socks.
/ O O \
\_____/  FTB.    The Cheat is not dead!

On Mon, 8 Nov 2004 08:46:23 +0100, "Markus D�rschmidt"
<markus.doerschmidt@gmx.de> wrote:

>I'm writing an application which needs to write depth information to the 
>depth buffer. AFAIK is there no linear mapping from depth to the value, I 
>must write to the buffer. Therefore: How can I compute the depth 
>buffer-value from the depth value?

Isn't it true that  that you can apply -any- monotonically increasing
mapping between  your desired value and the 'depth' you write into the
depth buffer & it will have the same effect (apart from resolution)?
Um, and-- as long as the endpoint mapping is 0.0-> 0.0 and 1.0->1.0.
I'd think that would give you enough freedom to find a linear mapping
that would do the job...

Matt Feinstein

--
There is no virtue in believing something that can be proved to be true.

Matt Feinstein wrote:
> On Mon, 8 Nov 2004 08:46:23 +0100, "Markus D�rschmidt"
> <markus.doerschmidt@gmx.de> wrote:
> 
> 
>>I'm writing an application which needs to write depth information to the 
>>depth buffer. AFAIK is there no linear mapping from depth to the value, I 
>>must write to the buffer. Therefore: How can I compute the depth 
>>buffer-value from the depth value?
> 
> 
> Isn't it true that  that you can apply -any- monotonically increasing
> mapping between  your desired value and the 'depth' you write into the
> depth buffer & it will have the same effect (apart from resolution)?
> 
> 

Yes, but people who do this usually want to draw
something else on the top of it.


-- 
<\___/>          For email, remove my socks.
/ O O \
\_____/  FTB.    The Cheat is not dead!

Writing depth values with an any monotonically increasing mapping would
cause problems in drawing an object in the scene.

Is there no specification how the depth values are mapped to the depth
buffer? Does each OpenGL implementation handle this in another way?

thx
Markus

Markus D�rschmidt wrote:
> Writing depth values with an any monotonically increasing mapping would
> cause problems in drawing an object in the scene.
> 

Correct.

> Is there no specification how the depth values are mapped to the depth
> buffer? Does each OpenGL implementation handle this in another way?
> 

They all do it the same way (I think), the
problem is that there's no nice simple formula
for it.


-- 
<\___/>          For email, remove my socks.
/ O O \
\_____/  FTB.    The Cheat is not dead!

fungus wrote:

> Markus D�rschmidt wrote:
> 
>> Writing depth values with an any monotonically increasing mapping would
>> cause problems in drawing an object in the scene.
>>
> 
> Correct.
> 
>> Is there no specification how the depth values are mapped to the depth
>> buffer? Does each OpenGL implementation handle this in another way?
>>
> 
> They all do it the same way (I think), the
> problem is that there's no nice simple formula
> for it.

Well, there have been implementations that used a W buffer instead of a 
Z buffer, and there may well be differences in how the z values are 
calculated. However, since many applications rely on gluProject and 
gluUnProject (or similar code), the implementations would get lots of 
bug reports unless they were at least close to the "usual" calculation.

I have not found many problems when reading back the depth buffer in 
floating point or integer formats. However, my accuracy needs are fairly 
low.

--
Andy V