Runtime Animation Rig transforms reset every time I change a custom playable graph.

Hi,

In my animation system, I often destroy and create new animation clip playables at run-time. There's no getting around this in my system.

For some reason, every time I do this it resets the animation rig back to default positions. If I make an empty test game object as a child of the character and move it around at run time it does not reset, only if it is a rigging constraint.

Has anyone else experienced this? Is there any way around this? Am I missing some obscure setting?

I can certainly think of some workarounds but I'd prefer not to have to go down that path.

 

Some additional information:

So it would appear that this only occurs to child-game objects that are rigging constraints. I tested with an empty game object that was not part of a rig and it wasn't being reset.

This makes me think that the rigging constraints are being added to the animation stream (which makes sense). What doesn't make sense is why creating and connecting a new clip playable to a mixer would reset the entire animation state. Fortunately my animation playables put the character back in order immediately before any rendering. However, since the constraints are moved through code outside of the animation loop, they get reset and there is no recovering from that.

The only way I can see to workaround this is to cache the constraint positions before the animation update. Then, have a custom playable which moves the constraints back to where they should be between my custom playable graph and the animation rigging playable graph. This seems super messy and I would prefer not to do it if possible.

Of course I could have all the IK logic run in the animation update but since this is an asset I'd prefer to not have to force my customers to do that.

 

Thanks for the response. Appreciate it. I will try this.

 

So this sounded good in theory but it didn't really work. Is there any particular place I should be calling WriteDefaultValues() ?

It makes sense to me to call it during a regular update right after moving the IK targets. However, there has no effect. I also tried in a number of other places but no luck.

 

Call WriteDefaultValues or Rebind don't work before i change my playgraph.

https://issuetracker.unity3d.com/is...playableextensions-dot-connectinput-is-called

 

Yes I found this too. I had to create my own system to manually track and reset values. However, there's only so much you can do with such a brute force method

 

The same thing happened to me. And parameters in the animator controller get reset too when creating and connecting a new clip playable to a mixer.

 

This needs to be fixed. It makes playables unusable with animation rigging. I can try to get around it by moving the targets out of the rig but the rig weights will reset to the default values. If I try to set these weights from another script there is a flicker before the update frame sets the value back.

 

Exactly the same issue. I swap runtimeanimationcontrollers and there is a very fast flicker of said weights and specially constraints positions. The animations themselves swap out smoothly without any issue, its just the rigging part.

 

Any solution for this?
I set weight value to 0 for default, and i set it to 1 when it meets the condition.
but even if the condition is met, when the another animation played, the weight value return to default value(0)
so there is a flicker...

 

Up

 

It baffles me to find that a core animation feature in Unity doesn't work with a REQUIRED animation feature in modern games... it's like you guys never even attempted to make a game with this engine isn't it?

 

+1

 

Anything?

 

Up

 

Well... calling WriteDefaultValues() it's actually reverting my ik targets at their default values. Should i even ask...? Nobody seems to care at this point.

Though by desperation i've found out that if you set an animation layer to 0.00001f or something very low that's not zero it's not going to stop the layer and redraw the playable so it never triggers a rebuild. The animations are still going to play in the background though so this might be a bit of a hit on performance but your ik systems will not be affected :\