UDK FBX 2012 Animation Pipeline

Recently I have started to work more closely with the AnimTrees inside of UDK. Along with this, I'm also trying my hand at animating characters. Since I've started working more closely with the animation side of things, I've discovered some irregularities in the FBX pipeline. Here are some interesting bits.

1. My first hurdle was to get my skeletal mesh inside of UDK. For someone who hasn't worked much with UDK, this was incredibly frustrating to start with. I found out that the FBX export will not cooperate if the geometry and the bone hierarchy structure are inside another hierarchy. These two apparently need to be placed inside the world space when it comes to exporting.

2. The FBX exporter allows you to bake animations, with only one problem: You can't bake translations. I have yet to find any kind of documentation regarding this problem, or anyone else coming across this problem. It's incredibly picky as to which bones it wants to bake translations. In order to achieve baked translations, you need to go to Edit > Keys > Bake simulation. Make sure you have all the bones selected, and bake the desired animation. Unfortunately this breaks the rig, so you'll have to export, then undo your baked simulation. This then leads to the next issue.

3. Say you just baked your animation starting from key frame 50 and ending in 109. Export it, import the FBX animation into your AnimSet, and preview it. Blank frames. Maya thought it would be cool if you had those extra frames at the beginning, so instead of exporting 59 frames it went ahead and exported 109. So those first 50 frames are garbage. They do nothing. Your character sits still for 50 frames, then plays the animation.

So enough ranting. Here is the pipeline I used to work around all these issues:

The skeletal mesh, in T pose, is kept separate from all the animations. Each individual animation is contained in it's own Maya file. They all start from frame 1 and end where needed. This will keep Maya from exporting the blank frames. Once I am satisfied with my animation, I save and proceeded to bake my animation on to my skeleton. This will make sure I get translation values on my bones. Once exported, I can import my FBX animation into UDK and not have any problems.

Unfortunately this means I have an FBX file per animation, but it saves my sanity, if only a little bit. I still enjoy working with animations and the UDK, and I'm also hoping someone else will find this post helpful, or peak enough curiosity to ask me questions/give me advice.

School and such

Been a while since I last posted an update and I just wanted to keep my blog alive. This spring is my last semester as a graduate student at the University of Texas at Dallas. As part of my graduate project, I am working on an animated short, that you can find here http://cabinfevershort.blogspot.com/ and I'm having to teach myself animation, as we lack animators for the project.

It's coming along very well! In fact I'm looking forward to posting some of the shots I personally worked on. I'm very proud of the work I've been doing for this short and I want to share it on my portfolio, but I want it to be perfect. So I'm still around, just working incredibly hard to finish my degree. I'm hoping to have something posted within the next week!

Rigging Philosophies: Joint naming conventions

This a new post to kick-start a new section of my blog. I was recently asked what were some of my "beliefs" when it comes to rigging. Basically how I think rigs should be made and how they should function. This will be a nice way to really start analyzing why I do things the way I do them. So let's get started.

When it comes to naming joints, some might think that naming them anatomically would be an ideal naming convention. Keeps things organized and you know exactly what that bone's function is. So why is this a problem? By default, Maya likes to organize deformers in the component editor alphabetically. This can be a problem when you start having clavicles, shoulders, and elbows. They can be misplaced within the component editor and make it difficult to see point weights side by side. Yes, you can filter out the zero'd channels but what happens when you give points a full weight of 1? going back and searching for it's neighboring deformers can become a pain! So here is my simple solution: Use numbers!

Let's use an arm for an example, starting from the clavicle: Instead of starting out with bind_L_clavicle01 lets go with bind_L_Arm001. From there we start getting our arm, starting from 001, 002, 003, and so on. With this naming convention, you know that it's on the left side arm, and that it's going to have geometry bound to it. Best part about this, in the component editor, all of your arm joints are side by side, making it incredibly easier to read and sort through.

So you might be asking yourself "This is great and all, but what about fingers?" I simply start with the thumb carpals and begin naming them like so: bind_L_D1_001, bind_L_D1_002, and so forth. With this naming convention, I know that it is a digit on the left side, and D1 means that it is the thumb. Now this does require a bit of mind training as you always start from the thumb and fan out from there. Once again, this is great because now all my fingers are all clumped together and easy to find.

I have found this naming convention to help me be a more efficient weight painter as well as making it easily readable for someone down the line. Now I only use this convention for deformers and joints in general. For controls I use a more anatomical approach as it makes more sense for an animator. Controls are also the representation for that area of the body and should be named as such, where as a deformer is part of the underlying framework of a rig.