Reducing Render Time

cheshirekow · Post by **cheshirekow** » Fri Mar 26, 2010 11:30 pm

I'm interested in what are some good rules of thumb for designing a scene to keep the frame count high. These are some of the things that I imagine contribute to the render time in a particular scene:

Polygon count
Size (resolution) of textures
Dynamic lighting
Graphics hardware
(edit) Culling
(edit) Batching with CBatchedMesh

What am I missing? Are there any rules of thumb to target to keep the frame rate high enough (say, 100fps)? The program code, obviously, will also contribute to the frame rate, but eliminating that as a factor, and making some reasonable assumptions about the users hardware, what are some numbers I should keep in mind as I build scenes?

Lonesome Ducky · Post by **Lonesome Ducky** » Fri Mar 26, 2010 11:57 pm

I know you said the code will be eliminated as a factor, but culling is VERY important in keeping a high frame rate. Graphics-wise only, resolution and whether or not it's full screen will effect the speed.

cheshirekow · Post by **cheshirekow** » Sat Mar 27, 2010 12:14 am

No, good point. Culling is done by irrlicht though right? I guess the question is, if any polygons are culled, will they contribute zero to the render time? Or essentially zero? Or some fraction? Can I make an arbitrarily large scene and then just cull-away the things that are "far" without any contribution to the render time?

I guess it might depend on whether or not the whole object is past the "far" plane. In which case the scene manager may disable it all together. Though if part of it is in-plane, then it will still have to process the mesh and figure out which polygon's are visible right?

I'll probably be doing some far-plane culling eventually for large scenes, but I wasn't thinking about that in my original post. I was only really thinking of like a "room" or something. In which case, the next question is, does irrlicht (or the underlying driver) think about whether or not polygons are obstructed? If so, I suppose that could also cut down on render time as well. If that's the case, maybe "visible polygons" is more of an indicating factor.

Thanks for the input though, and if you happen to know the answers to the above questions, please let me know!

Lonesome Ducky · Post by **Lonesome Ducky** » Sat Mar 27, 2010 12:33 am

I wouldn't say there's really a rule of thumb for keeping a frame rate. Hardware varies wildly on computers. You don't have the benefit of consoles where if it runs on the one you're testing, it'll run perfectly on the others. Chances are even if you get a program to run quickly on yours, it's not going to run very well on another. I try using a mid range system for testing and try to get around 70 fps. And about the culling, most games now a days use portal culling. Basically it says if you're in this area (like a room), then only these areas can be seen. Obviously if you're in an enclosed room, you won't see most of the other rooms in the buildings through the wall

So if you're displaying an indoor map, you can cull more than 90% of the whole map at most given times using this method. There's also a method called occlusion culling, which is done by the graphics card. I remember an example on these forums a while ago, but I don't have the link anymore.

BlindSide · Post by **BlindSide** » Sat Mar 27, 2010 7:34 am

Draw calls and batching.

ent1ty · Post by **ent1ty** » Sat Mar 27, 2010 8:20 am

I was thinking about optimizing an .irr file with, let's say, 100 meshes.
My idea was to add all these meshes to one octree node in code. That would help on fps, right? But would it be enough for the effort?

Lonesome Ducky · Post by **Lonesome Ducky** » Sat Mar 27, 2010 3:42 pm

If it's 100 low detail meshes, culling probably won't be worth it. Batching though will make a big difference.

cheshirekow · Post by **cheshirekow** » Mon Mar 29, 2010 5:41 pm

I'm not familiar with what batching is or how it's performed, can you guys expand a little on that? I guess the important thing is what are the classes or functions used... The manual should take care of the rest.

Acki · Post by **Acki** » Mon Mar 29, 2010 6:20 pm

http://irrext.svn.sourceforge.net/viewv ... chingMesh/

cheshirekow · Post by **cheshirekow** » Tue Mar 30, 2010 4:18 pm

Oh nice. That seems very easy to use as well. So for a (mostly) static scene, if all the meshes are batched together using a CBatchingMesh then it will reduce the number of draw calls and speed things up. Roughly speaking, will this be the same as if all the meshes were actually loaded as a single mesh?

hybrid · Post by **hybrid** » Tue Mar 30, 2010 4:25 pm

Yes, that comes very close. Please note, though, that batching everything might become counter-productive. Culling works on a per-node level, so it could happen that much geometry from behind the camera needs to be rendered then. And the number of vertices shouldn't become too high to fill the GPU continuously.

ent1ty · Post by **ent1ty** » Tue Mar 30, 2010 5:34 pm

So maybe use an Octree to cull some stuff?