Anybody know any pitfalls to depth testing that I should be aware of? I've got two small sample apps I've written and in one depth testing works and in the other it does not. Objects "behind" other objects are being drawn in front -- according to the order that their draw methods are being called.

I set the depth-test code up the same way (straight from the Red Book), and the context is active, so I don't know what's going on. The only major difference is that the working app uses glVertex3f(), problem app uses glVertexPointer().

Short of publishing the entire code (which spans multiple objects), I'm not sure what other information to mention. Please ask.

Thanks,

Brent

Some things to check:

glEnable(GL_DEPTH_TEST);

glDepthFunc(GL_LESS); OR glDepthFunc(GL_LEQUAL); OR nothing

glDepthMask(GL_TRUE); OR nothing

If you're using AGL, CGL or NSGL to set up the context, you should have something like

DEPTH_BITS, 16

(where DEPTH_BITS is an API-specific constant) in your attributes list.

If you're using GLUT, GLUT_DEPTH bit-or'ed into the mask to glutInitDisplayMode.

If you're using SDL, the appropriate SDL thingie

If Cookie's solution isn't working, you should investigate the vertex order of your object(s).

When I began I made some mistakes related to my data organisation when I first adventured myself to the world of glVertexPointer etc.

One last thing to keep in mind is your viewing projection (frustum). If the near plane and far plane are really far apart, the depth functions loose accuracy.

For example, if you do:

This is bad -- too far apart. Also, you never want your near clipping plane to be at 0 (make it 0.1 or something else).

This probably isn't your problem, but something else to check.

HTH,
Jeff

Quote:Originally posted by OneSadCookie
Some things to check:

glEnable(GL_DEPTH_TEST); // yes

glDepthFunc(GL_LESS); // yes[b]OR glDepthFunc(GL_LEQUAL); OR nothing

glDepthMask(GL_TRUE); OR nothing //yes

If you're using AGL, CGL or NSGL to set up the context, you should have something like

DEPTH_BITS, 16

(where DEPTH_BITS is an API-specific constant) in your attributes list. // using the default NSOpenGLContext
[/b]

I was very careful in determining triangle vertex indexing so I'm not worried about front/back faces being mixed up -- but this shouldn't affect the z-value anyway, should it? Anyway, everything is CCW, but I've even built a little toggle button in my interface to let me switch to CW so that I can see the backfaces when I want to. This doesn't affect the failure of depth test to do anything.

Light Box
that's the project for anyone interested. Free code!

Brent

Quote:Originally posted by jefftkd

Code:

gluPerspective(60.0,width/height,1.0,2000.0);

This is bad -- too far apart. Also, you never want your near clipping plane to be at 0 (make it 0.1 or something else).

Thanks Jeff, but you're right, that wasn't it. The objects in the scene are 1.5 to 25 units in size, near plane is 1.0, and the far plane is 100.0. I believe though that the depth distance itself is not as important as its size relative to the size (specifically the distance between) objects in the view, no? Also, I thought that the depth values were perspective corrected so that the problem only got serious towards the far clipping plane, where the same distance between objects would be a smaller value in the depth-buffer. I could be mixing up something else, though.

B

This is your problem:


The default pixel format doesn't have a depth buffer.

You should instead do something like this:


That's what I meant when I said

Quote:If you're using AGL, CGL or NSGL to set up the context, you should have something like

DEPTH_BITS, 16

(where DEPTH_BITS is an API-specific constant) in your attributes list.

I should never question those who know, but you know, some things don't make sense the first time.

Thanks, of course it works now.

I was just confused about something. I have another test app. My subclass of NSOpenGLView doesn't override any init methods or call [super initWithFrame:pixelFormat]. I don't create a pixelFormat myself, so I just assumed that the default was being used. Apparently not. They have a different default. (Come to think of it, I no longer understand how that works...)

It just seems odd that they'd have a default and then use a different one internally. But stranger things have happened.

Thanks very much for the help.

B

I was having the same issue with depth testing, but thanks to this code it's been resolved.

thanks guys