Dynamically adding animations to playable graph at runtime

We have a system that needs to add and blend animations dynamically at runtime. It's not possible to know in advance which animations or how many animations might be involved. Currently we're using playables and mixers to mix incoming animations with outgoing ones. The one issue we're having is that the outgoing animations resets when we add the new one to the graph, so we lose some of the smoothness we're shooting for.

The code is trying to keep the tree as simple as possible at all times, so it will dynamically create a mixer and attach the existing playable and the new playable then blend between them. I believe that this is causing the graph to be rebuilt and the existing playable to be reset. I'm wondering if there is a sequence of operations that would not cause the reset--if we kept one mixer alive at all times and simply changed the inputs?

Basically I'm going by the comment in this thread that "changing the playablegraph at runtime will trigger a Rebind operation on the animator..." and I'm wondering if there's a sneaky way around that since I'm not entirely sure which operations count as "changing the playable graph":

https://forum.unity.com/threads/run...time-i-change-a-custom-playable-graph.758159/

Thanks!

 

Why would you not do that in the first place? Destroying and recreating it is just going to waste performance.

I built Animancer (link in my signature) entirely around the concept of adding animations dynamically as they are needed and haven't had any problems with things resetting. I don't think I've explicitly tried it in a regular mixer, but the entire system uses a layer mixer which should be the same.

 

Does the documentation outline the performance impact of creating mixers somewhere? As with most of this code base the answer seems to be no and it’s often guesswork time determine best practices. I can certainly think of many implementations that could be very efficient. But we’re usually left guessing.

 

No, the Unity documentation rarely talks about performance and the Playables API documentation is especially bad at ... everything really.

But I'm still wondering why you think you need to create mixers dynamically. Surely the number and configuration of mixers you need is known on startup so you only need to create them once and can just change their inputs whenever you need to create more AnimationClipPlayables to attach to them? Creating an AnimationClipPlayable isn't free, but the performance impact seems to be pretty minor.

And you can always just use the profiler to find out.

 

Well no, that’s point—technically we don’t know that configuration so a pure implementation requires the graph to change over time. But I can probably approximate it with a single mixer with at most 3 inputs, so I’ll give that a shot.

 

But more generally I was hoping to gain some insight into how it all works. I can’t find any reference that states what conditions trigger a “rebind,” and I didn’t want to bite off a refactor of the code until I had some reason to believe that simply changing an input would *not* do this.

 

So for what it's worth, this approach seems to have the same problem. Animation A is running on a loop on input 0 with weight 1. When I attach animation B to input 1 and weight 0, animation A appears to reset back to 0 causing a stutter. So unless I'm missing something, simply switching inputs seems to cause the same behavior.

 

Ah dang, scratch all of this. There was another point in the code where I was hard resetting some animator values that was causing a blended input to reset. I turned that off for now and both implementations provide smooth transitions.