Jump to content
  • Advertisement
Sign in to follow this  
poigwym

how to solve z-fighting

This topic is 767 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

two plane is same height,  the below picture :

[attachment=32233:360??20160611170253851.jpg]

 

 

can you see the red part, there's a box under the plane, and the upper face of the box has the same height as the plane...

Is this  call "flick" ?

how can I solve it ?

Edited by poigwym

Share this post


Link to post
Share on other sites
Advertisement

The best way to fix z-fighting is to move your geometry so that it doesn't z-fight.

 

Depending on which API you're using, there may be features available that can help to hide the effects of z-fighting.  In OpenGL it would be polygon offset, in Direct3D it would be depth bias.  But these are just a collection of hacks and tricks and may have unwanted side-effects.  OpenGL's polygon offset is particularly bad because the specification allows it to be implementation-dependent.  They also may not interact too well with a common non-linear depth buffer.

 

So the only real "fix" is to actually get it right to begin with.

Share this post


Link to post
Share on other sites

I always avoid depth bias style approaches because they're never very portable across different rendering APIs. I prefer to use a different projection matrix with an ever-so-slightly reduced field-of-view for decal rendering.

Share this post


Link to post
Share on other sites

The best way to fix z-fighting is to move your geometry so that it doesn't z-fight.

Yeah, co-planar geometry will z-fight... unless they share exactly the same vertices data and run the same vertex shader.

So basically, co-planar faces is an art bug - you need to fix the art.

 

If you have z-fighting in other situations, the first thing to do is to increase your near-clip value. There's also different Z-buffer formats, different projection types, reversed projections, infinite far planes, etc...

Share this post


Link to post
Share on other sites

Yeah, co-planar geometry will z-fight... unless they share exactly the same vertices data and run the same vertex shader.


My experience is that you also need the very same input assembler setup, as well as the same matrices. For example:
 

out.Position = mul (m1, mul (m2, in.Position));
out.Position = mul (m3, in.Position);


Assume that m3 = m1 * m2. This will probably z-fight.
 

device->DrawPrimitive (D3DPT_TRIANGLEFAN, ....);
device->DrawIndexedPrimitive (D3DPT_TRIANGLELIST, ....);

 
Assume that otherwise everything is identical and these are drawing the same geometry.  This will also z-fight on certain hardware (*cough* Intel *cough*).

 

So to slightly contradict my initial statement; it's also important to ensure that one is not in a situation that actually causes z-fighting when otherwise there would be none.

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!