# Question about the depth buffer

This topic is 4439 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

After doing exhaustive research on the issue and not finding any definitive answers, I was hoping somebody here could clear up a few things about the depth buffer... From what I read, pixel z-values are stored in the depth buffer relative to the viewer's eye position, and scaled relative to the near and far clipping planes, with a final value somewhere between 0.0 and 1.0. What I have is 2 cubes in 3D space. For simplicity, say their width's are 10 units, with cube1's center at (0,0,0) and cube2's at (0,0,-100). Cube1 is drawn before cube2. I have the following flags set: glEnable(GL_DEPTH_TEST); glDepthFunc(GL_LEQUAL); Of course, I'm clearing the depth buffer with 1.0. Here's the problem - currently I have implemented a camera with 6 degrees of freedom, so the player is free to move around these cubes in any orientation. If the viewer's eye is looking at the cubes down the -z axis at a slight angle, both cubes appear correctly (cube2 being slightly hidden by cube1). However, if the viewer now moves to the opposite side of the cubes and looks up the +z axis, cube1 is not properly hidden behind cube2. In fact, some weird graphical artifacts occur depending on how you are looking at the cubes (in some cases it looks like a poor attempt at blending even though blending is not enabled). In fact, if I draw the first cube with the depth buffer enabled, and draw the second with the depth buffer disabled, the first cube is visible at all times, no matter where the viewer is positioned. Now my thoughts are, if the depth buffer value for each pixel really IS relative to the viewer's current position and viewing frustrum, why is one cube visible at all times and only one cube properly hidden? If the depth value is relative to the objects actual position in space then this makes sense. Does the order objects are drawn really matter? I though the whole point of the depth buffer was to eliminate the need for a specific drawing order. An proper explanation of the depth buffer and why I'm seeing the errors I am would be greatly appreciated. -Q

##### Share on other sites
Your context may not have a depth buffer, in which case enabling depth testing does nothing.

How did you create the context?

##### Share on other sites
I created the context the usual way:

hRC=wglCreateContext(hDC)

as well as

wglMakeCurrent(hDC,hRC)

I also made use I set depth buffer bits to 16 in the PFD. Depth testing does seem to be functioning properly from a certain angle, just not every angle.

##### Share on other sites
What is your projection matrix? I have the slight suspicion you have set your near plane to 0.0

##### Share on other sites
Depth testing is done in eye-coords. So the position of your camera matters.
If you have blending on(you said no) then you have to draw from back to front.
To speed some things up you want to draw opaque things from front to back.

That said, the depth buffer should let you draw opaque things in any order and get the correct
output from the program.
You could try changing the order of things, GL_GEQUAL and clear to 0.0 ... but I doubt that will change anything.

##### Share on other sites
I've set my near plane to .001, far to 100000. I know that seems a bit excessive, but for the time being I'm rendering a rather large 'grid world' that I was using to debug camera movement. The odd thing is that if I set the near plan to .1, and the far plane to 1000 and just render the cubes, I can't see them no matter where I'm positioned. Even stranger, every definition of gluPerspective I've read states that the near plane MUST be a positive number, but I've experimented with mine at -1.0 and everything renders just fine.

I'm thinking the drawing order of objects for my case does matter, regardless of depth buffer setting. What I'm trying to avoid is being able to see a projectile (like a laser or a missle) on screen if it is behind a player or another object; the object still needs to show up if it flies in front of another player or object from the viewer's perspective. This is easy if the player doesn't move, but the engine I'm building is designed to support space-combat simulation type games.

##### Share on other sites
So I read NeHe's lesson 32 again for the 12th time or so, and I think the solution to my problem lies in the order my objects are being drawn. I know my depth buffer works fine when the cube that is supposed to be furthest away is drawn first, and the closer cube is drawn last. NeHe's tutorial talks about sorting (picking) of objects, which seems like a simple solution to this problem.

If any body uses another method of object sorting, especially in large open spaces, please share.

##### Share on other sites
The depth buffer definately does not need any object sorting in order to work right. That's not your problem, but I really don't know what it is. There must be something wrong with your matrix setup, but I can't say without looking at the code.

##### Share on other sites
Quote:
 From msdn:Depth-buffer precision is affected by the values specified for znear and zfar. The greater the ratio of zfar to znear is, the less effective the depth buffer will be at distinguishing between surfaces that are near each other. If r = far / nearroughly log (2) r bits of depth buffer precision are lost. Because r approaches infinity as znear approaches zero, you should never set znear to zero.

It sounds like your depth buffer is working, but because of the huge ratio between far and near (100000/0.001 = 100000000!) it lacks precision.
Try setting the far plane to something like 1000 and the near plane to 1.
This will reduce the ratio to 1000 while increasing the precision. For your scene it will hardly make a difference, as both cubes will still between far and near.
Alternatively, you could increase the precision of the depth buffer by setting its bits to 24 or 32 in the PFD. I'd prefer my first solution though.

##### Share on other sites
Quote:
 Original post by mikemanThe depth buffer definately does not need any object sorting in order to work right. That's not your problem, but I really don't know what it is. There must be something wrong with your matrix setup, but I can't say without looking at the code.

Are you certain about that? Don't forget that the viewer in my app has complete freedom of movement, so even if the depth buffer works fine when the viewer is looking straight at the cubes, what is supposed to happen when the viewer moves behind the cubes and looks at them from the opposite direction?

Thanks for the MSDN reference...I'll have to play around with my near/far clipping planes some more.

1. 1
2. 2
JoeJ
20
3. 3
frob
17
4. 4
5. 5

• 10
• 10
• 11
• 13
• 9
• ### Forum Statistics

• Total Topics
632197
• Total Posts
3004728

×