Horde3D

Sorry for the delay in replying, I got caught up in my work.

I'm using vtune, an evaluation edition, and it only let me save the profile in it's own format. I'll check out whether I can get a text output of the routine's time usage.

On a different note, I noticed that when I use 100k agents, Horde ends up taking 1.5GB of memory to hold the character meshes, when they are 13 in all, and not too detailed ones at that (~2k tris, ~500 verts). Is there a way to remove this storage redundancy? because otherwise there's not way I can make it to 1M agents, and even so it doesn't make much sense to me to duplicate the mesh in memory. I must say though, Horde is extremely stable and doesn't act out even with this high number of agents, and barring the fps issue, it seems to be pretty robust.

If all characters have the same geometry files and no morph targets it should be possible to use only one instance of the geometry if you are using hardware skinning. In case of software skinning or if the model contains morph targets each instance will be a separate copy of the original geometry. (Nicolas correct me if I'm wrong here).

I'm using 13 meshes in all, none have morph targets, only skeleton based animations. I'm using hardware skinning only, because I haven't enabled software skinning and the documentation says that characters are hardware skinned by default. I faced the same problem when I used only 1 character mesh. I expected the behavior you said should happen, but since it is not, I wanted to find out whether there's some flag I'm missing.

That's a bit strange. I checked the chicago sample. I reduced the number of characters from 100 to 2 and the memory consumption stays nearly the same. I also checked that cloneResource is not called. So I guess there's something a bit different in your example. Can you make a breakpoint in the ResourceManager::cloneResource method to ensure that no model will be cloned, and if the method is called try to check why it is called. Normally the only reason is as already mentioned, softwareskinning or morph targets.

But another possibility may be the data structure of your agents itself. If you have 100 000 agents, a struct containing references etc. may consume enough memory that you will reach 1.5Gbyte even if the resource won't be cloned.

I checked that out. I tried increasing the number of agents in Chicago to 100k, I observed the same thing, the mem usage bloated up to 1.5GB.

As for my agent specification using that much memory, running the code without using Horde uses about 75-80MB of memory for 100k agents, so that can't be the source of the usage.

Well Horde3D itself keeps references, scenegraph information etc. so it seems like Horde is creating a little bit to much information for each instance. I switched the Chicago Sample between 2 and 200 agents and it made a difference of about 4MB so each character need around 0,02MB for it's informations. That fits into your 1.5Gigabyte problem, even if the geometry does not get cloned.

Is there a possible optimization for this? As else I'll have to delve into creating a 64bit version of my code and Horde for creating larger scenes. I wanted to try and avoid that because some of the dependencies I have are not functioning at 64bit.

There may be possibilities to optimize this, but none that can be enabled by toggling just a flag. I guess someone has to digg a little bit deeper in the code to check if there are possibilities to optimize the memory usage.

Hmmm. I tried 100 models and 1000 models with and without animation and memory consumption was 24mb on the low end and 29mb on the high end, for a release build. Performance still in the 3 - 4, occasional 8 fps range. Mem based on what task manager tells me. Consumption is higher when fullscreen, like 80 - 90mb. Makes me wonder why a difference between what you two are reporting. 3.5ghz Pentium D, 4gb ram at 3-3-3-9-12 timings, and an 8800GTX for specs. Lots and lots of batches, 1200 - 1500 when deferred and upwards towards 3000 with forward shading.

So in short, I'm not seeing memory problems, but fps issues. I've got a lot a free time this weekend, so maybe I'll try quickly gutting the the batch rendering and using different ogl instancing techniques.

My horde test app (Chicaco clone) usually uses 33mb of ram in Release builds with 100 NPCs walking around.
I just upped it to 5000 NPCs and the memory usage went up to 107mb (it also took a long time to load, and ran at 0.5 FPS ).

Horde Stress test - 5000 NPCs + 2 viewports + particles + 2D

In my previous test I used the debug version so that may be the reason for the difference. Although running it in release mode I had 27MB with 100 Characters and 40MB with 1000. Compiler was VS2005, Horde3D was the one from the Community Branch Rev. 170 no changes on the project settings or source files except the number of characters. Looking at the whole scene I got around 10 fps ( min. 9.6fps, max 12.5 fps ) with about ~7 740 000 Tris and ~ 3900 Batches.

System: Core 2 Duo E8400 @ 3 Ghz 2.98 GB RAM, Geforce 8600 GT

Volker will soon integrate a patch that solves this problem. It was surprisingly easy to reduce the loading time for 5000 characters from around 40 seconds to 3 seconds

Does the Community branch differ substantially from the version 1.0.0Beta2 that is available from the website? Does it have any speed/reliability improvements? Since others are getting different results in trying to replicate the memory usage problem I'm facing, I was wondering whether switching to this branch might help in any way.

No, there is not much difference at that time, especially not performance-wise.

After my last optimizations hotfixes to cull objects using the aabb tree and turning on sse2 optimizations in the visual studio compiler it would see that my bottleneck in the chicago sample is the scene updates (the memory usage is about 40megs and loading takes about 1 second). What I was thinking of doing is optimizing away the animations for the objects that are not in the frustrum, or at the very least, maybe reduce the frequency of the update and not do it every frame. Since updating joint nodes is the biggest bottleneck for me I think this could help a lot in accomplishing horde3d's goal of rendering large crowds. I unfortunately just started a new job so I don't know how much time I will have so I thought I's pass that idea around.