Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


zbuffer problem?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 starsailor   Members   -  Reputation: 122

Like
Likes
Like

Posted 26 August 2001 - 10:13 PM

I''ve got a bunch of simple cubes spinning around, and with backface culling disabled it''s as though the backfacing polys bleed through seemingly random, and mostly around the edges, and flicker ontop of the front-facing. it''s fixed now with backface culling, but I was just wondering if anyone has any clue to what causes it?

Sponsor:

#2 mittens   Moderators   -  Reputation: 1323

Like
Likes
Like

Posted 26 August 2001 - 11:07 PM

Try turning on GL_DEPTH_TEST (glEnable(GL_DEPTH_TEST))... That should be your problem.

------------------------------
Trent (ShiningKnight)
E-mail me
Shining Darkness- A division of Chromesphere Studios

#3 starsailor   Members   -  Reputation: 122

Like
Likes
Like

Posted 27 August 2001 - 12:41 AM

I''ve got depthtesting on. the weird part is that it''s not the entire polys, just around the edges. could it be that the resolution of the depthbuffer is too small, or that I''ve got too small objects zoomed up?

#4 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 27 August 2001 - 01:55 AM

I had the same problem in my city rendering app on the edges of buildings. I''ve recently found out that it''s caused by the limited precision of the depth buffer (16 bit in my case) and the effect is known as ''stitching'' or ''Z-fighting''.

Culling backfaces helps a lot, but doesn''t fix all the cases. For example, where I have 2 buildings separated by a very narrow alleyway, I still get the problem. In general, if you have 2 polygons close together in depth viewed from a large distance, you can run into this.

According to the OpenGL FAQ you can fix this by varying the zFar and (especially) the zNear planes of your viewing frustum. I''m still experimenting with this because it also affects the viewing angle in nasty ways.

See issue 12.040 at http://www.opengl.org/developers/faqs/technical/depthbuffer.htm

#5 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 27 August 2001 - 02:08 AM

Perhaps glPolygonOffset would be of use here. Just a thought.

#6 Dodger   Members   -  Reputation: 122

Like
Likes
Like

Posted 27 August 2001 - 04:37 AM

Z-fighting usually results from not enough z-buffer precision. Try to either
a) increase the depth of your z-buffer
and/or b) move the far and near clipping plane of your frustum closer together.

The further the near and far clipping planes are apart, the lower the depth buffer accuracy gets in relation to the ''amount of space'' in between them. Try to keep them as close together as possible for your application.




#7 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 27 August 2001 - 11:00 PM

Oh, by the way, I found out why zNear affect the viewing angle in "nasty ways". If you use glFrustum the top, bottom, left and right params must be scaled along with zNear if you want to keep the same viewing angle. I.e. top = tan(0.5 * field_of_view) * zNear. If you use gluPerpective you don''t have to worry about this.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS