Jump to content
  • Advertisement
Sign in to follow this  
Prozak

Triangle Strips: Still worth the trouble?

This topic is 5401 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So, I've got a good VBO pipeline in my engine, and a good file format to go with it, and I was wondering if Triangle Strips are worth another layer of code. After a good VBO implementation, do TS bring an added speed increase? or do graphics cards nowadays already process the vertices in such a way that it really does not matter? As a side question, if you do use TS, what do you use to generate them?

Share this post


Link to post
Share on other sites
Advertisement
Well, it really depends on the bottle neck, however I would say its a good idea simply by refering you to page 17 of the all Holy and Great OpenGL Performance Tuning PDF (see sig for pdf and video link).
From the video you also get that NV cards prefer triangle strips while ATI cards perfer triangle lists in strip format.

NVTriStrip is the program mentioned on the pdf page for stripping data, and i think ATI have their own tool as well which is mentioned in the video.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I would just use DrawElements/DrawRangeElements and be done with it. The post transform cache on nVidia and ATI cards more often than not bypass any advantage of doing strips. Now, if your mesh has no vertex sharing what so ever, a strip may be a better performer. Note: the post transform cache is even more important the more complex your vertex shader becomes.

However, has _the_phantom_ alluded to, most game environments are heavily fill limited (as opposed to geometry limited), so I'd just pick the easiest approach and go with that. The easiest way to check your bottleneck in OpenGL is to turn on glEnable(GL_CULL_FACE) and glCullFace(GL_FRONT_AND_BACK). If your frame rate stays the same, you are geometry limited.

Share this post


Link to post
Share on other sites
on my gffx5200 (about 2 weeks ago)

i changed some code that was drawing heaps of objects of ~100 x 20 quad, quad strips in immediate mode. (2000 quads)
to one vertex array, GL_TRIANGLES.
it slowed down ~20%.

though in a real world case (and not like what i was doing a scene with LOTS of polygons) there should not be much difference between the two, the bottleneck is elsewhere.
but yes strips are usually(always) faster, less data

Share this post


Link to post
Share on other sites
AP: if a mesh has no vertex sharing, how will you form your strips ? With degenerated triangles ? It's likely to be ALOT slower.

The real question is, given a mesh, what is the size of strips you can form ? If all your strips are 6 triangles, using triangle lists with the index cache is going to be much faster - simply because of the glDraw[Range]Elements call CPU overhead. If all your strips are 1000 triangles, then stripping is going to be very interesting.

The best solution is to use a mix of the two: generate as many strips as possible bigger than a fixed size (ex: 256 vertices); and put all the rest in a large triangle list.

If your meshes don't have long strips, it's better to not bother and to use triangle lists everywhere. It will simplify your rendering code.

Y.

Share this post


Link to post
Share on other sites
Tri strips can help...but they're not worth as much effort as they used to be. If you can easily remodel your data into tri strips, go right ahead and do it. But if you need to fall back to complex algorithms for creating mesh strips, your gain/loss is going to fall off very quickly.

This is one of those things that probably isn't worth considering, ever. Make an initial design decision and stick with it. With indexed tri lists vs indexed tri strips, the only thing, and I mean the only thing you gain with strips is that you send less indices across the AGP bus. Unless you're bandwidth limited (very rare), you gain nothing. Indices aren't that big to begin with, doubly so if you're using 16 bit.

Some people will claim that using tri strips allows efficient use of things like the post TnL cache, but usually this is more dependent on the format and ordering of your data than the actual rendering mode. In fact, it can be beneficial to reorder your vertices than to bother stripifying the primitives.

Share this post


Link to post
Share on other sites
Just FYI, I did a performance test drawing 722500 triangles (texture mapped, no lighting or shaders), 100 triangles which were each made of 85x85 triangles, using VBOs. I tested it in 2 ways, doing triangles in rows from left to right, bottom to top, and doing it using a space filling curve (sierpinski gadget). I saw a very small performance boost on an nVidia Quadro FX 150, from about 36 to 39 million fps, but a much bigger jump on a Radeon 9700 mobile, from about 75 Mfps to about 95 Mfps.

The idea is that the space filling curve tries to maximize the vertex cache performance by always picking vertices which have very recently been used. If you're going to try doing triangle strips, I would suggest you consider the vertex cache, as it can make a considerable difference.

Share this post


Link to post
Share on other sites
Triangle strips were preferd becouse of their almost inplicit cache friendlynes. If you use indexd triangles you can probably rearange triangles(indices) to be more cache friendly than any tristrip, but you might have to use some new algoritems. Even the simple greedy algo can perform very well. The size of index buffer is hardly the thing to change your speed. One hidden cost of using triangle strips is also call overhead. Until we have zero-cost degenerated triangles or implemented primitive reset functionalyity you have to resort to multiple draw calls, since you can't stripify each model in one long strip. Not to mention that using triangles only simplyfies engine desing. All in all I think cons outweight pros and so I just use triangles in my engine.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!