I’ve just noticed that my game’s framerate drops substantially when there are >10 NPC models on screen using the DynamicAnimControl. If I remove the code that adds the DAC to the model, then I can go back to having ~80 of the same model without any noticeable framerate drop.
The issue still persists even when I call dynamicAnimControl.setEnabled(false). I thought I could avoid the drop in framerate by disabling each individual DAC until I need to use it, and then disable it again within 5-10 seconds once the model goes back to playing regular animations. I can also notice that disabling DAC does improve the framerate to some degree (specfically when multiple DACs are overlapping and are triggering physics collusions with one another) but it still lowers the framerate drastically as long as the camera is looking at all of the models with disabled DACs.
Typically, I expect this type of issue to be related to graphics, because the framerate goes back to normal when I turn the camera to face the other direction so that the models are culled by the engine’s frustrum culling.
Is this FPS drop on the GPU intended behavior, or could there possibly be a bug that is making DynamicAnimControl tank the framerate even when the DAC is disabled?
I can also provide more information if needed or make a video showing how the framerate changes when DAC is enabled, vs when its disabled, vs when its not used at all.
>10 DACs implies a large number of physics bodies, as in >100, so I’m not surprised there’s a performance impact. I am surprised that it depends on the camera direction. That seems worth investigating further. Is physics debug visualization enabled by any chance?
There are many ways to improve the performance of DAC. One is to simplify the collision shapes, which are determined by the ShapeHeuristic in each LinkControl. VertexHull is the default, but often TwoSphere or FourSphere is sufficient.
Reducing the number of links per ragdoll should also help.
Also, please make sure you’re running the latest MInie (v6.0.0).
I’ve double checked to be sure, and I am not calling bulletAppState.setDebugEnabled(true); anywhere in my code.
I also upgraded to the most recent 6.0.0 version and the issue still persists.
Here’s a video demonstrating the issue and how the framerate improves when the camera faces away from the NPCs.
First I run the game with no DACs to show the standard framerate with many NPCs, then I run it again with DACs attached and enabled to show the way the framerate drops when they are in view of the camera.
Let me know if I need to provide anymore information
Yeah, a screenshot or 2 with the detailed profiler might provide insight:
stateManager.attach(new DetailedProfilerState());
Another thought: DynamicAnimControl disables hardware skinning before the DAC itself is even enabled. With many animated characters on the screen, that might cause a noticeable performance impact. You could test this hypothesis (with no DACs) using
I think this might be the cause of the issue, and explains why it occurs even when I disable DAC.
I experience the same type of framerate drop when I spawn in 10-20 of any NPC that have hardwareSkinningPreferred set to false without any DACs.
Is there any way to use DAC while using hardware skinning preferred set to true? Or to have it go back to hardware skinning when DAC is disabled?
It seems like using software skinning makes it impossible to load in >30 on a very small map with a single terrain, and on larger maps I can only spawn in 8-10 models before the framerate starts to drop substantially, which I suspect will only become a bigger issue as I attempt to optimize my world to increase the render distance of far away NPCs.
It’s been years since I wrote that code. I don’t recall exactly why I disabled hardware skinning. It might be possible to re-enable it after the collision shapes are created … or even to avoid disabling it entirely. I’ll look into this…
Edit: It’s easy to re-enable hardware skinning after the shapes are created, and I’m convinced that doing so won’t create any new issues. Failure to do so appears to have been an (embarrassing) oversight (on my part). I’ll solve the issue in Minie v6.0.1, but for now you can work around it using setHardwareSkinningPreferred(true).
lol yeah the poor Ogre is getting fat shamed for no reason
Although it wasn’t me who named it that haha, he’s one of the (many) models I’ve purchased from graphic designers who are much more skilled than I could ever hope to be, especially when it comes to animations.
( i got a lot of models like him on sketchfab during 35%-50% off site-wide seasonal deals a few years ago when sketchfab was newer, although its a shame I don’t think they run big sales like that quite as often since they’ve grown. I think they still do for black friday, but I don’t think I’ve seen 50% off in a long time)
That plague spore I showed in the last WIP thread is the only somewhat decent model I’ve ever managed to animate, aside from the main wood-elf character that you play as in my game which I did animate (very poorly) and have been heavily procrastinating on finding some high quality bvh animations to retarget onto her.
Although I did surprisingly have 82 people so far download a copy of my wood elf female that I uploaded to sletchfab a while back for some reason, I made it free but didn’t understand the licensing and made it non-commercial rather than fully open-source which I still feel bad about lol. But I was surprised some people found it useful enough to downlaod and play around with despite the poor animations which is kinda cool to think about.
