Speed with different geometry types

I have a program that pushes out 1.2 million triangles a second and another which does 100 thousands tris a second using the same base code but a slightly different rendering engine on my p3 600, 128MB with a TNT2m64 32MB. The slower one loads Unreal maps and contains a mixture of 3, 4, >4 vertex polygons, draw with tris, tris-strips, and polygons( some have 12 or more vertices and can’t be put in a tri-strip/fan). The fast program only has triangles but are called multiple times (for each tri a glBegin is called). The fast prog has a display list to render the slow does’t and there ends the differnce why? So I made a test: an array of 100 * 100 was made and rendered at a failry flatish angle to the camera with the whole lot in view. The surface area was thus small and so so texturing speeds and fillrates weren’t tested (this will be done soon). Each quad is rendered seperately in a for loop and so no strip could go along one full axis-only rendering a quad. Here are the results:
multiple calls to GL_POLYGON = 56 FPS
multiple calls to GL_QUADS = 55FPS
single call outside loop to GL_QUADS = 75FPS
multple call GL_TRIANGLES (2 per quad *num quads) = 30FPS
single call to GL_TRIANGLES outside loop = 50 FPS

multiple call to tri-strip to draw each quad = 56 FPS

The same each in a display list:

multiple calls to GL_POLYGON = 54 FPS (SLOWER)
multiple calls to GL_QUADS = 57FPS
single call outside loop to GL_QUADS = 100FPS
multple call GL_TRIANGLES (2 per quad *num quads) = 45FPS
single call to GL_TRIANGLES outside loop = 38 FPS (A LOT SLOWER)
multiple call to tri-strip to draw each quad = 60 FPS

This seems to show that GL_QUADS are the best, I thought that the TRI_strip would be the best. Additionaly why are some things in the display lists so much SLOWER such as normal triangles. You can see for your self from the results the questions I have. What should I use? Next I need to look into CVA and so on, On my TNT2 I was under the impression that display lists should be faster? DrawElements with tri-strips should be fast though?

One last question, has anyone here worked with the unreal map exported .t3d format, I have looked into it before and told people to use it but now I am starting to use I have found some problems. Such as polies with more than 4 vertixes and so need to be drawn with GL_POLYGON, this also messes up back face culling.Some times a simple quad pland like the side of a cube gets split into strange triangle like arrangments (that are sort of convex) and so aren’t drawn correctly when called from tri-srip or GL_POLYGON etc.

I see no reason for triangle strips to be faster than quads in this case. Drawing two triangles with a strip takes four vertices, same as a quad.

But I agree that it’s strange how slow the triangles display list is.

Tri-strip[s hsould be faster than a quad because a quad has to be split into 2 triangles and so this will be slightly slower- this is seen in the display lists but the non dis-lis versions tris strips are slower than quads. I know that the best yse of tri strips are if they are in long strip but you usualy can’t use them that way. I will add a tri-fan and then some CVA type stuff.

One optermisation I have thought of the my unreal rendering is ordering the pollies by type, but this will only speed up the triangles since one call to glBegin is needed. I also need to check how much of a difference binding a different texture every time is and if I should sort out the polies by texture.


I have updated my speed tester app to use also use vertex arrays, currently it only uses glArrayElement which I know is crap but even so I was surprised to see that all geometry types drawn were slower using this vertex array. Every test was about 10% slower! Also I found that triangles fans are about 10% slower than tristrips when drawing a quad.

I have checked the code and it definately seems that use of a display list can slow down some geometry types such as polygons and triangles. This is particularly anoying!
I have the latest drivers from NV, don’t think there is a driver bug.