Quote:Original post by Basiror
@trienco: could you please elaborate why index triangle strips optimized for vertex cache efficiency should be the last option for pipeline optimization?

Because if you did everything else and all the more major stuff, they are unlikely to make any difference. With heavy texturing going on, using VBO, etc. the shortest plank in your barrel is most likely NOT vertex submission and experience usually shows that making the long planks even longer still won't let the barrel hold more water. It's like one part of the pipeline is working like mad, just to get a 5min break after each step to wait for the others to finish their job, too.

Quote:I held a seminar about vertex cache efficient triangle strips last winter and I can t agree with statements that claim that index triangle lists sorted for vertex cache efficiency can perform nearly as fast as optimized tri strips.

Now, if you're going to say that you used non trivial shaders and not just "naked" unlit and completely "unrealistic" polygons (and probably immediate mode or vertex arrays on top of it), I'm definitely interested in numbers.

But my previous terrain renderes showed exactly no difference between even "non-cache optimized tri lists" and all as one big strip, each row as a strip and everything else I tried, simply because there were about a dozen other places in the pipeline that took longer anyway.

Quote:The only reason I see that one should start with index tri lists is because almost all index tri strip generators require exactly this storage format for strip generation.

Because it's easier and you won't need to wrap your head around alternating winding orders and placing your degenerate triangles just the right way? You can still start reodering your vertex and index buffers when the terrain is completely finished.

Quote:Original post by mrbig
A. Since I'm doing everything inefficiently, this is exactly the time to test how minor optimizations affect the overall performance.

And will give you numbers, that are pretty much meaningless for a setup that isn't inefficient to the core. With immediate mode and without any texturing it actually DOES matter to send as few vertices as you can, because your CPU is hand feeding the card and it takes forever. It's the shortest plank and making it longer will make a big difference. In a realistic setting vertex submission most likely won't be the problem and what made things go 300% faster will now make about 0% difference.

Quote:Oh and another thing, how do you guys associate a 256x256 texture on a huge terrain with "detail"? ;)

I associate either a much larger texture or tiled detail textures with detail. Of course putting a 256x256 texture on a 256x256 terrain is kind of silly, at least if the color is just a function of position (which isn't exactly giving your artists a lot of flexibility)

Quote:I'm going to use texture splatting and detail maps, so having defined the general colors of the map also allows me to use greyscales for the textures and detailmaps themselves, which means a little bit less data on the hard-drive and GPU RAM.

You need to think a bit further. It means blending together 4 detail textures with a single dot product AND let's you store them all in a single texture, meaning 2 look ups and one dot product, instead of 5 lookups, 1 mul and 3 mads. However, the result tends to look a bit boring, because you can't have colored detail anywhere. No nice green and yellow grass for example and the base texture doesn't remotely have the resolution to pull it off. Clipmapping might be something to look into.

[Edited by - Trienco on June 26, 2006 12:22:38 AM]

mrbig: nice terrain anyway :). I'm also working on a terrain generator here. I use triangle strips and Display Lists. First time I read about VBOs and my red book has no index entry to it(!!) but from what I've read from the posts here I understand VBOs are simply to move vertex datas to the graphics card and avoid sending them all the time. So, I suppose this can be mixed with display lists as they are completely different processes. Is this right? Do I have interest to do that mix?

Now a sub-question as we are about terrains: My terrain generator must have a system that provides a stepped coloring depending on height. Simply put: over a certain height, draw in one color, above another one, draw with another color, etc. I tried both vertex coloring (glColor()) and clipping (set a color, draw the scene with a clip removing everything not in the desired height. redo this for another color, etc.) and clipping is really the nicest result. Now, can one think of a cleaner approach, maybe avoiding rendering the scene n times where n is the number of colors?

Quote:Original post by Trienco

Quote:Original post by Basiror
@trienco: could you please elaborate why index triangle strips optimized for vertex cache efficiency should be the last option for pipeline optimization?

Because if you did everything else and all the more major stuff, they are unlikely to make any difference. With heavy texturing going on, using VBO, etc. the shortest plank in your barrel is most likely NOT vertex submission and experience usually shows that making the long planks even longer still won't let the barrel hold more water. It's like one part of the pipeline is working like mad, just to get a 5min break after each step to wait for the others to finish their job, too.

Quote:I held a seminar about vertex cache efficient triangle strips last winter and I can t agree with statements that claim that index triangle lists sorted for vertex cache efficiency can perform nearly as fast as optimized tri strips.

Now, if you're going to say that you used non trivial shaders and not just "naked" unlit and completely "unrealistic" polygons (and probably immediate mode or vertex arrays on top of it), I'm definitely interested in numbers.

But my previous terrain renderes showed exactly no difference between even "non-cache optimized tri lists" and all as one big strip, each row as a strip and everything else I tried, simply because there were about a dozen other places in the pipeline that took longer anyway.

Quote:The only reason I see that one should start with index tri lists is because almost all index tri strip generators require exactly this storage format for strip generation.

Because it's easier and you won't need to wrap your head around alternating winding orders and placing your degenerate triangles just the right way? You can still start reodering your vertex and index buffers when the terrain is completely finished.

In other words, the optimization for indexed vertex cached optimized triangles will hardly pay off since computation necessary to process a vertex is pretty low in static geometry, as long as other parts of your rendering process are complex enough.

Did you do s early z fail pass and several shadowing passes for per object realtime shadowmap? There tri striping and optimizing would certainly pay off depending of mesh complexity


So when rendering pure unlit unrealistic polygons tristriping and optimizing for vertex cache efficiency theoretical should still be faster than vertex cache optimized indexed triangle lists although the speed difference decreases every generation of new 3d accelerators.

Quote:Original post by amnesiasoft
methe: you could try using a shader, that should work nicely for what you're doing.

hmm. I don't think I will dive into the 800pages orange book about shaders sitting on my desk if I don't know whether I'd get significantly faster result. I guess where I loose time is in the clipping mathematics more than drawing the scene 3 times as each time the scene is incomplete (only one color level is drawn). Can you give me good reasons to jump into the shaders book? :)