Sign in to follow this  
Guy Perfect

Depth Test Phenomenon

Recommended Posts

Guy Perfect    122
This is a problem that I've been dealing with for years, but never knew the cause/solution for working with it. The problem is that polygons or edges of polygons that are real close to each other start bleeding through in spots despite the fact that depth testing is on. I'm sure it's a simple fix, but I'm in the dark as to what it is. Here's a picture of this oddity: That's a picture of a boring ol' 6-sided cube drawn with Triangle Strips with Depth Testing set up for LEQUAL. The edges do not overlap whatsoever except for the lines connecting the vertices. The spots in the image that are showing through shouldn't be visible at all. It's an easy workaround to use backface Culling, but if I can fix it without "making due," I'd like to. Anyone have any information?

Share this post


Link to post
Share on other sites
hh10k    589
I would say that either your near clipping plane is too close, or your far clipping plane is too far away. Try adjusting the clipping planes to cover the minimum area required for your cube and see if that fixes it.

Share this post


Link to post
Share on other sites
Guy Perfect    122
Yeah, that fixed it. Thanks. The near plane was too near. I guess I'll just have to draw things bigger. So much for my beloved 10×10×10 realm.

Why do adjustments of the clipping planes make a difference? As far as I can tell, they should have no bearing on the bleed-through-ness of polygons. What reason is there for this peculiarity?

Share this post


Link to post
Share on other sites
hh10k    589
It's not so much the scale that you put everything, but the ratio between the near clipping plane and the far clipping plane that determines how 'spread out' the depth buffer will be.

For example, you would get just the same level of depth buffer quality from near=0.1, far=1000 as you would if all the objects were 10x as large and you used near=1, far=10000.

Share this post


Link to post
Share on other sites
rileyriley    235
It's an issue of precision. The z buffer is however many bits deep, and so it can only hold a finite number of depths. If you ask it to hold very near depths and very far depths, it will comply, but it's going to have to make rather big jumps to get all the way from one to the other. When you have two pieces of geometry that both round to the same depth in the z buffer, it can't tell which one is really farther away, and may draw the wrong one.

Now, you might be thinking, "well, [0.0001, 10] is less than 1 unit bigger than [0.1, 10], wtf?" This phenomenon happens (I believe) because the algorithm essentially scales whatever range you put in to be a range of [1,2^bitdepth] by dividing, and dividing by 0.0001 is very much different from dividing by 0.1, whereas dividing by 1.1 is not so different from dividing by 0.1, and 4.1 is even less different from 3.1, etc.

Share this post


Link to post
Share on other sites
lc_overlord    436
Quote:
Original post by Guy Perfect
It's an easy workaround to use backface Culling, but if I can fix it without "making due," I'd like to. Anyone have any information?


Backface culling is not something you do for an easy fix, it should be used.
And even though you might have fixed it using the correct z-near/z-far values it is not perfect.
The problem is still there, only on a much smaller scale (if you rotate the cube then you might still see some flickering at the edges in certain angles, sort of like the botom edge of the red polygon in the picture but only some single stray pixels).

Share this post


Link to post
Share on other sites
Guy Perfect    122
I always use backface culling, even if the back of polygons will be visible. I usually render two seperate polygons for the purposes of lighting and texturing, even if they overlap exactly.

But if I have one small front-facing polygon in front of, and very close to, a large front-facing polygon, I'd rather it not perform the depth testing incorrectly. That's why I needed a solution to the problem.

The cube illustration is merely an example of what the problem is.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this