You are an experienced programmer and have a problem with the engine, shaders, or advanced effects? Here you'll get answers. No questions about C++ programming or topics which are answered in the tutorials!
for our game SuperTuxkart we have been wondering what is the best way (in terms of runtime performance) to have many (think of 5 to 20 or 30) identical objects ina scene / on a track.
* Store those objects as one separate file, load it, and use one scene node for each of these objects.
* Store these objects as part of the main track (so in one big file), which is loaded as a octree.
While the overall size would be bigger with an octree, I would expect that the overall performance would be faster (since it should be more efficient in culling unused parts of the track). But first (admittedly very subjective) reports indicate that this is not faster.
Do you have any recommendations on how to handle a situation like this?
I think it depends on the geometry of the "items" in question. I mean, if it is only a relatively few tris, then using the octree should be faster, because like you said, it is only rendering certain sections.
On the other hand, part of the culling of the octree IS done runtime, though some is calculated beforehand. If you have many tris in the "items" than it may be better to keep them separate. I don't know exactly how effecient the octree is with small tri heavy items, and I know it is normally best used for "level" type geometry. I'm pretty sure Irrlicht culls objects using the bounding box, so you items may be better off in separate scene nodes, allowing Irrlicht to do so.
I think maybe someone else who knows more details about the octree could give you a better insight, but atleast I've given you something to start with.
Better option should be one bigger object than octtree (but important are also hardware target). You should try reduce draw calls to minimum. For me 100-150 draw calls per frame are maximum for optimal performance. Render some more 'extra' polygons is cheaper than too more draw calls. Of course for the best performance You must use static index and vertex buffers.
Nadro wrote:Better option should be one bigger object than octtree (but important are also hardware target). You should try reduce draw calls to minimum. For me 100-150 draw calls per frame are maximum for optimal performance. Render some more 'extra' polygons is cheaper than too more draw calls. Of course for the best performance You must use static index and vertex buffers.
This is also a valid point. It still depends on the exact geometry of the items though, and like you said, the hardware target.
thanks for the replies. Atm the 'identical' objects are using about 70 triangles. So my understanding is that we actually have three options for this:
Include all objects into one octree (hoping that culling is more efficient). Could someone confirm that octree should work atm as expected (e.g. if you have a small set of objects that can be culled, that they will actually be culled a few levels down in the tree?There is at least one thread http://irrlicht.sourceforge.net/phpBB2/ ... php?t=3268 which indicates that this might not be the case, though in my case we have a 3d octree, so it is probably a different issue. In the worst case I'll figure out how to get the number of rendered triangles out of irrlicht )
Include each object as a separate scene node (hoping that culling is easy and fast, even though the number of visibility checks is increased by the number of additional objects)
Include all objects as a single scene node with appropriate hardware mapping (while we don't get much benefit from culling, drawing it would be very fast, assuming that the objects are not too big). Wouldn't that be more or less the same as including it in one octree? E.g. if all of those items are visible, they should be drawn with one call? No idea what happens if only part of them are visible though.
And we basically have to measure each of them to see what's best (and that might depend on the graphics card used). Not ideal, but that can't be changed I guess.
1. Yes, use an octree, it'll be fast enough.
2. No, it'll be slower: Irrlicht would have many scenenodes to care about.
3. No, it won't help, because you're talking about 70 polygons per node.
No, it's not broken. It wasn't ever. It simply rendered without the octree optimizations. So it did do some unnecessary stuff, but in the end usually rendered twice as fast as the octree optimized version. Moreover, we're also testing a combination of octree culling and VBOs currently, so there will be real hardware accelerated octrees in the near future.
My bet is that you will get the best performance right now by simply batching all elements into one scene node. Having VBOs will render this pretty fast, otherwise you'll get still good performance since 1500 polys (which was the max value you gave in your estimation) is far from being much to send over the bus each frame. The octree culling is also quite expensive to calculate, so it will burn quite some CPU time which you can use for other things.
3rd option will be the best on each hardware which support VBO. 70 poly per draw call is too less, so You should split them to bigger parts and draw it with less count of draw calls.
thanks all for the answers. We have planned some more investigation into performance in a week or two, but have some first (somewhat surprising) results:
we replaced the addOctTree call with a simple addMesh call for the main track, and got 'some' performance improvement (it varies from track to track, machine to machine) - but in the order of 5 to 10 fps I'd say. We are still not that happy with the overall performance, so will be looking into more details later.
I must admit that the numbers of culled areas from the octree algorithm looks pretty small. This might show some erroneous behavior in the code, but I'm not yet sure how to properly read the figures. We'll keep this as is for 1.7, but we'll have an eye on this, and also do some more optimizations towards Irrlicht 1.8.
)