I have read many of the posts. I have read the reply by ReJ. I have googled. I have talked with engineers.

My conclusion is that the number of triangles reported in the stats window is incorrect OR the triangle stripper is broken. I hope to either be corrected or have the problem corrected. The former would be the easiest!

Attached is a test case for you to try. It is a simple .obj with 4 triangles and 12 vertices. If you import this into Unity Iphone and smooth the normals you will see 6 vertices with 5 triangles. This means that overlapping vertices were combined and the tri-stripper made 1 degenerate zero-area triangle. It should be able to have 0 degenerate triangles with this triangle pattern.

If you import this .obj without adjusting the normals you will correctly see 12 vertices in the stats view: 4 triangles x 3 vertices. However, you will also notice 19 triangles in the stats view. That’s 4 real triangles, and 15 degenerate zero-area triangles generated by the tri-stripper. There are three connections to make a strip out of 4 triangles: connect the 1st to the 2nd, connect the 2nd to the 3rd, and connect the 3rd to the 4th. That means each connection has 5 degenerate triangles.

Sure, degenerate triangles are discarded. This does not mean that they are free.

This is one of those times not having the source code makes understanding the issue very difficult. I had to reduce the issue down to a simple test case after I, like all of you, saw a simple 400 triangle object explode to over 1,200 triangles with a single pass and smoothed 180 degree normals.

Why is the tri-stripper unable to strip 4 triangles together with no degenerate triangles when the pattern of the triangles should allow for zero degenerate triangles? Why does this test case have 15 degenerate triangles when there are only 4 real triangles?

Finally, consider this case: 100 triangles with 2 passes. Let’s say there are 50 degenerate triangles. The stats window would report 300 triangles. That’s 100 real triangles + 50 degenerate triangles, twice. My gripe is that it becomes unclear in “normal” scenes which triangles have to be rendered and which triangles are degenerate. It is important to distinguish them because they do not carry the same weight in terms of cost. It would be much better to know that there are 200 triangles that the card will have to draw, and 100 triangles that the card will simply discard after realizing they are zero-area triangles. When it simply reports 300 triangles, it becomes unclear how many of those triangles get rendered and how many of those triangles get discarded beczause they are degenerate. As you all know, this is for an environment where each vertex and each triangle counts.

Thoughts? Corrections? Solutions?

What about index buffers instead of tri-strips? What about being able to disable the tri-stripper? Is 19 triangles sent to the card correct for this 4 triangle test case? How can that be?

321398–11335–$four_tris_become_nineteen_tris_185.zip (468 Bytes)