Performance Optimization of Crowd.update()

[niko-dellic]

I'm looking for some suggestions on how to increase the performance of the crowd update function. I can run 2500 agents with ease, but drop to 1FPS over 10,000. Running the profiler, the major bottleneck is the crowd update function:

Before I commit to creating a multi-threaded worker system, does anyone have any suggestions on how to reduce the cost of the crowd.update() function? I'm using a fixed time step of 1/60:

and the other functions in the update loop are quite negligible even at 20,000 agents:

any help in the matteer would be greatly appreciated. Thanks!

[niko-dellic]

Hi @isaac-mason , let me know if you have any thoughts or references on the matter. Thanks!

[isaac-mason]

Hi @niko-dellic, I don't have any concrete suggestions without having more information about your use case. You are likely just running into the performance limitations of having that many agents in one crowd with the detour crowd implementation.

If you can provide more information about what you're trying to do I might be able to give some suggestions.

If you need full flexibility you will probably benefit from being able to modify the detour crowd code so you can fine tune it to your situation. It seems like most non-web users of recast/detour are making modifications as part of integrating it into their project.

[niko-dellic]

@isaac-mason thanks for the response. I can try to get you an isolated environment to check out later this week. For modifying the crowd code, Is that something that is possible with your web-assembly port? I'm not well versed with web-assembly, so apologies if this question is naive, but is there a general workflow for modifying the crowd code and rebuilding the web-assembly port? Any thoughts or direction would be greatly appreciated, thanks!