Where do pixel gaps come from in OpenGL?

Question

The problem that I have is, that there are some pixles in my rendered scene that seem to be missing/invisible and therefore have the same color as my clear color. Interestingly, this only happens if MSAA is turned off.

My first thought was, that it could have something to do with the fact, that all the triangles are overlapping and somehow distorted by the projection matrix but these artifacts only seem to occur on lines rather than edges.

I read about just applying a scale of 1.00001 to everything in another question but that seems like a cheap hack to me that could cause other problems. Although these artifacts seem to be reduced when using hardware multisampling, I want to know if there is any other way to solve this.

Edit:

A way to solve this by Nicol Bolas:

OpenGL (and all other hardware rasterizers) only guarantees gapless rendering of the edge between two triangles if the edges exactly match. And that means you can't just have one triangle next to the edge of another. The two triangles must have identical vertices on the shared edge between them.

So if you have a long triangle next to a short triangle, what you have to do is split the long triangle into several triangles, so that the shared portion of the edge is properly shared between two triangles.

As stated, a possible solution is to split the big triangles into small ones to ensure that all overlapping vertecies are identical (i.e. abolishing the greedy meshing). But in my case I want to keep the greedy meshing due to performance aspects.

Answer 1

It's called "stitching". The rasterizer isn't matching the triangles exactly and some pixels are missing. Others have explained how to set up the triangles so OpenGL knows they share an edge. However as your model-building logic gets more and more complicated sometimes stitching is hard to avoid. The workaround is to clear to black or dark grey, and the stitches are then nearly invisible.

Answer 2

This is due to there being an issue of you having two polygons touching on the edges, and but being there would be some small error. (most likely round-off error in the floating point units being used to estimate the edge) There should theoretically also be times that they are overlapping their edges, but this would be far less noticeable. Setting a really small magnification factor, or going and just moving the polygons themselves a fraction towards each-other should resolve it. The reason it only occurs when MSAA is turned off as generally it would help prevent this type of issue. (This is due to it running all of the calculations at a higher resolution, but then downscaling everything to a lower resolution so it won't be as noticeable. The issue actually does still occur, but because of the downscaling, the missing pixels will disappear as they are blended into the surrounding pixels. )

Answer 3

OpenGL (and all other hardware rasterizers) only guarantees gapless rendering of the edge between two triangles if the edges exactly match. And that means you can't just have one triangle next to the edge of another. The two triangles must have identical vertices on the shared edge between them.

So if you have a long triangle next to a short triangle, what you have to do is split the long triangle into several triangles, so that the shared portion of the edge is properly shared between two triangles.

Since you seem to be building a world made of cubes, this should be fairly easy for you.

The other thing you have to do is make certain that the two shared vertices between the two triangles are binary identical. The gl_Position output from the vertex shader needs to be the exact same value. So if you're computing the position of the cube's vertices in the VS, you need to do that in a way that will guarantee binary identical results.

But in my case I want to keep the greedy meshing due to performance aspects.

Then you need to decide which is more important: performance, or correctness. Because there's no way to force the rasterizer allow such edges to be gapless. It's a matter of floating-point precision and such, which will always be different on different hardware.