Long thin triangles

[SteveL]

In another thread:

The only concrete tip I can offer is that GPU's hate "long thin triangles" and shaders that call textures too many times.

 

The advice on long thin triangles is often mentioned, but I always have the same question in mind when I read it: how best to triangulate a long thin surface?

 

Easy enough to understand that for two triangles that have the same area, the graphics card will do better on an equilateral one than a long one. But usually the choice you're faced with is between two long triangles and twenty or so equilateral ones, like in the common case when you have to triangulate a long thin rectangle like the edge of a wall. What's better then?

[Atheran]

I'd say it depends on what you want to do. For a photorealistic render go fo the equilateral ones as you don't care for the polygon count. For a game, if I take these numbers as is I'd still go for twenty equilateral ones. Eighteen polygons are not something you should worry about. But if this is a mesh that appears several times in the rendered cell and those eighteen polygons become like 5-6k then there's a big difference in which you'll have to decide in favor of performance or visuals (keep in mind that twenty equilateral ones can be UVed much, much easier and textured as such).

 

And that's for DR in the way I understand it.

[Tels]

There probably is a mis-understanding here what long-thin triangle means. A triangle which is already long and thin, or one that appears long and thin on the screen. The latter can happen even if you view a triangle from a steep angle. Plus, "long" is rather relative.

 

Also, the size of a triangle matters if one triangle is hit by two lights. The tri in idTech4 is then rendered twice (for each light). If you cut it up in two tris, each tri is rendered once (for each light).

 

So, basically, avoid overly large (or overly long) triangles (beyond a few hundred/thousand units). But don't chop them up in 20 tris, because replacing them with twenty equilateral ones will not really help - it increases the triangle count, the edge count (and thus shader costs).

 

This article discusses a few topics:

 

http://www.andythoma...timization.html

 

See also: http://www.g-truc.net/post-0662.html

 

 

This might also be something we want to add to the engine in the future:

 

http://w3.impa.br/~d...SanNehBar07.ppt

 

While googling for the paper which explained the high overdraw due to small triangles (which I did not find again, sadly), I came across this:

 

http://wiki.thedarkm...tial_Must-Knows

Edited August 22, 2014 by Tels

[Atheran]

Alright I shut up

I didn't think of view angle I just thought about the big polygons, in which case I'd still prefer to retopo them even with higher polycount.You may have a point about shader costs but for vertices/edges/polys count it shouldn't be any problem if you get a couple dozen more of each. Unless you reuse it several times throughout the cell. Shaders might be a problem tho'.

 

Now I go back to try and do basic operations in DR and stop missreading posts way above my DR understanding

[Tels]

Hah, found it at least:

 

http://graphics.stanford.edu/papers/fragmerging/shade_sig10.pdf

 

This shows the effect of very small triangles (and why LOD models for far-away detailed mehses like our AI models are so important).

[SteveL]

Cheers. The take away message I saw in that paper was, reduce the account of triangle edge in view where you make a decision. Borders and small tris and two edges close together cause wasteful shading. It wouldn't have occurred to me either that a triangle seen edge on is equivalent to a long thin triangle, but it makes sense from the point of view of that problem at least.

[nbohr1more]

Yeah, I only knew of Humus's work on this:

 

http://www.humus.name/index.php?page=Comments&ID=228

 

which I linked in our Optimization wiki.

 

I don't know if dmap optimizes for "max area" triangulation but I believe it I've seen fan style triangulation in screens

for func_statics, thus models would have that advantage in optimization.

[demagogue]

I think of it like playing with triangle slivers is rolling the dice, so they shouldn't be unnecessarily or gratuitously made when they don't have to be -- like using the subtract tool when you can use the cut tool to do the same job. You should make them very consciously, for a specific reasonable thing that has no other way to make it, when you think the benefit is worth the cost, and you're ready to spend time fixing up any problems that might pop up.

 

It's not a hard rule you can never break, I think, just a rule of thumb people have learned from hard experience that will save a lot of avoidable pain in the long run.