Monday, August 31, 2015

Unity3D At Home Project - Day 4 - Basic Animation

Busy weekend, busier week, but I did manage to sneak in a little bit of time on Sunday to play around with simple animation, and to get our avatar animated.


You may recall last week I wasn't sure if I was going to dig into the barely functional camera controller some more, or start working on animation. I decided to skip any more work on the camera controller for now namely because, as you recall, ultimately I want this to be a giant robot game, and I'm thinking robots with turrets, and I'd want the camera attached to the rotating upper half of the mech. Additionally, we'll be using a 3rd person shooter point of view, and until we get a crosshairs on our hud, and some weapon systems, there's not a lot of point in fine tuning the camera. So let's get Ethan animated, instead of just gliding across the terrain.

Well the first thing to realize is - I didn't use Ethan. See, the Ethan prefab that is provided in the standard assets is a great resource.  In fact, it's a little too good, as it has a lot of stuff preconfigured already, and that was exactly the stuff I wanted to configure myself. To learn what those components are, how they're set up, and how they related to each other.

Learn
So the first thing I did, and I did this part at periodic points throughout the week, was to start getting familiar with animation basics in Unity 5.  To be precise - humanoid animation basics. And I started that by just working through Unity's own tutorials, and even reading the manual.

Introducing Kyle
So as I mentioned, Ethan is a bit too far along for our purposes. I really just wanted a straight up humanoid mesh. I dug around the asset store, and found Space Robot Kyle. Kyle is from Unity tech itself, and has been around since, forever. Most importantly, he's a simple, skinned mesh, and a material.  In other words, he's perfect.

Creating an Animator, and an Avatar
So I got Kyle imported easily enough, but it still took a bit of work to actually get going.  I created an empty Animator controller easily enough, but I was having trouble creating an Avatar to associate with the model. I would go to the rig tab of the model view, set Avatar Generation to "Create from This Model", and click "Configure", and nothing would happen.  Eventually I learned a very important lesson. And that is, if you have your Unity inspector in debug mode, about half of the automated inspector tools Unity provides for you around animation either don't show up, or don't work.

Finally, when I turned off debug mode, and clicked configure, it loaded up the Avatar Configuration scene, and allowed me to configure the bones.  Not unsurprisingly, the bone mapping and muscles were pretty much exactly correct.






One interesting side node. As soon as I generated and applied the avatar to my mesh, the existing mesh I'd placed in the world view took a 90' turn to the right. I suspect applying the avatar mapping will even reorient your model if need by for it to align correctly with mecanim's bone system. Fortunately, deleting the previously placed one and dropping a new one into the game had him nicely oriented.




Animations

Now I had an animator controller, and an avatar associated with my model. It was time to actually hook up some animations. This part wasn't too difficult. I only wanted to do some really simple stuff: Idle, Walk, Run. Double-clicking on the Animator Controller in the project view brings up the animation sequence editor. Unity provides a pretty sophisticated system for sequencing and blending animations, and if you've ever worked with animation sequencers before, this will be quite familiar. But Unity does a great deal to automate the process for you, including an ingenious method of setting up 1 and 2 dimensional blend trees with many animations. To the left here you can see my very simple blend tree I ultimately ended up with for Kyle.

But what animations did I use? Well I used Ethan's.  And that, really is the key point here.  Unity's mecanim system makes it ridiculously easy to mix and reuse animations from other models. See, back in the bad 'ol days, all animation files moved bone positions around by explicit bone names. That meant that the skeleton of your rig had to exactly match the names of the bones that were used when the animation was created. Which is why all the legacy models you buy at the store come included with some animations. And if you wanted more animations, you had to make sure they were built specifically for the model you were using.  Mecanim though democratizes this process, and makes it stupidly easy to rig, and use animations from other sources. And yes, I know this is all over Unity's mecanim promotional literature. But there's a world of difference between reading a feature set, and actually being able to use that feature.

Final Touches
In any event, before long I had a functional, if simple, animation tree built. I added my controller script to Kyle, pointed the camera at him, and launched the game. He animated perfectly while idling.. but.. he didn't animate while moving. Oh duh. One more step - get a reference to the animator, and update the animator parameter values (in this case a whopping one - ForwardSpeed) through script. Oh hey now he works!

One tweak I noticed right away was that he didn't animate backwards. Stupid me, when I initially set up the blend, I set the thresholds from 0 to max forward movement speed. Well this doesn't account for moving backwards. I adjusted the blend tree again to account for negative speeds, and limited his backwards moving speed to be limited to half his forward moving speeds.  Overall, pretty pleased, and not bad for what was about a single night's work.  Here are the results.


This is the fourth segment in an ongoing series wherein I build a game from scratch in Unity3D. If you'd like to read the entire series, click the Game Development tab above, or just click here.