Hi everyone,
I’m working on custom geometry generation for a very minimal voxel engine (not true voxels technically speaking). On rendering stage I note some strange little holes like missing pixels on quad borders. They randomly appear and disappear when moving around. Has anyone experimented this issue? All vertex positions seem to be correct for me 
I’d like to be sure I’m not missing something when setting up vertex positions…
Thanks in advance…
My wild guess is bounding boxes…
It’s not bounding boxes but…
Now I’m afraid it has to do with some identical polygons occupying the exact same place, maybe some mismatch at depth buffer level. The strange thing is, even if there are two polygons at the same place, they are oriented in reverse to have always one of them culled, but I think that’s not enough and it produces weird rendering results on the corners where two or more quads touch themselves, I would need someone to please confirm this, I have not much experience with 3D graphics or OpenGL in general… Some behavior may seem odd to me but it’s in fact the expected default.
I’ll do some more testing on this…
And sorry for my English if there is any mistake, it’s not my native language…
Cheers!
Depending on how you generate the mesh it could be an artifact related to T-Junctions in the edges of your mesh. See https://0fps.net/2012/07/07/meshing-minecraft-part-2/ for a brief discussion (he concludes it’s not a problem, except possibly on some graphics cards, so this may not be the cause of your artifacts).
Looks like T-junctions. The cause of it is usually when you have two triangles with shared edge, but not shared vertices, and because of floating point precision error the edges don’t perfectly align and you get those epsilon gaps which causes these pixels (which are what you got from behind).
A solution is to detect those shared edges and split them to make sure all vertices are shared.
imagine both edges are overlapping:
v1._____.v2
v3.__________.v4
Edges are on the same line, but v2 and v4 aren’t at the same position, which causes precision error.
to fix the T-junction:
v1._____.v2
v3...v4
-----------v5
Added v5, which as the same position as v2, so the edges 1,2 and 3,5 use exactly the same vertex positions.
Yes, 90% sure that’s the case, thanks for the info, and I will have to deal with it as part of my poorly implemented but working greedy meshing method. Having tested on a cheapy integrated video board at work this problem is very visible, but there should be more factors related to this I think…
On a sidenote, if you look carefully, you can see the same issue on http://mikolalysenko.github.io/MinecraftMeshes2/ using “Sphere” as data source, but in his T-Junction test there isn’t any cracks because the mesh in the test is quite simple compared to the sphere, so maybe it is not a good test 
On a sidenote, if you look carefully, you can see the same issue on http://mikolalysenko.github.io/MinecraftMeshes2/7 using “Sphere” as data source, but in his T-Junction test there isn’t any cracks because the mesh in the test is quite simple compared to the sphere, so maybe it is not a good test
Probably just WebGL being WebGL, unless you’re referring to the Z-fighting when edges are rendered.
Not sure if this is only in custom geometry, I also noticed this on most PBR demos here.
sRGB and RGB mishaps perhaps? Hopefully … those minor goofs will cause mishaps with abrasive artifacts both high or low.
I don’t know, but I already posted an issue and sample hilighted it here. There’s a few more in there that I just missed out if you examine closely.
Thank you. The rects around artifact areas is helpful.
sure thing JSands, just trying to help out and see these bugs as I see it, particularly if it is included in the demos or latest commits.
