5
$\begingroup$

Typically when coplanar or nearly coplanar polygons are rendered in OpenGL, the textures of each polygon mix together in a non-deterministic way. My understanding is that this is caused by the limited precision of the z-buffer as it uses floating point values. However, there seems to be an exception to this case. I've noticed that when two polygons are rendered with the exact same vertex positions, z-fighting does not occur. The polygon that was rendered last appears on top of the other coplanar polygon.

Why does this occur? Does this behavior always occur? Is this behavior guaranteed across all OpenGL implementations?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
6
$\begingroup$

There are explicit rules in the OpenGL specification about invariance guarantees. For the purpose of this discussion, these rules boil down to the following.

Given a particular series of vertex processing shaders (VS, tessellation, and GS), there are some set of input values, uniforms, and the like which lead to the computation of the final gl_Position value for the primitives in that process. If all of these values are binary identical (including the way the vertex format leads to any VS inputs), then you're guaranteed that gl_Position will have binary identical values. And if two primitive of the same type have binary identical positions, the rasterizer is required to generate binary identical fragment positions.

And thus, no z-fighting.

Now, that's kind of restrictive, as it only works with the same shaders. You can use different shaders, so long as:

  1. all shaders involved get binary identical values on expressions leading to the computation of gl_Position,
  2. all shaders involved use the exact same expressions (and I mean exact; a + b isn't the "same expression" as b + a, no matter what mathematics says) to compute gl_Position, and
  3. gl_Position and any inter-shader in/out variables leading to its computation are qualified with the invariant qualifier in all shaders. This tells the compiler not to optimize certain things away in expressions leading to the computation of such values.
Improve this answer
$\endgroup$
2
  • $\begingroup$ But why there's no z-fighting in the case of identical vertices? As I understand the fragments can be processed in parallel, i.e. primitives A and B are processed at the same time and it's possible that the depths of two neighboring fragments will be calculated for different promitives so they will be colored differently. $\endgroup$
    – nikitablack
    May 19, 2021 at 9:02
  • 1
    $\begingroup$ @nikitablack: While fragments can be generated, and the FS executed, in any order, writing operations must process the fragments as if they were generated in primitive order. One of those triangles was sent before the other, and therefore it will write all of its fragment data before the other. $\endgroup$
    – Nicol Bolas
    May 19, 2021 at 13:17
2
$\begingroup$

That would be because the GPU is deterministic. For the same inputs (vertex positions) it should produce the exact same per pixel depth outputs.

Z-Fighting usually occurs with polygons with different vertex positions but still on the same plane, so interpolation rounding errors show up as differences and hence Z-fighting.

Improve this answer
$\endgroup$
7
  • $\begingroup$ So it would be safe to rely on this behavior across different implementations and GPUs for example when rendering texture overlays in game programming? $\endgroup$
    – Quantum64
    Jun 26, 2019 at 9:43
  • $\begingroup$ I would say its down to the internals of the GPU, I've seen some mobile SOC GPUs with terrible interpolation precision. I'm not sure, but I don't think this precision is exposed to openGL either, given that it could be performed in floating point units of fixed point integer units inside the GPU silicon. $\endgroup$
    – PaulHK
    Jun 26, 2019 at 9:47
  • $\begingroup$ That comment is casting doubt on whether or not I should use this in my game. My alternative is to generate alpha masks for the textures I want to apply overlays to, but I would like to avoid this to save space on the texture atlas if possible. I am only concerned with desktop GPUs, should it be safe for those? $\endgroup$
    – Quantum64
    Jun 26, 2019 at 9:53
  • 2
    $\begingroup$ @Quantum64 No, this doesn't come down to the internals of the GPU alone, the OpenGL standard actually makes certain guarantees for invariance and this is one of that. For the same inputs the same calculations will return the same results. This holds for pipeline transformations and interpolations as much as it holds for any deterministic program... $\endgroup$
    – Christian Rau
    Jun 26, 2019 at 12:26
  • $\begingroup$ ...What could result in differences here would be if you have different vertex transformation operations in the vertex shaders (i.e. an MVP multiply vs. a separate P * MV multiplication). Make sure you use the same computations. Even then there could theoretically be different results (practically not, though), but even that is resolvable with declaring the vertex position invariant. So yes, drawing your mesh multiple times for stuff like texture layering is a perfectly reasonable and common use-case that, when handled properly, can be done in a 100% standard compliant and reliable way. $\endgroup$
    – Christian Rau
    Jun 26, 2019 at 12:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.