winz depth buffer relation

can you give me relation between winz and depth buffer zd

    let real world point be Xw,Yw,Zw
    its screen point     be winx,winy,winz --> from gluProject
    let zd               be depthBuffer[winx][winy] --> from glReadPixels(..GL_DEPTH_BUFFER..)

    now how do I relate zd -to- winz

    I'm interested to find whether the world point is visible or occluded
    from this info [zd,winz,Zw,gluProject,gluUnProject]



Aren’t they the same? I think they are, if you read the depth buffer value as GL_FLOAT. Within a certain tolerance, of course.


Zw = 0.853817; winZ= 0.611403; Zdepth= 1.000000

Well here’s what I intend to do to find whether a 3D point is visible or not

// winZ <-- 3D point
gluProject( Xw, Yw, Zw,mvm, pm, vp, &winX, &winY, &winZ );
// Zdepth <–corresponding
glReadPixels(winX,winY, 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT, &Zdepth);

if( winZ > Zdepth )
visible = false;
visible = true;

but the values winZ, Zdepth are not same for visible points also.
My doubt is can we compare winZ, Zdepth like this , or , do we have a relation between the two…

if this relation exists
1/Zdepth = (1/Znear - 1/winZ )/(1/Znear - 1/Zfar )
do [Znear, Zfar] correspond to values used in gluPerspective, or glFrustum…

how do I exactly relate winZ and Zdepth



Are you drawing points? If you do then the pixel that you are reading the DEPTH_COMPONENT from might be rendered one pixel away. (I wanted to do the same comparison as you and I debugged for days.) The second problem was that gluProject is probably done on CPU not in HW thus leading to invariance. I am not completely sure on the last one. Does anyone know if gluProject is invariant with the z buffer value.


Why dont you do a test.

Render a polygon that is facing you, and read the depth from that.
Make sure that your modelview,projection,viewport that you send to gluProject are the correct ones.

gluProject doesn’t use the hw at all.

There will be a slight difference, so it’s recommended that you set your depth buffer as 24 or 32bpp to keep the difference to a minimum.

When I did my tests, 100% of the pixels rendered were different, but their values were very close. I think you can trust the results to 6 decimal places.

I tested and I get very different and weird results

my GL Settings

gluPerspective(90,1.0, 2, 3000 );

so I assumed zNear = 2; zFar = 3000;
for certain 3d points of a large set
Zdepth=1.000000 winZ=0.694281
Zdepth=1.000000 winZ=0.687986
Zdepth=1.000000 winZ=0.696543
Zdepth=1.000000 winZ=0.695461
Zdepth=1.000000 winZ=0.660850
Zdepth=1.000000 winZ=0.671353
Zdepth=1.000000 winZ=0.687734
Zdepth=1.000000 winZ=0.697303
Zdepth=1.000000 winZ=0.692211
Zdepth=1.000000 winZ=0.700016
Zdepth=1.000000 winZ=0.671326
Zdepth=1.000000 winZ=0.663656
Zdepth=1.000000 winZ=0.697395

this winZ is obtained from gluProject of 3d point object space coords.

Can anyone give exact / explicit relation between such a Zdepth and winZ



They are the same, with a slight error. You are doing something else wrong, all your depth buffer values are one, meaning the far plane. Possible things that could cause this:

-No depth test enabled
-You draw with depthMask(false)
-You read from the wrong position, maybe outside the window
-Your variable types are somehow messed up. This is unlikely to cause all Zdepths to be 1 though
-You don’t request a depth buffer when creating the window
-Your rendering context isn’t active at some point when it should be
-You do swapbuffers right before you read the values, after that the backbuffer values are undefined. Propably the empty frontbuffer gets swapped there, which would explain…
-Or then there’s just nothing at the position you read from.


All the above issues are taken care of.
specs: i686/linux/riva-tnt2
depth buffer read as GL_FLOAT

both winZ and Zdepth must be same, but I was not convinced because
>> for the visible points, the precision differed at third decimal
>> I have no points near zFar plane and still have lots of zBuffer entries with 1.0

As of now I have implemented visibility as
(winZ - zDepth ) <= 0.01. Certain glitches still persist. Sometimes even visible triangle are also thresholded

Thanks for the inputs