triangles vs. triangle_strip

Yes triangle_strips should be faster when rendering many tris.

"C lets you shoot yourself in the foot rather easily. C++ allows you to reuse the bullet!"

In my landscape I have chunk of 33*33 vertices, using tri strip instead tri list double the rendering speed (CVA or VBO used), so yes, there is definitly a big performance boost.

For the uninitiated, why are strips faster? Yes I can search Google but let''s have it here so that we can all learn together

Strips are faster because you only need to send one vertex to define the next triangle, and I believe the hardware is also optimized at handling that kind of data.

For a clearer understanding, write a software renderer, and write a triangle strip routine, and you'll see the kinds of values you can hold on to from the last triangle submitted. All those values need to be recalculated when you are just rendering straight triangles.

[edited by - Waverider on July 15, 2003 1:45:03 PM]

The more triangles you render the more triangle strips will be faster. For example:

Rendering 5 triangles without strips takes 5*3 = 15 vertices;
Rendering 5 triangles with strips takes 3*1 + 4 = 7 vertices;

Rendering 2000 triangles without strips takes 2000*3 = 6000 vertices.
Rendering 2000 triangles with strips takes 3*1 + 1999 = 2002 vertices.

You probably won''t notice if you aren''t rendering a whole lot, but once you start pumping up the triangles you can easily reduce your vertex count by 500%.

So for rendering terrain areas (like I am) strips are essential really? Nice to see some tangible numbers, thanks!

In the spec. of older cards (GeForce 2, GeForce 4MX) it is said that it can draw 20 MTris/sec, something like that. Newer cards however draw 150 (for example ) MVertices/sec. So this means that for older cards there is no speed difference if you use strips or whatever. Right?

"C lets you shoot yourself in the foot rather easily. C++ allows you to reuse the bullet!"

Anything you can do to reduce the geometry values sent to the hardware will improve speed. Always prefer strips over straight triangles. They are always faster in large quantity, no matter the processor, no matter the card.

[edited by - Waverider on July 15, 2003 2:24:16 PM]

quote:

---

Original post by Raloth
The more triangles you render the more triangle strips will be faster. For example:

Rendering 5 triangles without strips takes 5*3 = 15 vertices;
Rendering 5 triangles with strips takes 3*1 + 4 = 7 vertices;

Rendering 2000 triangles without strips takes 2000*3 = 6000 vertices.
Rendering 2000 triangles with strips takes 3*1 + 1999 = 2002 vertices.

You probably won't notice if you aren't rendering a whole lot, but once you start pumping up the triangles you can easily reduce your vertex count by 500%.

---

You're forgetting about indexed primitives and the vertex cache...

quote:

---

Always prefer strips over straight triangles. They are always faster, no matter the processor, no matter the card.

---

Wrong. You too, are forgetting about the famous vertex cache It's entirely dependent on your model. Sometimes, indexed strips are faster. Often, indexed strips and trilists are more or less equal (if everything is in VRAM). And sometimes, indexed trilists are actually faster than tristrips, because they make much better use of the vertex cache. That's especially important, if you use complex vertex shaders. Basically, vertex cache friendly trilists will reduce the amount of transformed vertices, compared to tristrips.

[Edit: stupid nested quotes]


[edited by - Yann L on July 15, 2003 2:27:26 PM]

quote:

---

Original post by Waverider
Anything you can do to reduce the geometry values sent to the hardware will improve speed.

---

not if youre fillrate-, cpu-, or whatever-bound. with 2byte indices the difference isnt that big, degenerate triangles will add slightly more traffic than necessary, cache optimized tri lists can sometimes still outperform strips AND something not mentioned so far i guess: the moment strips require additional drawing-calls when trilists can be done in one call its quite likely strips will actually be slower.

i definitely wouldnt do too much work just to get everything done with strips. they arent that much faster anymore.

and what if your mesh doesn t have neightbouring polygons everywhere?(touching on the edges)

how do you want to render this as a triangle strip

btw when i put the render geometry into the VID memory and draw everything as a large TRIANGLE vertex array i won t suffer fillrate problems due to function call overhead

quote:

---

Original post by Basiror
btw when i put the render geometry into the VID memory and draw everything as a large TRIANGLE vertex array i won t suffer fillrate problems due to function call overhead

---

How did you work this one out? You could render an entire triangle list in a single glDrawElements call.

Death of one is a tragedy, death of a million is just a statistic.

Anyone have some benchmarking programs to test this? I''ve been rather curious as to how strips and trilists compare in different situations. In the case of terrains, I would think strips would be the best way to go -- also quick and easy to program (unless you have LOD).

I''ve said it before, I''ll say it again, don''t waste your time on strips.

course people have told me I''m wrong before, and I am sure they will again...

IF you really care to see my reason, search for some posts of mine on the subject

Jeff

Indexed tri lists should be as fast as a tri strip (depending on the driver, of course) and will be far more to manipulate geometry with.

It''s usually good to test both on several systems and see what works.

quote:

---

Original post by python_regious

quote:

---

Original post by Basiror
btw when i put the render geometry into the VID memory and draw everything as a large TRIANGLE vertex array i won t suffer fillrate problems due to function call overhead

---

How did you work this one out? You could render an entire triangle list in a single glDrawElements call.

Death of one is a tragedy, death of a million is just a statistic.

---

if you have 2000 polygons with 200 different textures and render them as tristrips you first need to switch the textures 200 times
and then for each polygon you need a draw call

now lets say you place everything in a triangle vertex array

all you need is 200 texture switches and 200 drawing calls with GL_TRIANGLES

and using VBOs will speed it up anyways(someone came up with a speed comparsion some time ago )

this i only have 400 function calls
with tri strips i could have probably more than 2000
depending on the geometry you are rendering

quote:

---

Original post by Basiror
btw when i put the render geometry into the VID memory and draw everything as a large TRIANGLE vertex array i won t suffer fillrate problems

---

and what exactly does fillrate have to do with where and how you store your geometry or how many calls you need? the only way that comes to mind is draw fewer pixels, use less passes and do occlusion culling.