Sign in to follow this  
nPenAPaT

Triangle Strips vs Quad Strips

Recommended Posts

Hi. I am making a terrain engin. So far it`s been going well but now I started thinking about optimisation. So which of GL_TRIANGLE_STRIP and GL_QUAD_STRIP is faster? I mean if I render the terrain mesh with Quad Strips will it be as fast as if I render it with Triangle strips?

Share this post


Link to post
Share on other sites
I've heard that many opengl implementations convert quads to triangles under the hood, so I doubt one will be faster.

If you really want to optimize your terrain, look at level of detail algorithms, like ROAM. And for that you'll actually need triangle fans.

Share this post


Link to post
Share on other sites
How will you render the mesh?
If you will use index based rendering, I've heard it doesn't matter.
In fact, render everything as GL_TRIANGLES as this will reduce your calls to glDrawRangeElements

A long time ago, someone benchmarked and said there is no diff between tri strip and quad strip, but that was a long time ago and things can change.

Share this post


Link to post
Share on other sites
Quote:
Original post by gharen2
I've heard that many opengl implementations convert quads to triangles under the hood, so I doubt one will be faster.
Definetly true! You can read more on the latest geometry shader extensions. There are no quads really.
Quote:
Original post by gharen2
If you really want to optimize your terrain, look at level of detail algorithms, like ROAM. And for that you'll actually need triangle fans.

I've spent a few time on ROAM and I never finished it. The involved effort wasn't simply worth it.
Consider in future APIs (D3D10 is already there, think at GL next-gen) there's a special IMMUTABLE flag for resources which I expect to be extremely helpful to HW. This will bump DLOD methods again!
If you need out-of-core, Hoppe's Geoclipmaps are easier and I expect them to provide considerably higher performance than ROAM (or even RUSTIC)!


Share this post


Link to post
Share on other sites
one thing you may wish to consider is to optimize your indexing to make it vertex cache friendly... even something as old as theoriginal GeForce had a cache of 10 vertices, the point being that if you for example draw triangles, a given vertex is used typically 4 times (i.e. in 4 different triangles) so the if you order your triangle so that the vertices stays in cache you can potentially increase the geometry output, there are 2 source files I have found on the web, one from Nvidia: "NvTriStrips" go to developer.nvidia.com to find it and TriStripper at:

http://users.pandora.be/tfautre/softdev/tristripper/

[Edited by - kRogue on May 7, 2007 2:02:11 AM]

Share this post


Link to post
Share on other sites
Thank you everyone for your replies. I made my program to render the mesh with GL_TRIANGLE_STRIP.The result: a mesh 256X256 vertexes and the with good framerate (i didn`t put a FPS counter becasue there was no lag in the picture)So I need to ask you something else. If I make the whole mesh a display list and draw it without Vertex arrays will it affect the speed of the calling of the list ?

Share this post


Link to post
Share on other sites
if u care about speed u will needto break the terrain up into say 33x33 or 65x65 vertice sized patches + stick a boundingbox around each patch, this is gonna help much more than DL/VBO etc

Share this post


Link to post
Share on other sites
I do not have any benchmarks on which is faster, but in my experience QUAD_STRIP does not work as well for terrains because when you have a square on the grid where only point is elevated, like at the edge of a hill or a cliff, the quad will get "bent" and act weird/not always display properly. Technically this is because a quad must be coplanar, and a quad with three points on the ground and one point elevated is not coplanar; although gl will usually draw it anyway it causes problems.

If it were not for this getting bent I would probably use quads because it is less data to transfer to the card and I figure most likely modern cards can easily handle splitting the quads into 2 triangles when they receive the data, so better to send less data and let the GPU split the triangles than to do it yourself on the CPU and have to send more. However triangles are probably better anyway because most of the optimization algorithms like ROAM or "Terrain Simplification Simplified" assume your mesh is made out of triangles.

My terrain is in a list. Lists are a bit faster to call. Mostly though it will be faster because you will not have to recall your rendering function each frame. You will only have to call it once and then you can use the data it generates for many frames until something changes in the terrain (or you scroll a certain distance, assuming your engine works like mine where only a smaller visible portion of the map is rendered at a time. If you are drawing the entire map each frame then you will only to have to call your renderer once at startup).

I would advise you though to put a FPS counter on your program. Just because there is no lag does not mean you should not do this. It is very handy for keeping track of how much impact this or the other thing you changed had on the algorithm, and will allow you to catch bad ideas long before they are actually visible in the engine. Without a counter you will not notice the difference between terrain taking 4 milliseconds to draw and 16 milliseconds to draw because they are both totally smooth. But 16 milliseconds is 4 times slower than what you had before and you change something that makes it jump like that you want to notice it right after you do it and not way later on when it starts causing lag and you've forgotten about it.

You can easily make a counter to track something I call "blitms", just call some timestamping function like SDL_GetTicks() or whatever the equivalent is for your library before you do your RenderScene, then when RenderScene returns call the function again and find the difference between the two. I get about 3-5 blitms on my engine with only terrain visible, about 15-18 with objects in the scene. I have a laptop though and it has kind of a sucky accelerator so yours may be faster than that.

[Edited by - surogue on May 8, 2007 11:51:31 AM]

Share this post


Link to post
Share on other sites
Thank you surogue for the answer. I will consider putting a frame counter but I think i will use the standart Frames per Second.
And about the splitting of the terrain. I really considered that but I think that it wont look nice. If I have a straight terrain (no fog) I should see a verry large distance. And if I cut the terrain in small pieces it will just jump out of nowhere when I reach a particular point at which I will draw it. I then thought that i should draw all terrain near my position:

00000 X- my position
01110 1- peaces of the terrain that should be rendered
01X10 0-not rendered
01110
00000

But wont this be slower than if i just render the whole thing ?

Share this post


Link to post
Share on other sites
Quote:
Original post by nPenAPaT
But wont this be slower than if i just render the whole thing ?


Depends,
the act of deciding which sections to draw takes up CPU time in your program
while the actual drawing is your 3d accel card

So depending on how busy each one is compared to the other, it may or may not be worth your while to do such visibility and LOD culling.
Try doubling your terrain size (4x the triangles).


For your specific method though, of only rendering the 'sectors' around the camera; it could easily be accomplished using a few mul/divisions to find the index range to display in your terrain heightmap. So it costs nearly nothing and is easy to build; it won't hurt anything.

And yes, fog is very useful for avoiding the terrain 'popping' problem when it changes.

Share this post


Link to post
Share on other sites
Quote:

And about the splitting of the terrain. I really considered that but I think that it wont look nice. If I have a straight terrain (no fog) I should see a verry large distance. And if I cut the terrain in small pieces it will just jump out of nowhere when I reach a particular point at which I will draw it. I then thought that i should draw all terrain near my position:

WRT splitting it into pieces
visually there is absolutly no difference, theres no need for fog (things will not jump out of nowhere)
for each patch u test if its bounding box intersects the modelviewfrustum if so draw it.
the only difference WRT splitting it into patches is the framerate will increase 3x in speed (on average)

Share this post


Link to post
Share on other sites
Quote:
Original post by gharen2
If you really want to optimize your terrain, look at level of detail algorithms, like ROAM. And for that you'll actually need triangle fans.

ROAM is almost always the wrong algorithm to use. It is an elegant algorithm and easy to understand, but it is basically obsolete. ROAM does not use triangle fans (well, I guess maybe it could). You are probably confusing it with Röttger, et al, "Real-Time Generation of Continuous Levels of Detail for Height Fields".

As a first attempt at terrain LOD, I recommend learning geomipmapping.

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBolton
ROAM is almost always the wrong algorithm to use. It is an elegant algorithm and easy to understand, but it is basically obsolete. ROAM does not use triangle fans (well, I guess maybe it could). You are probably confusing it with Röttger, et al, "Real-Time Generation of Continuous Levels of Detail for Height Fields".


You're absolutely right, that is the algorithm I was thinking of. My apologies.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this