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

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.

What is your projection matrix? I have the slight suspicion you have set your near plane to 0.0

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.

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.

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.

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.

Quote:Original post by mikeman
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.

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.