Jump to content
  • Advertisement
Sign in to follow this  
LPVOID_CH

Terrain: Triangles or TriangleStrips?

This topic is 3867 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

hi all i'm improving my terrain engine. i know that triangle strips are handled faster on the gpu than triangle lists. but i'cant represent my terrain with only one indexbuffer, if i use triangle strips. for each terrain-row i need a index buffer and have to call this buffer for each row in my programm. with triangle lists i can put all in one vertex/indexbuffer and call this buffer once for the terrain. does anyone has experience which of them could be faster? i couldn't find anything about that in the web. thanks

Share this post


Link to post
Share on other sites
Advertisement
You can use degenerate triangles that have two vertices with the same index to patch multiple strips together. Be sure to test if you actually get any speed up though. It's probably going to be quite small.

Share this post


Link to post
Share on other sites
ok, this would be an idea, but i don't like things like degenerated vertices. i'm porting my engine to XNA, so i don't know how XNA handles degenerated vertices.
thx for the approach

Share this post


Link to post
Share on other sites
Quote:
Original post by LPVOID_CH
i know that triangle strips are handled faster on the gpu than triangle lists.
Wrong. The best transform ratio (physically transformed vertices / triangles count) you can get with tri-strips is asymptotically near 1.00, whereas with tri-lists you could get the ratio down to 0,52.

If it`s not obvious by now, this means that you can make the card render 1000 tris with only 520 transforms by Vertex Shader.
Compare this to 1008 transforms for tri-strips or 3000 transforms for non-indexed tri-lists.

Of course, you must rearrange the vertices so that they stay in cache as long as possible so you can reuse as much of them as possible.

Then again, it`s easy to do for terrains, but not so easy to rearrange them for any regular 3D mesh (there are some utils from card vendors, though). However, these days, when you can easily push up to 10M tris per scene, it`s not really that much needed, unless you _REALLY_ want to push on screen as much vertices as possible. With basic LOD, you can get a really nice and dense terrain with long view distance easily under 1M tris, which is nothing these days.

You`ll hurt the performance MUCH more if you`ll start using more streams for your terrain. Try to aim for less than 3-4, even at the cost of duplicated data.

Share this post


Link to post
Share on other sites
Quote:
Original post by joe1024
Of course, you must rearrange the vertices so that they stay in cache as long as possible so you can reuse as much of them as possible.

For big terrain patches, you could use a Hilbert curve for this.

Share this post


Link to post
Share on other sites
Quote:

Wrong. The best transform ratio (physically transformed vertices / triangles count) you can get with tri-strips is asymptotically near 1.00, whereas with tri-lists you could get the ratio down to 0,52.


well, i always read in books/articles that tri-strips are faster than tri-lists. if this is true, i'll go ahead with tri-lists.
i don't use LOD because the LOD calculation on the CPU is slower than cashing whole terrain patches in the g-ram. my engine is also for FPS, so you can't look very distant like in a flight sim.

Quote:

For big terrain patches, you could use a Hilbert curve for this.


can you explain your aproach a bit more in detail or refer to an article about this?

Share this post


Link to post
Share on other sites
Quote:
Original post by joe1024
The best transform ratio (physically transformed vertices / triangles count) you can get with tri-strips is asymptotically near 1.00, whereas with tri-lists you could get the ratio down to 0,52.

How did you get this? I can understand that if the cache is large enough to hold vertices of one row, it won't make any difference which you use, strips or lists, you get about 0.5 . But if the cache is not that big, I'd really like to know how you can easily arrange a list to get a ratio of 0.52, no matter how big the grid.

Share this post


Link to post
Share on other sites
Quote:
Original post by LPVOID_CH
ok, this would be an idea, but i don't like things like degenerated vertices. i'm porting my engine to XNA, so i don't know how XNA handles degenerated vertices.
thx for the approach


It handles it very well. I've implemented a terrain engine in XNA that supports triangles lists and triangle strips without much problem. By the way I've profiled the engine and I've not found any noticeable difference between the two approaches. But i'm using only two vertex buffers and one index buffer for all the terrain...

Share this post


Link to post
Share on other sites
Quote:
well, i always read in books/articles that tri-strips are faster than tri-lists.
Of course. All literature for beginners should say that, beacuse otherwise they would have to start explaining it in more detail which would just utterly confuse/scare off the beginners. You can`t realistically expect to learn the advanced tricks from place which introduces you to basic concept of indexing, can you ?
Plus, not everybody knows of that. I too personally have seen many people not aware of this "trick", although they were quite competent otherwise.


Quote:
i'm porting my engine to XNA, so i don't know how XNA handles degenerated vertices.
What does that have to do with XNA ? You`re confusing API with basic 3D concepts. Check the underlying architecture of Xenos to see similarities.

Quote:
Original post by SnotBob
How did you get this? I can understand that if the cache is large enough to hold vertices of one row, it won't make any difference which you use, strips or lists, you get about 0.5 . But if the cache is not that big, I'd really like to know how you can easily arrange a list to get a ratio of 0.52, no matter how big the grid.
Personally, I`ve reached only the ratio of 0.56 with my own pattern. Only later, I`ve read here on gamedev one thread where one guy showed a way how to get the ratio of 0.52. However, I must admit I wasn`t bothered to try to implement his approach, because frankly, whether it is 0.52 or 0.56, it doesn`t matter at all. It`s still ~twice as much as compared to a no cache-friendly-indexing. 5% more or less - I couldn`t care less.

As to other part of the question - it doesn`t matter if the row fits to cache, since my indexing pattern isn`t based on rows at all - it`s of a completely different shape (no, not even a Hilbert curve), but I can easily traverse whole terrain chunk with it.

I should probably write a paper on it, since I haven`t seen it anywhere on the net. But since eventually a 4% faster approach was discovered, I couldn`t be bothered to devote some time the paper.

[Edited by - VladR on June 4, 2008 2:19:34 AM]

Share this post


Link to post
Share on other sites
Ok, I think I get it now. I wonder why I've not come across this before. Even a simple zig-zag pattern will get a ratio of about 0.75 . Seems to me that a simple, but reasonably good approach is to grab a suitably thick strip of Hilbert Curve -like curlies and lay the whole grid with those.

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!