Jump to content
  • Advertisement
Sign in to follow this  
hannesder3te

OpenGL display of faces corrupt

This topic is 4906 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by staaf
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.


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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 zFar
RedistVal = a + b/Z
where
a = 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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!