Single pixel holes in GBuffer

Started by
4 comments, last by tonemgub 8 years, 7 months ago

I recently added a sky to my application, and while testing I simply wrote red pixels wherever the sky shader was invoked. When doing this I noticed that a few pixels inside solid geometry turned red, and they vary depending on camera angle. The way I render the sky is that I render a fullscreen triangle at the far plane and use the depth buffer for early z-rejection, only shading fragments where the far plane is visible (i.e. no geometry has been rendered). This led me to believe that the depth buffer still contained its clear value at those texels.

It turns out that the GBuffer have holes where a fragment has not been generated, and these holes seem to appear where two triangle edges meet. This is the final image. It's quite dark, but you're looking at a wall with two windows and a slanting roof above it (see the image below for a clearer view as to where the roof begins). To the right is a pillar. Notice the few pixels in a row where the wall meets the roof between the two windows (you might have to view the full images to see it clearly).

[attachment=29004:finalimage.png]

Here are the normals of the GBuffer. Notice that the same erroneous texels are grey, which is the clear value (I clear to 0.5 because in [0,1] that corresponds to the zero vector in [-1,1]).

[attachment=29005:gbuffernormals.png]

I understand that a fragment is generated by the rasterizer if the center of the pixel is contained in the triangle, and for this reason it seems that the center is inside neither of the triangles. Could this happen if due to precision problems the triangle edges are very close to the center of the pixel but not quite overlapping it? Note that this is a very rare case with several pixels in a row; usually it's a few single pixels scattered all over the image at places where triangle edges meet.

Has anyone else stumbled upon similar issues? How could these holes be fixed? If I have a dark indoor environment and a bright sky it's a very annoying artifact when a few bright pixels appear and disappear at random locations when moving the camera.

Advertisement

That can happen with "T-Junctions" in the mesh, where a vertex is located on the edge of another triangle (instead of at one or the other endpoint)

Also if you render both faces of the triangle then winding order differences can be an issue I think but if you only render one face that cant happen (within a single mesh).

o3o

That can happen with "T-Junctions" in the mesh, where a vertex is located on the edge of another triangle (instead of at one or the other endpoint)

I took a look at the mesh in wireframe mode and while these pixels lie on a triangle edge, there's no vertex there.

Are the vertex positions exactly equal?

One way to guarantee this is if you use indexed mesh and both triangles index the same vertex.

o3o

Are the vertex positions exactly equal?

One way to guarantee this is if you use indexed mesh and both triangles index the same vertex.

I'm not quite sure how to verify that. The mesh comes from an obj-file so the positions ought to be defined once and then indexed. Since I can't make an index buffer for every attribute I have to duplicate some data, but that's all I do. There's no modification of the positions, they are just copied.

Another thing I observed is that the holes don't seem to appear on the edge of adjacent triangles in a quad, but rather on the edge of the quad itself. Not sure if that helps though.

I tried scaling up another mesh to see if the same issues appeared there (because it seems there's always a somewhat large triangle involved) but I couldn't see anything similar. An online viewer of the mesh showed the very same kind of holes that I see in my application, so I'm really starting to think it's the mesh itself that's faulty. If it's the mesh that's bad, then it could very well be that positions are duplicated in the file and not quite equal. I'll have too look into this in more detail.

Edit: I started to look inside my obj-file and found that about half of the vertex positions were duplicated, but I couldn't find any vertices that were the same apart from small rounding differences. Nevertheless, I found it odd that positions were duplicated (after all, the obj-file uses indexing so there really is no reason for any attribute to be duplicated in the file) so I began googling for things releated to unreal editor and duplicated attributes. I found http://irrlicht.sourceforge.net/forum/viewtopic.php?f=2&t=31090 which describes the issue I'm having. At first I thought you meant that the holes would appear on the T-junction, but the last post of the linked topic made me understand that the entire edges may go "out-of-sync" because the vertex at the T-junction may not lie exactly on the larger edge. It also explains why I don't see holes on the edges inside quads.

[attachment=29021:finalimage2.png]

[attachment=29022:finalimage2wireframe.png]

In case somebody else stumbles upon this in the future these images might help. Consider the wall between the two windows. The holes do not appear at the T-junction itself, but because the vertex at the T-junction might not lie exactly on the roof triangle edge, the wall triangle edge is not perfectly synced with the roof triangle, causing holes.

Now the question is, how would one prevent this? Is it perhaps due to bad triangulation in UnrealEd (which is what I used to create the mesh)?


the entire edges may go "out-of-sync" because the vertex at the T-junction may not lie exactly on the larger edge

Wow. I like that simple explanation a lot. I tried to make sense of this once, but it's way too tedious, and you'd have to be a genius to figure out the side-effects of T-junctions from all that.

This topic is closed to new replies.

Advertisement