Depth test works when A is in front of B but not when B in front of A

Hi all. I’m writing a little solar system app and I’m getting some really strange behavior. When I go to the side of the Earth opposite the moon and look toward the moon, I can see the moon straight through the earth, but when I go to the far side of the moon and look toward the Earth, the moon appears to be in front and obscures the Earth as one would expect. I am rendering both with gluSphere and both are textured, really the code that draws each is pretty much copy and pasted. I’m modeling the camera motion by translating and rotating everything around the observer, in other words all my calls to gluLookAt start with


… . I suppose I could find a way to make screenshots if the problem I am describing is unclear.

Another symptom presumably of the same problem is that the portion of Saturn’s rings on its far side obscures the view of the front of the planet itself. However, I am rendering background stars with a very large gluSphere surrounding everything, and everything shows up in front of that as expected. I’m kinda stumped.


That’s what I’d expect if depth testing was disabled and you were rendering the moon after the earth.

I.e. rendering stars, Saturn, rings, in that order, with depth testing disabled.

Thanks for coming to my aid again GClements, I really appreciate your taking the time. You are correct about my ordering but I’m not sure why depth testing wouldn’t be turned on. I’m using Lisp so copying and pasting my code would probably not be helpful, but in the class I declare that inherits from glutWindow I am asking for depth mode, then in the method I declare that overrides displayWindow I say to glEnable depth test and I declare depth func to be lequal. (Sorry for the lack of code, I have good documentation for translating C to Lisp but not the other way around). Would subsequent calls to glEnable for lighting, culling, etc undo my enabling depth test? I’m not sure what I could be missing.

Yep I just checked with a print statement inside my render routines. glIsEnabled returns true when passed the depth-test parameter.

Aha! Figured it out. My z-near value in glu perspective was a little too small. I knew better than to set it to zero, but I didn’t know you could make it just small enough to cause problems.

Thanks again GC.

Assuming that zFar is significantly greater than zNear, roughly half the depth range maps to -Z values between zNear and 2zNear and the other half to values between 2zNear and zFar. More generally, -Z values beyond N*zNear get roughly 1/N of the depth range. If zNear is too small, most of your scene will use a minuscule fraction of the depth range, resulting in poor depth resolution.

If you need to allow for a very large range of distance scales, you may need to use multi-pass rendering (where distant objects are rendered first and near objects last, with each pass using different near/far planes), or logarithmic depth, or a floating-point inverted depth buffer (where the depth is 1 at the near plane and 0 at the far plane, so that decreases in the Δdepth/ΔZ ratio near the far plane are offset by the increases in floating-point precision closer to zero).