Depht Test Working ?

I’m working on a program that loads an .ase file (3DS MAX ASCII export format) and then display it.

The problem is that the depth test is not working properly.

For example, for a ship, there are reactors, cockpit, wings… When i draw it, i always see the reactors, even if there is something in front of them. Idem for the others stuffs.

In my program, i clear the depth buffer each time i draw, i’ve enabled the depth test, ans set the depth function. I’ve althought tried the culling but the result is the same.

So what is the problem ? Must i sort triangles before displaying ?

Thanks to help me.

Could you post some code ?? It would help the understanding of the mistake…

just a thought…

It sounds like a problem I have had a couple of times.

It may not be the depth buffer. It may be the back face culling. I had a similar problem, but worked out that I was in fact specifying the verticies in reverse order so that when I drew the object it culled the front face rather than the rear. Try changing the culling to front face rather than back face, and that may be your problem. (or not)

When you call the gluPerspective, than
the third parameter (near clipping plane)
must not be zero. Otherwise you will see
all faces, regardless what you specified
with the depth buffer. I don’t no if this
is a bug in some drivers or in OpenGL or
if it’s normal. I always use 1.0 in that
parameter, then it works.


I’ve been loading 3ds files without problems, even when the near cut plane was =! 1.0f. Uhmm, I also think that culling the front faces is a bit ugly.
I think some code would help us to help you.

Just tried it again… Getting the following results with third parameter set to 0.0 versus 1.0:

(The crankled outlines in web2.jpg are because of jpg-compression)
I got nVidia TNT2. I didnt have a hardware accellaration, when I encountered the problem like tjourdan have and I solved it with setting the 0.0 to 1.0 (or a bigger value). So I think its driver dependent.


So here is the code i use :

int BuildGLList()
glNewList(index, GL_COMPILE);
i set the material for the current element
For each face i get the associated vertex then :
glVertex3fv(coords[0]); glNormal3fv(normale[0]);
glVertex3fv(coords[1]); glNormal3fv(normale[1]);
glVertex3fv(coords[2]); glNormal3fv(normale[2]);
I get the next element (link chain)

int DrawGLScene()

int InitGL()
glClearColor(1.0, 1.0, 1.0, 0.0);

I’ve tried to on / off the culling, differents functions of depth test… but always the same problem.

Thanks if someone as the answer.



I’m not sure if this have anything to do with your problem since most of the work that I do is in an orthographic view, but I was having depth testing problems for a while and the problem turned out to be that my near and far clipping planes were so far apart that I was effectively losing resolution in my depth buffer. You might check it out, the the result of the problem is exactly the same - the rotors for my helicopter were always on top, even when you viewed it from the bottom!

Good luck.


tjourdan, can you post your code for setting up the view (gluperspective etc.) too?

For those who are interested.

Thomas’ problem was the following call:

gluPerspective(60.0f,(GLfloat)width/(GLfloat)height,0.0f,100.0f); // Calculate Window Aspect Ratio

As you can see, he used 0 for the z near plane. Changing it to 0.1f made it OK…



Is my english such bad? Or do I have to change my name that people believe in me? I posted in this thread before, that you shouldn’t use 0.0 as near clipping!!!

[This message has been edited by Kilam Malik (edited 11-23-2000).]

Kilam, perhaps Thierry did not see your post: he sent me the code and I fixed it…

That just means that you were right !



Taken from a document on nvidia’s site :

To calculate the screen space z coordinate (sz) from eye-space Z, a perspective transformation is applied.


sz = (zf / (zf - zn))(1-(zn/Z)) Eq.2

Equation 2 yields 0 for the near clipping plane (zn) and 1 for the far clipping plane (zf). The value
sz is the value that gets scaled by the available Z-buffer resolution and stored in the Z-buffer.

This shows how the depth value of a fragment is calculated.
You can see here why you shouldn’t use 0.0 for the near clipping plane’s Z coordinate (every fragment would have 1 as a depth value whatever it’s world’s Z coordinate).
There is no bug !

Yes there was a bug: in Thierry’s code !

We didn’t say it was a driver bug !



Sorry for not answering faster…

So the problem is solved, it war the near clipping plane (do not put 0.0 but 0.1).

Thanks for the help of everybody