How many polygons, how many vertices? A test.

[mkultra333]

Ever agonize over how many polygons to use in your model? I do, and here's a test I did.

I'm making models for my game, been doing it on and off for a while. Tend to make a model, end up hating it, and rebuilding it again. Since I'm a "programmer artist," this is a painful process. Made the mistake of being too low poly in the beginning, since I'm ancient and was mentally mired in the old ways. Been upping the polycount each modelling iteration since. But how much is too much?

I actually focus more on vertex count. Fragment shaders are more about fill rates and the amount of screen a model takes up, rather than how many triangles there are. Vertex shaders on the other hand are all about vertex counts.

My system is a GeForce GTX560 SLI system, so not too bad. My test model has 5300 vertices per monster (6000 polygons), as read from the mesh.xml file. There are a lot of sharp edges and UV splits, I could optimize away about 1000 vertices if I wanted by having less sharp edges and less UV splits, and have the same polycount, but possibly loose a little bit of quality... maybe not. There are 7 monsters per mesh to cut down on batching, so with a limit of 65536 verts per mesh, the most verts per monster would be 9362. (Models can have more than 65536 verts, but need 32 bit indices instead of 16 bit indices.)

I wondered if I'd gone too far in the other direction, too many verts and polygons. Decided to test. Set up a scene with 126 monsters and a set camera position looking at them. This is far more than I'd use in a real game, where there'd typcially be maybe 16 monsters on screen, or maybe 32-48 in a really heavy battle scene. The frames per second with 126 monsters drops to about 16 fps, but most of that is spent on CPU physics. I check the GPU render time seperately.

Made 4 versions of the model with different numbers of vertices, and then checked the GPU rendering times. Note that the only difference here is vertex count. Batching, materials are the same, and screen coverage is virtually the same. (Different models mean marginally different area covered, but practically speaking it's identical.)

Code: Select all

 50% (2650 vertices per cyborg) = 4.4        milliseconds total GPU time.
 75% (3975 vertices per cyborg) = 4.5        milliseconds total GPU time.
100% (5300 vertices per cyborg) = 4.5 to 4.6 milliseconds total GPU time.
175% (9300 vertices per cyborg) = 4.5 to 4.6 milliseconds total GPU time.

So the vertex count (and poly count) made virtually no difference. I could even up the vertex count, although I won't, I'll save them for extra verts in the environment. I've yet to test this on a lower end system, I have a laptop I can try later with a smaller ATI card. Not an integrated graphics system though, I imagine on one of those the vertex count would make much more of a difference. But I don't target them anyway.

Edit: Did some more tests out of curiosity, to see at what point vertex count made a difference. I altered the meshes so that there was only one monster per mesh instead of the usual seven, which means worse batching but a higher possible max vertices. I then made versions that had 16000, 32000 , 40000, 48000 and 64000 vertices.

Note that the numbers below aren't directly comparible to those above due to there being roughly 7 times more monster batches, even though there are still 126 monsters.

Code: Select all

 100% ( 5300 vertices per cyborg) =  7.9 to 8.0  milliseconds total GPU time.
 300% (16000 vertices per cyborg) =  7.8 to 7.9  milliseconds total GPU time.
 600% (32000 vertices per cyborg) =  7.9 to 8.0  milliseconds total GPU time.
 750% (40000 vertices per cyborg) =  9.7 to 9.8  milliseconds total GPU time.
 900% (48000 vertices per cyborg) = 15.9 to 16.0 milliseconds total GPU time.
1200% (64000 vertices per cyborg) = 33.8         milliseconds total GPU time.

So higher vertex numbers (poly counts) made no difference up to 32000 vertices per model, but started having a negative impact after that. Goes to show that you can really go crazy with the vertex counts now, unless perhaps if you are targeting mobile devices or low end machines.

It also underscores the importance of batching. The 5300 vertex models, when done in groups of 7 monsters per batch, took 4.5 milliseconds. The same models rendered at only 1 monster per batch took 7.8 milliseconds.

A side note though, it isn't just framerates that matter. The size of the model is obviously a lot larger for higher vertex counts. This means longer loading times, both in the resource loading phase and in uploading to the graphics card the first time the player sees the model. These are only one time costs as opposed to per frame costs, but can still matter.

[bstone]

Thanks for sharing! That's nice to know. I think with hardware instancing that should look even better since you can still have up to 65k vertices per monster but batch them in even larger numbers.

[saejox]

Thanks.
I am very stingy about vertex count too, maybe i can get away with more.
Never even tried to go above 3000.

Did you test with skeleton animations?
In my tests it mattered the most, easily surpassed physics calculations.

[mkultra333]

Yeah, I was updating their skeletons. Just an idle pose, not much movement, but enough so that bones needed to update vertices.

I am doing hardware animation though. So all the vertex translations are done on the GPU. If you were using software animation the vertex translations have to be done on the CPU, so I expect the result would be very different and minimizing vertex count would again become useful. But for PC (or console) there aren't that many situations where you'd use software animation over hardware animation.

[saejox]

i am not really experience on this stuff, but your numbers suggests a bottleneck. Something other than vertex count is a performance drain.
Only after a certain point you see performance lost.

You may see linear decrease in performance as vertex count increase when skeleton animation is disabled.
When more than one element active in a system profiling provides wrong results.
Not %100 on that tho, just throwing some ideas

[mkultra333]

I suspect it's about the relationship between the work the fragment shader and vertex shaders are doing, plus the work the CPU is doing. Keeping in mind the GPU command buffer as well, which typically allows up to three frames of commands to be buffered up. As long as the time taken by the vertex processing is less than some fraction of the fragment processing, the actual number of verts makes very little difference. But once it starts to exceed some fraction of the fragment shader, things go downhill.

This is just a guess though, and a wild guess at that.

As far as the accuracy of the profiling goes, all I can say is that it was a real game example where the only variable was the vertex counts. There are seperate timers around the physics update, the game engine update, and the graphics update, and the figures above are for the graphics update. It made sense to profile animated meshes, since that's the meshes I'm building.

Edit: I might try a test with different number of vertices in the non-animated environment meshes later. Unfortunately that's a bit tricker for me to setup, so it'll have to wait.

[saejox]

I forgot about command buffer, that must be it.

i still wouldn't make high poly characters. Modelling is fun, but UV mapping is such a pain in the ass.
I have yet to see a good auto generated UV map.