Questions regarding animationsblueprint performance when shared with 1000 skeletal meshes.

Hey There :slight_smile:

I have several Questions regarding this topic:
I would like to have a lot of Skeletal meshes in a single level which all share the same animation blueprint.

1.) How would i best go about optimizing this ?

  • should i keep the number of bones used to a minimum ?
  • is there a more efficient way to share the same animations for multiple skeletal meshes ?
  • how can i disable the animations when the skeletal mesh is far away enough ? how can i even determine that in a blueprint ?

2.) Is there any other system that i dont know about that unreal engine offers to help with handling a high amount of skeletalmeshes while keeping performance fresh ?

Thank you a lot

So some time passed and i wanted to share what i learned here:

1.) There is the Animation Sharing Plugin which enables you to share animations between skeletal meshes. All animations are in sync and i couldn’t find out if it is possible to change the start time of some of them. You can only register an actor via blueprint the rest is hidden in C++. (even de registering doesn’t exist.)

2.) There is a Method to decrease the animation update rate at distance. This plugin is quite old and not documented sadly. It is easy to enable but customizing only works in c++. Also the debuging functionality doesnt seem to work on it as of 5.2.

3.) My current best try is to hide actors from the game which are not in the screen which gave me enough performance to animate 1200 units individually with animation blueprints. With animation sharing its even possible to go for more.

4.) I also played with the LOD for skeletons which is quite easy to do. Sadly there is no option to disable animations based on distance which would be great. If anyone knows how to do that please tell me.

5.) culling of skeletalmeshes or actors on distance seems to be bugged for me as no matter what min draw distance i set for my actor they are always rendered.

Delete the actor (or the mesh) at the actor level.
Do the check on an event call via interface.
Set the logoc in a separate class which runs on tick but also set the tick to only run every 10seconds or so.

In all occurrences, when dealing with more than lets say 1000 skeletal meshes the engine will cop out.
Since you can’t expect people to play a game witb sub 30 fps, the only alternative is to make the actors static Instanced meshes and to give them a shader material for the animation.

The shader, working by design just on the GPU - and without any overhead from underlying system of the skeletal mesh - will function magnitudes more efficiently.

Very conmplex shader animarions are possible using a variety of techniques.
From Vertex Paint to textures (pivot painter).

If you want, I’ll answer your other questions, but from the last post I believe you figured out most if not all of it.

Essentially, the engine (any engine in this case) has a hard limit to how many individual skeletal meshes can be present.
And its actually more “the platform you work on” and thefore “the platform of your release target” that brings most of the limitations.

Between avaliable RAM and avaliable VRAM, plus, avaliable CPU speed, is where the cost(s) end up in.
As a rule of thumb:
The more bones in each mesh, the more ram - the slower the cpu cycle/calcs.

1 Like

Thank you a lot for the response. I will definitely look into shader animations for further optimization.