display of faces corrupt
Author
Hi,
i have an object whitch i am rotating, moving and so on. It´s displayed with the opengl light feature.
I calculated the normals for every face.
everything ist working, except from some errors in the faces. There are dark triangles on the edges of some faces.
http://www.roebbeling.de/3dstuff/fehler.jpg
(Look link, I don´t know how to post pictuers)
The lightning is working correct. The errors are most on very thin shapes and when the object is quite small on teh scree.
Any suggestions?
I am 95% sure that is Z-Fighting, try resizing your Z-Buffer to 24bit, and using 32bpp.
P.S. You post pictures with standar html.
P.S. You post pictures with standar html.
My guess from your picture: These coudl be faces that 'face' the wrong way (backfaces). The only solution I have is to manually edit them and face them to front.
Quote:Original post by Marmin
My guess from your picture: These are faces that 'face' the wrong way (backfaces). I have the same problem, and the only solution I have is to manually edit them and face them to front.
Hmm i dont know, do you have CULL_FACE enabled, OP?
If you are drawing very thin objects with triangles both on the front and the back, it might be that the distance between the back and front are too small for the depth buffering to differ them from each other properly (assuming you're using depth buffering). If you don't have already, try switching on backface culling.
Regards
[Edit]
I type slow... So many beat me to it. [grin]
Regards
[Edit]
I type slow... So many beat me to it. [grin]
Quote:Original post by DerAnged
I am 95% sure that is Z-Fighting, try resizing your Z-Buffer to 24bit, and using 32bpp.
Since you draw very little geometry, it's a little overkill to use a high resolution depth buffer if you don't really have to do it. Before doing that you could try adjusting the near and far clip planes closer around your geometry. This could ease the strain on the depth buffer a little, if I'm not entirely mistaken.
Quote:Original post by staafQuote:Original post by DerAnged
I am 95% sure that is Z-Fighting, try resizing your Z-Buffer to 24bit, and using 32bpp.
Since you draw very little geometry, it's a little overkill to use a high resolution depth buffer if you don't really have to do it. Before doing that you could try adjusting the near and far clip planes closer around your geometry. This could ease the strain on the depth buffer a little, if I'm not entirely mistaken.
Yes and no, honestly, using a 32bit depth-buffer over a 16bit one, on hardware released over the last 4 years, it won't be a bottle neck.
staaf DerAnged you're both right in my experience, my engine doing shadow mapping with the depth buffer (I use 32-bit) had no increase/decrease in FPS when changing to a lower resolution(8-bit) and I couldn't tell any difference visually.
This is probably a case of having the near clip plane set to 0 and the far clip at something absurd. hannesder3te check your calls to either glFrustum or gluPerspective. When you use near clip values close to 0 with a very large far clip plane it can produce artifacts because of lack of depth buffer resolution.
This is probably a case of having the near clip plane set to 0 and the far clip at something absurd. hannesder3te check your calls to either glFrustum or gluPerspective. When you use near clip values close to 0 with a very large far clip plane it can produce artifacts because of lack of depth buffer resolution.
Quote:Original post by DerAnged
Yes and no, honestly, using a 32bit depth-buffer over a 16bit one, on hardware released over the last 4 years, it won't be a bottle neck.
I guess you're right, DerAnged. It wouldn't affect the fps very much. It was just a feeling I got.
Quote:Original post by Optus
This is probably a case of having the near clip plane set to 0 and the far clip at something absurd. hannesder3te check your calls to either glFrustum or gluPerspective. When you use near clip values close to 0 with a very large far clip plane it can produce artifacts because of lack of depth buffer resolution.
Some time ago I started a thread about cusom depth buffering and how to generate your own Z-buffers externally and to use them in my (DX) program. There I found a formula for the distribution of depth values in Z-buffering which was:
Assuming Z is a depth value between zNear and zFarRedistVal = a + b/Zwherea = zFar / (zFar - zNear)b = zFar * zNear / (zNear - zFar)This I found in some OpenGL docs and also in some nVidia docs. When I implemented it it worked fine on my Radeon, so I guess at the time at least it was fairly standard.
If this formula is used and the zNear is set to 0, then a = 1 and b = 0, so all depth values will become 1.0f. Probably there is some failsafe mechanism if this happens, but it shows that the z-buffering distribution doesn't work very well with zNear-values close to 0, especially if zFar is a lot greater. This is not only because of a lack of resolution, but moreover an issue with the Z-buffer algorithm that has to be accounted for. So what Optus says is quite true.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement