Thanks again, Martin and Omar, for your suggestions! I picked up a lot of information while browsing Reddit and Discord afterwards, so I thought I’d pass on what I found in case it’s of any use…sorry if you already know this..
Here’s why a pole with 20-22 edges (I have in my mesh) converging on one point is a problem…
Reason 1 — small triangles waste shading work on their own. A GPU never shades a single pixel by itself; instead, it always processes pixels in fixed 2×2 blocks. If a small triangle only covers part of a block, the GPU still performs the shading calculation for the entire block and then discards the pixels which weren’t actually part of that triangle. Thus, thin slivers waste a portion of every block that they only partly touch.
Reason 2 — overlapping triangles cause the same pixel to be shaded more than once. If a large number of thin triangles all come to a single point, then they all overlap the same small area of the screen. To determine which of the triangles is actually visible at that location, the GPU has to carry out the complete shading calculation (including textures and lighting) once for each of the overlapping triangles; as a result, a pixel lying under eight overlapping triangle slices is shaded eight separate times even though the calculation could have been done just once.
The reason for fixing this by dividing the pole into a number of smaller ones is that a GPU isn’t a single processor working through a queue; rather, it has thousands of small cores, and different groups of these cores are each in charge of their own section of the screen. When one pole is crowded, all that overlapping has to pass through a single group in sequence, while the rest of the chip does nothing. By splitting the geometry into a few separate parts, different groups of cores can work on different sections at the same clock cycle rather than having to wait for one another in a queue.
As for the cost involved with geometry — there is one, but it relates to a completely different stage and the extent of that cost is important. There is a previous stage known as Primitive Assembly which links the vertices together to form real triangles, and unlike vertex processing (which is cheap and truly parallel), this particular stage has a strict, fixed rate limit — only a small number of triangles can pass through it per clock, no matter how powerful the GPU is. Yes, breaking a pole does mean that a few more triangles have to go through that stage. But this is a very small increase when compared to the number that would be enough to saturate it…. a problem of this kind only arises at extremely high numbers, for example with millions of sub-pixel-sized triangles. Therefore the slight extra cost in this case is negligible, while the savings from redundant shading as mentioned in Reason 2 can be significant, particularly when dealing with a more expensive material.
The final point to make is that having a single mesh with a pole attached in this way won’t cause any problems with the framerate. A single frame has a fixed amount of time available (for example, 10ms at 100fps), and the redundant shading from one pole takes up a tiny and essentially undetectable portion of that. The issue only becomes apparent when this practice is repeated across many meshes in a scene if hundreds or thousands of objects all perform this small amount of wasted work, together they begin to take up a significant part of that fixed time budget. It’s the same kind of calculation as one tiny triangle being harmless while millions of them (as in a “one triangle per pixel” test) cause the framerate to collapse — although the cost of each individual case is negligible, it increases linearly with the number of times the action is repeated, and a full game level involves repeating such actions many times.
So I just gotta fix that specific issue for the sake of good practice…but otherwise most people also said it’s fine..
Thank you martin and omar as always..
