# Z fighting with transparency

**URL:** <https://community.khronos.org/t/z-fighting-with-transparency/108692>\
**Category:** OpenGL\
**Created:** [June 3, 2022, 9:12pm UTC](https://community.khronos.org/t/z-fighting-with-transparency/108692 "2022-06-03T21:12:13Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![DasBabyPixel](https://community.khronos.org/user_avatar/community.khronos.org/dasbabypixel/32/8377_2.png) [@DasBabyPixel](https://community.khronos.org/u/DasBabyPixel)\
**Post date:** [June 3, 2022, 9:12pm UTC](https://community.khronos.org/t/z-fighting-with-transparency/108692/1 "2022-06-03T21:12:13Z")

</div>

![temp](https://community.khronos.org/uploads/default/original/2X/f/f649ae4e34278b0de4302f4c4f81b959456ad706.png)  
so basically this is the problem…

The R is fighting the transparent pixels of the Q (for some reason I don’t fully understand…)

These are the settings I use:

glEnable(GL\_DEPTH\_TEST);  
glDepthFunc(GL\_LEQUAL);  
glEnable(GL\_BLEND);  
glBlendFuncSeparate(GL\_SRC\_ALPHA, GL\_ONE\_MINUS\_SRC\_ALPHA, GL\_ONE, GL\_ONE);

zNear=1 and zFar=1000. Tweaking these values does not affect the outcome  
I mean z-Fighting shouldn’t even happen here. I render all the triangles for the letters in one single call to glDrawElements with one vao and vbo for all positions

I’m using java and lwjgl3 if this should affect anything, but I think that’s unlikely

Yeah thanks for any help

---

<div class="post-metadata">

**Author:** ![GClements](https://community.khronos.org/letter_avatar_proxy/v4/letter/g/e0b2c6/32.png) [@GClements](https://community.khronos.org/u/GClements)\
**Post date:** [June 4, 2022, 2:38am UTC](https://community.khronos.org/t/z-fighting-with-transparency/108692/2 "2022-06-04T02:38:44Z")

</div>

> [@DasBabyPixel](#):
>
> zNear=1 and zFar=1000. Tweaking these values does not affect the outcome

The Q and R are on the same plane. Any fragment which belongs to both triangles will have the same object-space position in both and thus the same NDC position in both regardless of the transformations. x=y =\> f(x)=f(y).

The stippling effect arises due to rounding error. As the overlapping polygons don’t have identical vertex coordinates, calculations which would produce identical values with infinite precision produce slightly different results when performed with finite precision.

> [@DasBabyPixel](#):
>
> I mean z-Fighting shouldn’t even happen here. I render all the triangles for the letters in one single call to glDrawElements with one vao and vbo for all positions

That doesn’t mean there won’t be depth-fighting. The primitives are still rendered in the order specified by the element array. `GL_LEQUAL` favours the primitive which is drawn later (presumably the R), but it won’t prevent the case where the actual depth value is half-way between representable values, with the depth value from the Q being rounded down while that from the R is rounded up.

If you want to prevent this, you’ll need to either modify the mesh so that primitives don’t overlap unless they’re identical, or disable depth testing or depth writes, or have the fragment shader `discard` wholly-transparent fragments.

If you were to tessellate the rectangles for the Q and R so that the overlapping portions were identical, it wouldn’t happen. Rendering identical triangles (where all three vertices have identical positions) should result in corresponding fragments having identical depth values in spite of rounding error (you’ll have identical calculations, rather than different calculations which should theoretically produce identical results).

Discarding transparent fragments is the simplest solution, but the use of `discard` in a fragment shader inhibits early depth testing, which has a performance cost.

---

<div class="post-metadata">

**Author:** ![system](https://community.khronos.org/uploads/default/original/2X/b/ba89cb49313a0e869198c8be354afde8bcae027e.png) [@system](https://community.khronos.org/u/system)\
**Post date:** [December 4, 2022, 2:38am UTC](https://community.khronos.org/t/z-fighting-with-transparency/108692/3 "2022-12-04T02:38:49Z")

</div>

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.