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?
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?
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.
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.
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.