So I’ve been working on the main character for the new game. I’ve been busy with it the last week and a half and it has been an absolute blast. It also has been an absolute pain in the ass from time to time, but I guess that comes with the territory.
The main problem I –and I’m pretty sure Tom too- had with animating Gerrit was the fact that the character was not set up with an IK rig. The reason it didn’t have an IK rig was because, unfortunately, IK doesn’t work in Unity (although the animation support in Unity 4 looks promising). That left the guys with 2 options:
- Just work with forward kinematics for everything, legs and feet included.
OR
- Build an IK rig, bake the animation in Maya and get it into Unity.
Both options work, both options have drawbacks.
The biggest drawback for just using FK is: animating a character that has to walk, crouch, jump anything like that, is very tedious. Trying to keep the floor contact poses correct is almost impossible. Moving the root means moving the entire hierarchy, which means those pesky little feet are never going to stay where they should be. Flailing legs in the air is no problem, but apart from some very specific animations that’s not going to happen a whole lot.
Baking an animation works just fine, as long as you optimize the baking process and don’t export anything more than is necessary. Now, I’m not the leading expert on animation baking or exporting animations from Maya to Unity, but I got the feeling that things weren’t as optimized in this department as in the rest of the production. So I took it upon myself to see if I could smooth out all the kinks in this part of the pipeline.
And what’s the best way to get stuff done easily in Maya? Yup, back to MEL it was. I did a little bit of MEL scripting a LOOOOOOOOOOOONG time ago and never anything terribly complicated. Luckily for me, creating a script to get this working wasn’t complicated at all. Because basically, I didn’t have to create anything that wasn’t already built into Maya. It was just a matter of combining MEL commands and doing some basic checks. More on that later.
The first thing I had to do was to inspect Tom’s file closely and fix any errors that happened when the joints were mirrored. Maya sometimes throws little monkey wrenches in your operations, so you might end up with colorful names, such as “joint25”, “joint28” and “Left_WristJoint02” on the right side of your character.
Kevin has been making the levels and requires that everything has a strict naming convention. It makes his life easier if he doesn’t have to hunt for every file. Hell, Twan even made a Python script for Maya to make sure every file has the correct name (among other things). And being the “Nazi” I am (not a real one, don’t kill me), I’m pretty strict on naming everything correctly in Maya (usually).
I started on the IK controls when the skeleton was named correctly. These didn’t have to be super-duper-Pixar-eat-your-heart-out controls because the Gerrit model is only around 1800 polygons. Just normal IK controls in both legs were all we needed. I set up a foot roll and a toe flop to help with walking/running animations. Gerrit has long ears which flop around while he’s doing stuff, I’m pretty sure his two little toes do the same thing.
This Gerrit rig is way more animator-friendly in my humble opinion. I didn’t change much on the rest of the body, other than adding a control to both hands to make a fist. Having to rotate the digits every time is a pain in the ass. Especially if you want to make a fist. AND, on top of that, you have to keep an eye on 3 animation curves instead of just a single one from the Fist attribute.
Which brings me to the next little irk I had (and unfortunately, still have) with the current Gerrit setup. I suspect that at one point in time, the local rotation axes for all joints were reset. Other than trying to manually rotate them all, I don’t think there’s a way to get them back to their “normal” orientation. Normal as in pointing down the hierarchy. And I don’t even know if doing it manually is still possible after the character has been skinned.
There probably is a way, but we can work around this little problem. The only thing we have to keep in mind is that, in order to bend the elbow joint for example, we have to rotate that joint using all 3 axes. It looks a little messy in the graph editor, but it’s not going to kill anyone soon.
I also played around with a spline IK setup for the ears, but because there are only 3 joints and not a whole lot of deformation possibilities, I omitted it and just stayed with standard FK joints.
Personally, if I don’t make a whole lot of controls available for myself (or anyone else who’s animating) in the Maya scene itself, I tend to have some quick controls available through some sort of interface. It really depends on the animator (and the mood he’s in) whether these controls are useful or not. I tend to ping pong between using them and just rotating joints. If I’m working on the firefly character, I find them very useful.
Seeing as Gerrit now has IK controls that have to play nice in Unity, I decided to write a controller/exporter script. The script makes sure than no unnecessary information is being exported out of Maya. We’re developing for iPad, stuff needs to be small and compact or Robin will get a heart attack 
The way old Gerrit was set up added overhead to exporting him out. All extras on the character (eyelids, hair, leaves and clothes) were parented to the skeleton. This works fine, but it also means it’s exported with every animation. I don’t know for sure how Unity handles this, but all geometry is already on the main character in it’s T-pose. There’s really no need to have each and every FBX animation file to have geometry in it. It’s the skeleton we’re interested in, nothing else. So, with file size in mind, I just parent constrained all geometry to the joints. Nothing changes on the outside in Maya, but the skeleton is not bringing any excess geometry along for the ride when exported.
Hoooooooooowever. We DO need all geometry in Unity to be there and move properly, so 2 different FBX are needed. One file with no animation and one with the extra geometry parented to the joints. This is the standard Gerrit file to bring into Unity. It has all geometry + the skeleton. All other files exported from Maya don’t have any geometry in them. They just animate the existing geometry in Unity.
Makes sense?
It might be a bit of a hassle to set up, but it only needs to be done one time for the entire project. I have to talk to the guys on Monday (blogging on a Saturday, w00t) in order to see if anything needs to be changed for the Gerrit project in Unity.
All existing FBX files also need inspection because they might be exported with the incorrect naming convention. If the standard Gerrit file in Unity has joint names like Right_WirstJoint01 and the old FBX file has Left_WristJoint02 instead, the animation is going to look wonky in Unity.
On a side note, this happened to me last night. I made the animation of Gerrit falling over in Maya. I then exported that animation out using my script to see if it worked in Unity. It did work, expect the right hand wasn’t moving and neither were his fingers. It was late and I already spent the better part of the evening staring at my computer monitor, so I decided to take a look at it in the morning. Then the most freaking amazing thing ever happened. I actually dreamt about this problem and in my dream I realized the naming conventions didn’t match. When I woke up this morning I immediately checked the naming convention in Unity and voila! I found the reason why the hands weren’t moving.
Anyhoo, back to the main story. This is the script I made for our blue little fella:
As you can see, not all that complicated, but it does some clever selecting and combining of Maya stuff to get everything exported out the way it should be. Like I said earlier, most of what this interface does can be done manually in Maya, but clicking once or clicking 18 times makes all the difference in the world. Doesn’t it?
The top controls are used for selecting various parts and the entire hierarchy + all the controllers. I’ll probably change this a couple more times depending on how which buttons I use/need the most.
The Specific Attributes are used to control the foot rolls, toe flops and fisting making fists.
The Animation Baking buttons are used for… yup, baking the animation. When the animation is baked, the script cleans up all unnecessary curves and keyframes automagically.
The Export buttons are used for exporting, or baking and exporting. Usually “Bake and export”is the button I use. Unless I have some very specific reason to do it separately, this button is the one click solution to get everything exported correctly. “Export only”exports whatever is selected. When that button is used, I have to make sure that my selection is 100% correct. I usually only use this when I want to export a specific part. That “Undo bake”button is actually just an undo command.
Side note:
You’d think this can be added in the “proc BakeAndExport()”, but you’d be sadly mistaken. For reasons unknown to me at the moment, undoing from within that procedure undoes the hierarchy selection, not the baking process. I’ve tried just about everything to get the undo to work automatically, but it doesn’t want to play nice. I’m sure there’s a good reason why it’s not working, anyone who has the answer is more than welcome to let me know I usually test drive my animations several times in Unity when I’m working in Maya, so I always undo the baking process. The baked animation is saved to a different (FBX) file anyway, so no need to keep it in the Maya binary.
The last 4 buttons are general animation tools I use. These are things from the Graph editor, but I added them in here because they’re just one click away now.
I added the functionality to make the window dockable anywhere in Maya. This means that when I can’t steal Robin’s extra screen, everything fits nicely on one single screen.
