Let's Explore the ANIMATOR Component in Unity!

Animations bring about life to our games, but managing animations and the logic for handling them could get complex way too fast. Enter Animator. Animator is a component in Unity that allows GameObjects to be animated via logic, that is explicitly represented inside an asset in our project. So we can create something called an Animator Controller, and this allows us to manage a set of animation clips along with the transitions, visually. For example, we can switch from an Idle animation to a Run

animation when we press the arrow keys, and the logic for that could be set up in the Animator Controller. The Animator component uses this Controller to animate a GameObject. Let's take a look at the component. Firstly, we have the Controller. I have already made a bunch of animations for Buddy here from Mixamo and an Animator Controller here as well. If we open it, we will go to the Animator window. And here, you can see the animation setup. This setup with a bunch of states and connections i

s called a State Machine. Here we have four states and a bunch of transitions. We will learn how to set up this State Machine in the next video dedicated to Animated Controllers. If we click on a state, we can see that it has an animation clip connected to it. Which means that Unity will play this animation once the control reaches this state. In this scenario, when we play the game, the Idle animation gets played. If we click on this transition here, we can see the condition that this transitio

n to Run will occur when the speed is greater than 0.1 and there is a transition back to Idle, when the speed is less than 0.1 Speed is a parameter inside our Controller. And in our script, we have connected this speed to the speed parameter via the Animator. Now if we move, we can see the transition happening. And the animation will play. We also have transitions to Jump and Attack from Any State based on some parameters called jump and attack. And they are connected back to Idle and walk based

on the speed parameter once again. Any State literally means ANY STATE. If this is complicated for you, don't worry, we'll look at this in detail in the next video in the playlist below. Back to the project, if we press spacebar, we can see the transition happening to jump, and on mouse click, we attack. Essentially, we set up a State Machine, and via code, we make these transitions happen by using these parameters. Cool. Now let's talk about an Avatar. An Avatar is a character rig and it defin

es the skeletal structure and animations for a humanoid character. It defines the hierarchy of bones and the positions of joints and stuff like that and then maps it to muscle groups in different parts of the humanoid body. What makes this useful is that it allows us to retarget animations. Or in other words, share animations between different humanoid characters, which implies they have similar muscle groups, even though their skeletons are represented in separate GameObjects. Does that make s

ense? Essentially, we can share animations with characters of similar Avatars. We can configure Avatars when we import a rigged 3D model. Select the model, go to Rig tab in the Inspector here, And click on Configure. In this example, we have two characters with two different Avatars. They are created by Unity automatically. But if we click on the models, and go to Rig, we can see that both of them are humanoid, which means they have similar kinds of muscles. Note, both of these have different Av

atars, because there are differences in bone length, and the bodies look different. We have an animation, and the type is set to humanoid, and we can define this animation based on an Avatar, and we chose the Avatar of the peasant. If we open the animation, most of the fields here are properties of the Animator. You can see Animator.Head and Animator.Chest, this means that the animation can now be shared between characters with the humanoid rig. Both of these characters share the same Animator C

ontroller, but different Avatars. You can see that the peasant's animation looks nice, but the other guy looks weird. This is because of differences in body types. and bone length of the two models. Essentially, if you make your characters to look similar, you can share animations between them to save memory. In this case, it's better to have a separate animation for the other dude. We can still configure his Avatar and go to Muscles and Settings, and change the Per-Muscle Settings, and play aro

und with these values to match the proportions. This is the power of Avatars. We basically have a second rig in which we can tweak things. For example, we can have the peasant to not stretch the arms that much upwards by going to its Per-Muscle Settings and lowering the range of the Arm Down-Up slider for the left and the right arm. And now the peasant is lifting his arms less. But we haven't even touched the animation. It's completely okay if you don't understand what the heck this is, if you'r

e starting off. Apply Root Motion gives us the option to let the animation decide the character's position and rotation. This means any movement or rotation inside the animation would be additive to the current global position and rotation of the root GameObject. This is useful if you have animations like dancing, and is useful in cutscenes and stuff, where the root is also animated. So turn this off if you don't really need any root motion. Animations like Running and Jumping are usually animat

ed "In Place" and the motion of the root GameObject is decided by a script or the physics engine. Turning this off would be a great optimization and avoids unnecessary calculations. But only do that once you're absolutely sure. Next, we have Update Mode. And I don't know why, but this is so important, but rarely talked about. Normal means the Animator is updated in sync with the Update() function call, which means if we slow down the timescale, the animations will also slow down to match it. Ani

mate Physics updates the Animator in sync with the FixedUpdate() function call. Use this if you are animating objects with physics interactions. Both Normal and Animate Physics may look identical, but Normal is more responsive to input, while Animate Physics gives realistic responses based on physics interactions. In most cases, you should use Normal, but when the animation of the object is heavily dependent on physics, go for Animate Physics. Unscaled Time is useful for animating GUI elements.

This updates the Animator in sync with the Update() function call, but ignores the timescale. When we pause or slow down the game, we modify the timescale value. But we may want the menu or the UI elements to appear, and their animations to work in spite of that. And Unscaled Time does that. This is really important to remember. Finally, we have Culling Mode. This is used for optimization purposes. Always Animate will always animate the GameObject, even when it is off-screen. This is more realis

tic, and seems more natural. Cull Update Transforms disable things like IK and write of transforms. State Machines and root motions are unaffected. Useful for things like a moving platform, controlled by an animation with child animations inside them. When the Renderer is not visible, root motion still works. Cull Completely means the animation is completely disabled when the Renderers are not visible. This doesn't stop rendering, only the animations. The former is called Occlusion Culling. Note

, all animations would work in the Scene View. Culling Mode is only effective when we build the game. So, sorry, because of that reason, I can't show you how it works. There's also a small box here, which is for the Animation Curve Information. This shows data used in all clips by the Animator Controller. In my six years of experience making games, I am proud to say, that I've never ever touched it. And yay! That is the Animator component. I highly recommend looking into the Animator Scripting A

PI docs. There are some really cool functions available inside the Animator class that we can utilize. Link below. In the next video, we will learn how to actually use the Animator Controller, so that we can learn to set up a solid State Machine. Hope this was useful. And as always, take care, see ya, bye-bye.