Introducing the Simple Animation Component

Ever since they were introduced as experimental in 5.2, Playables have been mysterious beasts. Many of our users have been curious, and have asked us, “What am I supposed to do with those?” We answered, “Anything!” but we didn’t have any concrete examples to start from… yet.

After multiple API rewrites and Unity versions, Playables were moved out of experimental in 2017.1, along with the release of Timeline. At that point, the answer became “anything you want, including custom Timeline tracks, or even something as complicated as your own Timeline”.

While this answer is certainly exciting (customizability is always nice), making your own Timeline is something very few will even attempt, and we were still missing examples of the other category: “Anything you want”.

Why not an Animation Component?

On the Animation team, one common feedback we receive is that the Animator component and the AnimatorController are often unnecessarily complicated for simple cases where you want one or a few animations on an object.

Another frequent request is more complex Playables examples. A few basic examples were made to show simple API usage, but they are not very useful to show what can be accomplished using Playables.

Therefore, we decided to address both issues at the same time, and make a simple Animation Component, all in C#, and Open Source it so that it could also serve as a living, functional Playables example.

(If you’d rather jump directly to the code or try it for yourself, you can find the implementation here.)

Something old, something new

The Animation Component is already well documented, still widely used, and except for a few more advanced features, has a simple and straightforward interface. As far as examples go, reimplementing something our users already knew and could intuitively understand seemed like an obvious choice.

As is visible in the above Inspector screenshot, the SimpleAnimation inspector is very similar to the Animation inspector, except for one thing: the SimpleAnimation Component requires the Animator to run. As the designed Animation output for Playables, the Animator is required by Playable Graphs. That, however, is the extent of its use. By adding a SimpleAnimation Component to a GameObject, the Animator will automatically be added for you. You can then simply fold it away and forget about it.

On the scripting side, the interface is almost identical to the Animation Component’s interface. You can find an in-depth explanation of the differences on the project’s wiki here.

Retro exterior, new engine

While the SimpleAnimation Component looks like the Animation Component on the outside, under the hood, all the Animation logic is implemented through Playables. This way, the component is compatible with Timeline, with other playable graphs, and, the Animation logic can be reused in other Playable graphs.

Not just a playable example

Simple Animation tests in Unity test runner

To ensure a smooth transition from the Animation component, we had to make sure that the SimpleAnimation Component’s behavior was as close as possible to that of the Animation Component. Since some of the test tools we use internally at Unity are now public, it was very easy for us to create tests and include them in the project. The project contains a suite of more 100 comparative tests that validate that both Animation and SimpleAnimation components behave the same. When you clone or download the SimpleAnimation GitHub project, the tests can be found under Assets/SimpleAnimationComponent/Tests. If you decide to customize or extend the Component, you can use those tests to validate your work.

The Simple Animation Component is compatible with Unity 2017.1 and subsequent versions, and it’s available now on GitHub. Please try it out and give us feedback.

I don’t think the Animator is particularly difficult to use. I did find it a bit confusing when I started working with Unity but within a short amount of time with it I got a solid grasp of how it works. I think this is one of these things that Unity newbies complain about, but doesn’t really bother more serious developers. This is why it is important to inquiry about the user profile experience when you are getting feedback, like asking how the user is using unity, what he is using it for, how much experience he has with it, how many hours/week he uses it, and things like that to assess what kind of user you are getting feedback from.

a few notes:
1- legacy is faster than animator on 1000 objects
2- on 2017.3b11 add GraphVizalizer to the simple animation component project and you get Assets/GraphVisualizer/Editor/PlayableGraphVisualizerWindow.cs(48,33): error CS1061: Type UnityEngine.Playables.PlayableGraph' does not contain a definition for GetEditorName’ and no extension method GetEditorName' of type UnityEngine.Playables.PlayableGraph’ could be found. Are you missing an assembly reference?

They’re recreating the legacy animation component with the animator backend.
So you can just drop a few clips in an array as opposed to creating a controller and dropping them in that asset.
Script access is the same: anim.Play(“clipName”)

Thanks for improving the animations, Will simple animation component address the issue of dirty the layout elements on every frame if used on UI? ( as stated in the talk Unite Europe 2017 – Squeezing Unity: Tips for raising performance, min 48:48)

Currently, we lack of a system to animate the UI with a good perfomance, You can’t use it in mobile

Just like the Animation component, the Simple Animation component disables itself once it’s done with the current states (as long as the clip’s wrap mode is set to “once”; “hold” will keep writing the last frame, and “loop” will loop indefinitely)

Once it’s disabled, it will stop dirtying the UI.

On the other hand, the playables rely on the Animator to write to objects, so Simple Animation still shares the fact that every property of every connected clip is written on every frame.
There’s an option in the component that lets you get the same result as with the Animation Component, but it’s turned off by default, because it requires disconnecting unused clips, which is costly.

We want to address this in the future by adding to the Animator an option that this Component will leverage, which will make this behavior pretty much free, but this option will have to come in a future version of Unity, whereas the Simple Animation Component can be used now, in any version after 2017.1.

How come this entire post dances around the obvious question: why would I use Simple Animation Component over the regular Animation component if I just want to use … simple… animations… I don’t get it. Why not just use Animation? Because I don’t get to use Timelines? But didn’t you write, in this very blogpost: “making your own Timeline is something very few will even attempt”… so what’s the point?

I think they will push out the legacy animation system, now they are providing a simple way to play animation, like old times. The legacy system was (very) slow compared to this new system, and because it’s Playables under the hood you will have all new things you couldn’t do with Animation legacy system (or in a VERY difficult way). Cheers !

There are no active plans to phase out the Animation Component. At the moment, the SimpleAnimation Component is not built-in (you need to copy the code from the GitHub repo in your project to use it), so it won’t replace the Animation Component for the foreseeable future.

As far as speed goes, the Animation Component is actually still very fast for simple animations. There are a few simple performance test scenes in the project that you can use to compare the speed of the different implementations (Animation Component, SimpleAnimation Component and Animator with AnimatorController).

Yes the legacy is still faster in simple cases.
Mecanim is faster when you have multiple deep hierarchies (humanoids for examples) that are imported with optimize on. Also it can calculate stuff on a separate thread, while legacy still spams the main.

Hi there. I’ve tried to follow along with each blog post about playable. I’ve read this docs, read this article and the git notes. I’m zero closer to having it click with me why these are useful. If you could please just give a straight forward A / B example of a setup that shows how playable overcome a common architectural problem it might start to make sense. All I’m getting from this latest content is on a high level that playable make something animatable compatible with timeline. If the code api is almost the same as an animator component, what’s the point of using it and how is this any more simple or desirable to use? Again is this only a benefit if using with timeline? Sorry but every time I read something about playables I’m even more confused and never seem to be able to grasp the benefits. I really hope for a light bulb moment one day.

My thoughts exactly!
“As far as examples go, reimplementing something our users already knew and could intuitively understand seemed like an obvious choice.”
I’ve never been able to intuitively understand the Animator and Animation components. This post doesn’t make it any clearer either.

For the component itself, here are a few examples where it solves existing problems:
– You don’t want to use the Animator Controller (there are many valid reasons) but:
– You want to play Humanoid clips, use root motion, benefit from Humanoid IK, benefit from importer options only available to Generic or Humanoid clips, etc..
– You want your character’s upper body to play a conversation on a Timeline while the lower body is free to walk around.(the Animation component cannot nicely blend with Timeline; the evaluation methods are too different)
– You want to create interactive objects that use Timeline to drive your character, but you want to blend in from gameplay and out again. (a bit like this: https://www.youtube.com/watch?v=Z38WBMqjMJU but with smoother transitions)

– You want to use the Animation component for some objects, but Animator Controllers for characters, but don’t want to deal with two types of clips that are not compatible.

For the code being public:
– If you don’t like the way the built-in components work (Animation and Animator), and you’d like to make your own, this is a great place to start to build from, especially since it comes with a library of tests to help you debug your changes.
– It’s a realistic example of how Animation playables interact together, and a lot more in-depth than what you can put in documentation.

For Playables in general:
– Playables let us synchronize and blend Animation, Audio and Video on multiple objects in one single graph. Without Animation/Audio/Video being expressable as objects (Playables) that can be part of an evaluation graph (the PlayableGraph), it would not be possible to play them in a Timeline (a graph that plays Audio/Video/Animation at the same time)
– Making more and more pieces of the Animation back-end available as mix-and-match parts (Playables) lets our users make their own Animation workflows, without being limited by the tools we offer out of the box (AnimatorController and Animation Component). Then end goal is to have as much customizability as possible.