<p>Even if two triangles aren't coincident...</p>
<p>Z fighting happens because of floating point quantization, this results from all the math the shader does to compute vertex positions such as: <span class="math-container">$glPosition = Projection*View*Model*vertex\_position$</span></p>
<p>When the vertices are all the same distance and angle from the camera then all the floating points values are effectively the same and the tiny error that crops up is so close that the Z fighting <em>appears</em> to go away.</p>
<p>On the other hand if you change the angle of the camera even a little bit then all the floating point values for each vertex are now slightly different and so is the quantization. This results in the z fighting that you are seeing.</p>
<p>But keep moving the camera back, and the results for the perfectly aligned camera will eventually begin to exhibit the same behavior. The camera position is also a floating point value and subject to floating point error so no matter how perfectly the camera is aligned, it will still, eventually, have enough error to cause the same issue.</p>

CC BY-SA 4.0
2021-05-19T12:00:50.977Z
I don't think this is a correct answer, sorry. If all the vertices are the same then a GPU is guaranteed to produce the same depth for all the fragments (with the same shader). And if the depths are the same the normal rasterization takes place with the rule that primitives are processed in submission order so the first one wins (with depth compare less). But in my case, the vertices are different (but still on the same plane) and I expect to see the z-fighting regardless of the camera position.
nikitablack
CC BY-SA 4.0
2021-05-19T12:16:42.550Z
Obviously draw order plays a role, but the fundamental reason for z fighting is quantization, which is a result of the accuracy of 32 bit floating point numbers.
pmw1234
CC BY-SA 4.0
2021-05-19T13:58:02.803Z
I know how floating-point numbers work and understand the rounding problem. For me still, the picture on the right looks very suspicious because the rounding errors are completely gone. I can't imagine that there's special magic behind this so should it be a coincidence and on another GPU it will look differently?
nikitablack
CC BY-SA 4.0
2021-05-19T14:33:56.007Z
@nikitablack: "*I expect to see the z-fighting regardless of the camera position.*" That's the wrong expectation to have; you can never "expect" z-fighting. Z-fighting is an artifact, essentially a form of "undefined behavior". And how that manifests will be different depending on the situation. You can say that z-fighting *might* happen, but you can never say that it *will* unless you know the details of the GPU. "*I can't imagine that there's special magic behind this so should it be a coincidence and on another GPU it will look differently?*" It could. But that doesn't mean it *will*.
Nicol Bolas
CC BY-SA 4.0
2021-05-19T14:51:44.840Z
@NicolBolas thank you for the input. But still, I didn't hear anything about my particular case - why certain camera angles completely remove the z-fighting. After discussions and readings, I'm almost sure that this is pure math and that just happened that rounding errors are not appearing.
nikitablack
CC BY-SA 4.0
2021-05-19T15:05:56.277Z
@nikitablack: "*I'm almost sure that this is pure math and that just happened that rounding errors are not appearing.*" Well, yeah. That's what this answer is saying. That the math can work out in such a way that "the Z fighting appears to go away".
Nicol Bolas
CC BY-SA 4.0
2021-05-19T10:52:46.770Z
2021-05-19T10:52:46.770Z
pmw1234
<p>There's a similar question <a href="https://computergraphics.stackexchange.com/questions/8940/why-do-identical-polygons-not-z-fight-in-opengl">Why do identical polygons not z-fight in OpenGL?
</a> but I believe I have a different setup.</p>
<p><a href="https://i.sstatic.net/I5uA5.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/I5uA5.png" alt="enter image description here" /></a></p>
<p>As can be seen in the picture the vertices for the planes are different and on the left side, there's a clearly visible artifact. On the right side, there's no z-fighting even in movement. Why?</p>
<p>Update: the white plane draw call submitted first. The depth compare operation is <code>VK_COMPARE_OP_LESS_OR_EQUAL</code>.</p>

<z-fighting>
Why there's no z-fighting for coincident planes if the camera look perpendicular at them?
nikitablack
# Why there's no z-fighting for coincident planes if the camera look perpendicular at them?

(Asked by: username_0 on 2021-05-19)

There's a similar question [Why do identical polygons not z-fight in OpenGL?](https://computergraphics.stackexchange.com/questions/8940/why-do-identical-polygons-not-z-fight-in-opengl) but I believe I have a different setup.

[![enter image description here](https://i.sstatic.net/I5uA5.png)](https://i.sstatic.net/I5uA5.png)

As can be seen in the picture the vertices for the planes are different and on the left side, there's a clearly visible artifact. On the right side, there's no z-fighting even in movement. Why?

Update: the white plane draw call submitted first. The depth compare operation is `VK_COMPARE_OP_LESS_OR_EQUAL`.

**Tags:** z-fighting


---

## 1 answers

### Answer by username_1 on 2021-05-19. Score: 2 | Accepted answer

Even if two triangles aren't coincident...

Z fighting happens because of floating point quantization, this results from all the math the shader does to compute vertex positions such as: $glPosition = Projection\*View\*Model\*vertex\\_position$

When the vertices are all the same distance and angle from the camera then all the floating points values are effectively the same and the tiny error that crops up is so close that the Z fighting *appears* to go away.

On the other hand if you change the angle of the camera even a little bit then all the floating point values for each vertex are now slightly different and so is the quantization. This results in the z fighting that you are seeing.

But keep moving the camera back, and the results for the perfectly aligned camera will eventually begin to exhibit the same behavior. The camera position is also a floating point value and subject to floating point error so no matter how perfectly the camera is aligned, it will still, eventually, have enough error to cause the same issue.

> **Comments:**
> **username_0**: I don't think this is a correct answer, sorry. If all the vertices are the same then a GPU is guaranteed to produce the same depth for all the fragments (with the same shader). And if the depths are the same the normal rasterization takes place with the rule that primitives are processed in submission order so the first one wins (with depth compare less). But in my case, the vertices are different (but still on the same plane) and I expect to see the z-fighting regardless of the camera position.  
> **username_1**: Obviously draw order plays a role, but the fundamental reason for z fighting is quantization, which is a result of the accuracy of 32 bit floating point numbers.  
> **username_0**: I know how floating-point numbers work and understand the rounding problem. For me still, the picture on the right looks very suspicious because the rounding errors are completely gone. I can't imagine that there's special magic behind this so should it be a coincidence and on another GPU it will look differently?  
> **username_2**: @username_0: "*I expect to see the z-fighting regardless of the camera position.*" That's the wrong expectation to have; you can never "expect" z-fighting. Z-fighting is an artifact, essentially a form of "undefined behavior". And how that manifests will be different depending on the situation. You can say that z-fighting *might* happen, but you can never say that it *will* unless you know the details of the GPU. "*I can't imagine that there's special magic behind this so should it be a coincidence and on another GPU it will look differently?*" It could. But that doesn't mean it *will*.  
> **username_0**: @username_2 thank you for the input. But still, I didn't hear anything about my particular case - why certain camera angles completely remove the z-fighting. After discussions and readings, I'm almost sure that this is pure math and that just happened that rounding errors are not appearing.  
> **username_2**: @username_0: "*I'm almost sure that this is pure math and that just happened that rounding errors are not appearing.*" Well, yeah. That's what this answer is saying. That the math can work out in such a way that "the Z fighting appears to go away".  

---

