# z fighting

Hi. I am drawing lines over quads. Even my near plane is 34 and my far plane is 50 I get depth fighting. I also use glDepthFunc(GL_LEQUAL). My depth buffer is 24 bits. Can anyone help please?

doesn’t sound like z-fighting, could you post a picture?

figure is as below. all black lines should be black continuous lines.

you can reach the file at
http://www.geocities.com/hiperstatiko/z_fight.JPG

also

I am sorry for the problem for the image. The link below works fine.

http://www.geocities.com/hiperstatiko/z_fighting.html

any recommendations?

That is some kind of depth fighting, but not something directly related to the near clip plane. Lines and triangles may not generate the exact same depth value, even though is mathematically should, so you get problems when you assume the depth are equal. Use polygon offset to solve it. Look up glPolygonOffset.

Thank you Bob, glPolygonOffset solved the problem. I have another question now: what should I do if I want to do blending? I heard that I cannot use depth test. So, for a 3D scene, I will need to draw objects from back to front? How do I do that? I heard about BSP etc.? Are they efficiently applicable to rotating scenes? Thank you.

Originally posted by Bob:
That is some kind of depth fighting, but not something directly related to the near clip plane. Lines and triangles may not generate the exact same depth value, even though is mathematically should, so you get problems when you assume the depth are equal. Use polygon offset to solve it. Look up glPolygonOffset.

… what should I do if I want to do blending? I heard that I cannot use depth test. So, for a 3D scene, I will need to draw objects from back to front? …
In fact, for blending to work correctly, it depends on the blending equation you use.

With additive blending, (GL_SRC_ALPHA, GL_ONE for ex) there is no need to sort the blended primitives, because addition is commutative. You should only disable depth writing for the blended primitives.

With other blending modes, the blended primitives should be drawn last and sorted back to front.

Don’t use offset for this, adjust your clip planes, you should have the precision for this.

Originally posted by dorbie:
Don’t use offset for this, adjust your clip planes, you should have the precision for this.

As far as I know, you cannot ensure that z-fighting will not occur, even with 32 bit depth.Also, surface s maybe curved, making it impossible to uniformly offset the wireframe or solid to achieve the overlay look.

I would suggest you stick with polygon offset. I have seen few problems with it, as long as your depth range is set correctly and the projection matrix is fine.

Your glFrustum call has the near and far clip plane parameters in in. You have a very simple small model it should not have zbuffer artifacts, you must have set your near clip VERY close and you probably have the far clip very far away too.

Try to sandwitch the model between your near and far and you will eliminate this problem. Some types of zfighting are caused by coplanar surfaces and cannot be solved like this unless you use polygon offset, but this is not the cause of your problem.

You have a rather straightformard zbuffer precision problem where the edges of your object are not resolving accurately enough. It will be solved by adjusting your near and far clip planes.

I was confusing this thread with another zbuffer problem thread where an image was posted where edges were not resolving. So discount my later post, I mistakenly thought the latter replies were aimed at this problem:

http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_to pic;f=3;t=011775