Playables API performance concerns

Is anyone here actually using the Playables API for anything serious?

It seems like the API is a good fit for those of us requiring more control over the way the animation behaves as well as supporting somewhat dynamic animations without going crazy, however it seems the implementation is riddled with shortcomings and performance issues as soon as you try to scale up.

We are currently using the API for our custom animation system because we were not satisfied with the stiffness of the Animator Controller.
At first we were building a graph with all the required nodes, of course this was really slow, so we ended up disconnecting nodes on demand (i.e nodes with a weight of 0 would end up disconnected from the graph), this improved the animation performance by nearly 10x.

However with this solution, we're seeing huge spikes happening in our profiling whenever nodes are disconnected and reconnected, see:


This is with about 36 characters with a relatively standard movement + actions graph swapping a previously created AnimationMixerPlayable with a few animation clips for another one.
This 40ms stall in Director.DirectorUpdate which is about 3 times as much as the whole gameplay loop is a big deal for a 60fps game.

Is anyone else seeing something similar? Any workaround?

Thanks

 

When I did the Performance tests for Animancer I also found that creating playables as they are used and disconnecting (not destroying) them at 0 weight seems to give the best performance except for Sprite animations where creating everything on startup and keeping it all connected is significantly faster. I don't remember noticing any performance spikes, but I wasn't really looking for them.

One of these days I'll get around to doing some much more detailed benchmarks to see how things change in relation to factors like the number of characters and number of animated properties per animation.

 

Thanks for the reply!
We're currently in the process of optimizing parts of our game, so we're really looking for these kind of issues, initially we overlooked this as well, but it became obvious when scaling up the number of playable graphs.

I'm going to be doing more profiling to figure out why exactly we're getting these spikes and if there's anything that can be done to mitigate them.
But so far it seems like we will have to keep the "most used branches" in the graph connected at all times, and just connect the less used ones on demand to avoid the performance issues.

I will post more info if I have some, but the state of the Playables API is disappointing, I really wish it was getting more love as it's the only available low level Animation API (yeah let's not talk about DOTS Animation ☠)
Animation is kind of important in games...