Z-Fighting, also called stitching, is a phenomenon in 3D rendering that occurs when two or more primitives have similar or identical values in the Z buffer. It is particularly common in coplanar polygons where two faces occupy substantially the same space without either face being in front. Affected pixels are rendered with fragments of one polygon or the other, whereby the accuracy of the Z-buffer is decisive. It can also vary when the scene or camera is changed so that one polygon “wins” the Z test, then another, and so on. The overall effect is a flickering, noisy rasterization of two polygons “fighting” for the color of the screen pixels. This problem is usually caused by limited subpixel accuracy and floating-point and fixed-point rounding errors. Z-Fighting often play an important role in 3D configurator projects.
The more Z buffer precision you use, the less likely it is that a Z fight will occur. But with coplanar polygons, the problem is inevitable if no corrective action is taken.
As the distance between near and far clip planes increases, especially when selecting the near plane at eye level, the likelihood of a Z-Fight between primitives increases. In large virtual environments, there is inevitably an inherent conflict between the need to solve visibility at a distance and in the foreground, so that in a space simulator, for example, if you scale a distant galaxy, you do not have the precision to solve visibility on any cockpit geometry in the foreground (although even a numerical representation would pose problems before z-buffered rendering). To mitigate these problems, the precision of the z-buffer is weighted towards the near clip plane, but this is not the case with all visibility schemes and it is not enough to eliminate all z-fighting problems.
How can this phenomenon be contained?
Z-fights can be further reduced by using a higher resolution depth buffer, by z-buffering in some scenarios, or by simply moving the polygons apart. Z-fights that cannot be completely eliminated are often resolved in this way by using a stencil buffer or by applying a Post Transformation Screen Space Z-buffer to a polygon that does not affect the projected shape on the screen, but the Z-buffer value to eliminate the overlap in pixel interpolation and comparison. If Z-fighting is caused by different transformation paths in the hardware for the same geometry (e.g. in a multi-pass rendering scheme), it can sometimes be solved by requiring the hardware to use invariant vertex transformation.
Z-fights caused by insufficient precision in the depth buffer can be solved by simply reducing the visible distance in the world. This reduces the distance between the near and far planes and solves the precision problem. However, in certain virtual environments, such as a space or flight simulator, this is not possible. In these cases, there are alternative techniques. One of these techniques is to “simulate” the distance of objects far away from the user without actually changing their position. For example, if the maximum safety distance (beyond which combat takes place) is 10,000 units and an object to be rendered is 15,000 units away, that object could instead be rendered at 10,000 units, but reduced proportionally to the distance over which it was moved. So an object half the size will look like it’s twice as far away as it actually is. If this only happens for objects that are already near or close to the maximum viewing distance, and objects near the user are rendered normally, this technique should not be conspicuous. Another technique used to reduce or completely eliminate Z-fights is to switch to a logarithmic Z-buffer that reverses Z. This technique can be used to reduce or eliminate Z-fights. This technique can be seen in the game “Grand Theft Auto V”. Because of the way they are encoded, floating point numbers have a much higher accuracy when they are closer to 0. Here, reversing Z leads to more precision in storing the depth of very distant objects, greatly reducing Z-Fighting.
That’s all we’ve got with our “Z-Fighting” article.
Thank you very much for your visit.