Hey, I know the Playables API is experimental ... But... if/when working, it would really solves several major issues for us... 1. Playing custom (one-off) animations without having them added to a controller 2. Blending between multiple controllers (when switching from exploration to combat etc.) However, when I try the simplest example presented in the docs... nothing happens. var clipPlayable = new AnimationClipPlayable(clip); GetComponent<Animator>().Play(clipPlayable); Has anybody had any luck with this?
Hum. Both should work. We have found that there is a bug where Animator.Play() does not work if there is a Controller asigned to the Animator. Has for blending multiple controllers, you should take a look at this : http:\\files.unity3d.com\pierrepaul\AnimatorControllerPlayableExample.zip And tell me how this goes!
Aha that explains it, thanks for your answer. Your example worked just fine The problem was that we're running around with Controller A (assigned to the prefab Animator component)... and then later want to blend over to Controller B. Any ideas whether this will be supported in the future? (i.e. that you can use Animator.Play(), to play different controllers/playables at different times?) Cheers
Is there a workaround for the bug? It seems that animator.Play(playable) still doesn't work, if there was a controller assigned (you can even remove it beforehand, as long as the animator is initialized, it won't work)
I've reproduced the problem and logged it as a regression. It will be fixed in high priority, and I'm writing a test right now to make sure it doesn't peek its ugly head again.
seems to be not fixed right now. Does re-importing the asset work? Works one time, but firing the animation a second time freezes the char.
Issue should have been fixed in latest versions of 5.4 (https://issuetracker.unity3d.com/is...-initialized-animatorcontroller-on-the-object) However, you need to call animator.Stop() between subsequent calls to animator.Play(). If that still doesn't work, please ping back and we'll figure it out.
Thank you, it works! Just 2 issues: 1.) Animation is 'snapping' it is not interpolating to the new Keyframe. But that's probably the intended behaviour. 2.) documentation still reads: var clipPlayable = new AnimationClipPlayable(clip); for creation. Should be: var clipPlayable = AnimationClipPlayable.Create(clip); To be found here: http://docs.unity3d.com/520/Documentation/Manual/Playables.html But this looks much more like an animation Api to me than Mecanim ;-). Thanks for giving this to us.
Yes. Normal flow would be (simplified): (Play) Create 1 AnimationMixerPlayable A Create 1 AnimationClipPlayable B Connect B to input 0 of A (Transition to new animation) Create AnimationClipPlayable C Connect C to input 1 of A over several frames, lower the weight of B to zero, while raising the weight of C to 1 (Finish blend) Disconnect B Disconnect C Connect C at input 0 Set weight of input 0 to 1, and weight of input 1 to zero And that's about it. This is pretty much what happens internally during a transition in Mecanim
yes, already made my peace with mecanim. Main problem I see with mecanim is that Animator Controllers are not reusable for different characters because they use animations directly and not animation names. If most of your characters have the same animation logic, e.g. idle, walk, run, attack1, attack2, GotHit1, GotHit2 it makes big time sense to have an abstraction layer between animation controller and the actual animation. That is, a name (string), not a pointer to an actual animation. This makes animation controllers reusable on totally different characters. The Animator then finds the animation in the fbx and fallbacks to some global scope animation or just fails (does nothing) in case there is no animation. Can all be set up before runtime. Just let the user determine the search strategy for animations (eg. localFirst, globalFirst...) and let him provide a global container of animations to unity in case of shared animations (e.g. humanoids). This would make mecanim flexible and usable for many different applications not just the using pattern you had in mind when designing it. But nevermind, just my 2 cents, thanks for building Unity!