Adjacent triangles sometimes write to the same pixel

[nical]

Hi,

I'm hoping to use euc in lyon's testing infrastructure. Lyon takes vector graphcs shapes in 2D and tessellates them into triangle meshes that approximates the original shapes. One thing that I am particularly interested in is to check that the generated tessellations don't have contain triangles that overlap.

I've put together a prototype of the overlap check in lyon's fuzzer using euc here: https://github.com/nical/lyon/blob/overlap-test/cli/src/fuzzing.rs#L35

The vertex stage basically forwards the input vertices, and the fragment stage writes 1. The destination target is overloaded so that it does a somewhat hacky additive blend (adding the shaded value to the destination pixel instead of overwriting it).

I then count the number of times a pixel was written to more than once to detect overlaps.

I see that on a lot of simple shapes (two adjacent triangles) euc's rasterizer writes the same pixel twice (which creates false positives on the test I'm looking to make). I checked that the cases my test detect are not in fact bugs in lyon (so far).

I'll come back with a more convenient test case but this mesh for example triggered the issue:

[[0.07318455, 0.33821934], [0.2277621, 0.6909972], [0.65824705, 0.83747554], [0.2277621, 0.6909972], [0.07318455, 0.33821934], [0.023455322, 0.97718465]]

It is rendered on a 1000x1000 target.

The image below shows for this test case which pixels was written multiple times from adjacent trianges (the dark red pixel highlighted by a light blue square to make it easier to find):

All GPU APIs guarantee that this type of overlap never happens (it is important to properly render geometry with blending), I'm hoping that euc is not far from being able to guarantee this as well?

[zesterer]

This is not something that I've specifically sought to avoid (the opposite problem, tessellation gaps, was more of an issue for a while). That said, I wonder if you end up with the same issue when running the refactor branch? A pretty significant portion of the code has changed, including the rasterizer.

[nical]

I gave the refactor branch a go (BTW, very nice that render can be called without the messy generics from the main branch's draw). Unfortunately the same problem happens.

Let me know if bending is out of scope for euc (I suppose dealing with opaque geometry properly is already quite a feat).

[zesterer]

I don't think it's out of scope by any means: it's just not something that I've put much focus on yet. If you had a simple test that generated problematic cases I'd much appreciate it such that I can try to play with the rasterizer to avoid this problem.

The rasterizer uses the vertex weights to determine whether a fragment should be emitted or not. I suspect that changing this check to > 0.0 might help alleviate the issue, at least temporarily; but I'm not sure the weights themselves are sufficient. I'll have to do some research into exactly how GPUs guarantee a lack of overlap.

[DanielJoyce]

Mesa has a software renderer and might be a source of some info...