Maya LT - Good Value or Dead End?

C'mon in and play, what could possibly go wrong?

Earlier this year I took a risk and bought Maya LT, a 3d authoring tool that Autodesk claims is perfectly suited towards indie game developers, especially if you use their game engine (StingRay).

After six months of constant use in production of our next Unity game, we've come to the conclusion that the LT version was a mistake for us. But first-

The LOVE part... It's fast

After years of using & teaching Max & Maya, Maya LT is a breath of fresh air for the core modeling & animation tasks needed in our game.

1) It's nice and fast. Starts fast, runs fast, and is fairly stable (occasional freeze-ups). You can run multiple instances without really taxing your system.

2) Easily design PBS materials, or use & edit Substances which has been great.

3) It's priced smartly to make it accessible to your average indie developer. A 1-year license can be had for $240 US, or monthly for $30.

Using Maya LT, I built custom rig controls for my Mixamo characters, and happily animated away for months. But then some hard realities became apparent.

The HATE part... LT is where your data goes to die

1) It's a tomb - Scenes you create in LT cannot be loaded into full Maya. You are limited to FBX, so forget about migrating your IK rigs or anything else that uses maya-specific data.

This is a significant misstep on Autodesk's part. We're investing heavily to create assets for our game, but fully expect to re-use them again in other games. This means we're locked into LT permanently, or have to make the hard break and rebuild it all again in full Maya if we decide to upgrade.

2) Not Full MEL - Check out the product comparison list that compares LT to Full Maya. See those check marks next to MEL scripting? That would lead you to believe that LT includes full MEL, but in fact it's gimped. For example, MEL in LT does not allow "Fopen", "Fwrite", "FPrint", etc.. In fact they've closed off any way to share or move data outside of LT, including removing the AnimImportExport plugin.

3) Can't integrate with Source Control or External Export Scripts - Yes, the lack of .NET API support is shown on the comparison list. But what serious Indie Developer doesn't use source control? And you cannot run shell commands from the OS. So interfacing with TFS becomes a non-starter, gotta do it old school (wasting time & introducing human error).

There are other annoyances that are typical for a 3d Package. But the above 3 items alone have me seriously considering buying a full Maya license and re-building our assets there so we're not trapped in a diabolically closed, walled garden that would impress Apple engineers.

I understand all the security arguments and why Autodesk built all this firewall code. But honestly, developers write plugins and extend the tools to solve problems in production. Maya LT is a good short-term solution for limited content creation, but falls well short in it's goal of improving indie development.

Your Curve Editor is a Damn Liar!

Professor Bunsen explains Maya's curve editor to Beaker

This is one of those blog posts I'm writing in the hope that I've foolishly overlooked something obvious. Where some smart person would reply with "Hey n00b just click these 3 checkboxes and bada-bing you're all good".

Where do I start? I'm not an animator, but I need to be one for our current game project. I'm animating characters for a first-person action game we're building in Unity 5.

While a lot of the motion is specific, in many cases the player controller input drives movement, like looking around, and turning the character, etc.. So these actions need to use very high precision linear animations for a lot of different reasons.

In pursuit of trying to get all that movement correct we ran into tangent & curve issues in Maya that caused a fair amount of pain. 

If you animate a character in Max or Maya, you probably use IK and a control rig on some (or all) of the skeleton. When it comes time to export clips to Unity, normally you would bake everything down to the joints, either inside Maya, or upon exporting an FBX file.

And that's where the fun begins.

The first sign of problems cropped up when I needed to do a very short, precise animation that switched between two poses. The animation was three frames, where the first frame is a reference pose, and the next 2 frames are the target pose. 

My first inclination was to set frames 2-3 to Linear Tangents, both in & outgoing. In Maya's curve editor it looked right. But once we had it in Unity it was doing really weird stuff. 

Why? 

To check, we imported the FBX into 3ds Max and saw a big difference. Here is the same FBX file side-by-side in both curve editors:

Seriously, who is responsible for this?

Really? Yes, this is specifically a problem with how linear tangents are handled (and displayed) after the baking process in Maya. 

Maya was lying. Regardless of what tangent type is selected, once baked your selected tangent type will revert to Auto.

This little gremlin would rear it's ugly head again, when a few days later I had a joint rotation that had a linear curve, but once baked, the first & last keys would reset back to auto tangents! This is what I'm talking about in a simple example:

No idea why this happens. As you may know, there's two ways to bake keys in Maya. When you have an IK control rig, it's nice to use "Bake Simulation" to bake everything down to the joints. Then you can delete all the controls and be left with nice clean joints to export.

Or, you can skip all that, and let the FBX Export bake your animation (not as elegant, you can select the joints and use Export Selected, but it may still include control rig elements). 

Now, you would think that either of those baking options would produce the same curves result, right? Wrong.

In the most aggregious case, I had a turning animation where the character's hips would rotate from 120deg left to 120deg right. We use this as one of the axis of turning for when our character looks around.

The hip joint is rotated off cardinal axes in the character's normal pose (this is a Mixamo rig). If you turn the upper body from left all the way to the right, your hip joint would rotate on world Y (up) axis instead of local. So you would naturally end up with curves on all 3 axes.

What could go wrong? Well, here are the Maya rotation curves on the hip joint from using Bake Simulation vs. just FBX Export (with bake option checked):

Continuity be DAMNED

Aye Carumba! How could the animation you saw above be represented by those curves? What is that, gimball lock? I have no idea what I"m looking at here.

And that's where things get serious. Is this just bad math in Maya? 

Usually this is where I step back and say "ok, there's no way this could be the software, we must be doing something wrong"... only to arrive back at the same point. So then I thought, what if I did the same animation in 3ds Max, would the curves look the same?

Answer: NO

After a re-building the control rig & setting up constraints in Max, I created the same exact animation of the hip rotation (Note: in Max, there's no way to internally Bake Simulation like in Maya, you can only export FBX to bake). 

Once again we re-import the FBX back into Max and lo & behold, look at the (vastly improved) hip joint rotation curves:

Order is restored in the galaxy.

So let me make sure I have this straight:

1) Two 3d packages from the same company
2) Both cases using Euler rotation controller on Hip joint
3) 3 different curve/tangent results from the same joint in the same animation

See, this is the kind of thing that will rapidly accelerate the aging process for an old art dude like myself. 

Yeesh.

So now, please tell me I missed something really simple. Or stupid. I would gladly take either at this point. 

(special thanks to my collegues at Digital DNA Games for the endless support and assistance in untangling this hella knot).

#GamedevIsEasy

So many mouse clicks...

I really need to blog more about game development stuff, but sometimes you're so deep in the woods that it's kind of overwhelming to break it all down in a way that people could obtain something useful from it.

In the last six months my work has been dealing with Unity 5, here are just a few of things I've been focused on:

- working around the huge grenade Unity threw into lighting... just... FFS ENLIGHTEN!

- accordingly putting real-time, baked, and mixed lighting modes through endless trials in an attempt to get useable results

- creating big terrains (8km) with high density vegetation, road systems, and placed structures

- clothing swaps for characters, and building an efficient rig to support this (ongoing)

- vehicle rigs with character drivers, support for co-op players

Once we get this next game out I will probably spend a few weeks just writing up the process and challenges we've been going through.

Until then let's just say that nothing is easy, any substantial gains are a hard-fought, perpetual process of trial & error. :)