Horde3D

I highly doubt I'm CPU bound. Given the low bone and vertex count, even in software you could easily skin that many characters at a higher FPS. I'll have to have a look and see if I cant track down whats actually causing the bottleneck.

Measuring performance in debug mode is pretty pointless. There are a lot of security checks and assertions and you get no function inlining or compiler optimizations. Sometimes I experience slowdowns of 5-10 times in debug mode compared to release mode. 60 frames in debug mode for the crowd simulation is fully acceptable (note that cascaded shadow maps are enabled as well). As DarkAngel says, you don't have to compile the whole solution in debug mode: if you want to debug your AI, compile it in debug and leave Horde in release. That's why Visual Studio has the Configuration Manager.

300 characters should work as well. And I know that there is still a lot of room for optimization in the Horde rendering code regarding batches, for example we are still doing string comparisons for the material classes. That area is still quite unoptimized.


Right, scene graphs are completely outdated. That's why we just use a scene tree in Horde. We also plan to make the scene tree structure even more lightweight. This should bring a considerable performance improvement for animated characters. Some parts of that proposal are already implemented in a prototype version.


Do whatever you think is the best for your project. But you should not underestimate how much time it takes to write a fairly competitive renderer. Sure, you can get some textured boxes on the screen in no time. But it is the small decisions and details that cost a lot of time. How long do you think will it take you to write a reliable asset pipeline that works well with all kinds of animations?

That's why I came over to Horde I was basically trying to achieve the same goals, but I ended up spending all of my time on the renderer itself instead of spending time on the projects that used it.Yeah speculation doesn't get us anywhere - you'll have to profile it.

The simplest things can become a CPU bottlneck in debug mode though - I've had a 100x slowdown (debug vs release) from simply iterating through a vector before, as MSVC adds a huge amount of error-checking overhead by default.

A few quick ideas for optimization on content side:
- You are using joints now and hence skinning for the animation. Since you don't deform the geometry, you could directly animate the meshes and completely discard the skinning.
- Instead of using four materials, you can create an optimized model which combines the 4 textures in one. If the user customizes the model, you just use the original 4-material model for that specific character.

Yeah, I could definitely do the animations that way. I might try that first.

As for the textures, I envision a lot of texture changes to the point where each character onscreen could potentially be made up of different parts. My thinking is that if I make a texture atlas for each mesh part (all heads, all arms, all legs, all bodies) but if each model part isnt batched, I wont save much. My other option is to write a batcher specifically for those nodes.

I agree that writing my own renderer really isnt the ideal option, but my needs are relatively modest. I've written animation code for skinned objects before so its not really an issue, although writing a collada parser for the data is an exercise in boredom

Its just attractive because GLSL isnt my usual shader language so I could write a loader and use my usual cg. But I'll stick with horde a bit more, at least to the point where I have a UI and the usual picking/editing functionality in the game in a horde version, just to do a direct comparison to my Ogre implementation.