It’s important to understand the limitations when creating control rigs for the purpose of exporting them as an FBX file to Unity. By working within these limitations, you’ll ensure that the work you do in Maya will carry through correctly to Unity.

Supported Deformers

• The only deformers that can be exported in FBX files are skinclusters and blendshapes. It’s more limiting, but you’ll learn to get crafty about it (think of non-uniform scaling, for example).

• Lattices, clusters, wraps, and nonlinear deformers are not supported.

Blendshapes

• Only static blendshapes can be used. This means you can’t connect a mesh that’s being driven by a skincluster, or other deformers as a blendshape into the final mesh.

Skinning Method

• Classic Linear is the only supported skinning method in Unity (Dual Quaternion and weight blended are not supported).

Max Influences

• In Unity, four joints per vertex is the recommended setting for standalone games where performance is very important. For film and animation, this value can be as high as you want.

Namespaces

• Namespaces cannot be used in Maya: they make it impossible to assign animations to a pre-existing rig in Unity. If you need to create a reference in Maya, merge the namespace into the root during reference creation.

When exporting an animation from Maya using the FBX format, you may notice that Unity displays an animation rotating in a abnormal way compared to the Maya animation, such as a “jumping” or “flipping” effect. This is not an error that comes up because of the Unity import, but is a side effect of exporting to the FBX format.

FBX files merge the Joint Orient and Rotation values of a joint together instead of keeping them as separate values, like Maya does, resulting in what’s called gimbal lock once the file is imported to Unity. Gimbal lock happens when a rotation is resolved with a jump or flip (going from just under -180° to just over 180°).

The current workaround in SYNK is to bake each frame during the animation export in Maya and turn off frame interpolation in Unity. This makes it so that gimbal lock still happens, but is virtually invisible.

If for some reason we do not want to bake each frame or do want to interpolate keyframes in Unity, a complicated yet effective solution in Maya would be to set up your rig in a way that separates the Joint Orient on the parent node and the isolated Rotation animation on a child node.

For example, in the image below, the Joint Orient of the control rig is set up on the rotation axis (X, Y, Z) of the nodes ending in “_zer” (standing for zero). Doing this will zero out the rotation of the child node. Next, we set the Rotation of the control rig joint on the child node ending with “_jnt”:

Open	Open Open

Open	Open Open

This structure will prevent the values from going under -180° or over 180°. This way, the rotation values in the FBX file will be the same as in Maya and will appear correctly in Unity. It is also imperative to assign the correct rotate order to the different joints. Remember that similar joints in separate hierarchies, such as FK, IK, Ctrl, and Rig, should have the same rotate order.

Squash and stretch on a character can look different in Unity than in Maya or it can even look deformed. This is because the method of calculating the scaling in FBX files is different than in Maya (or most DCC): it does not apply a segment scale compensation according to its parent node, like Maya does by default. In addition, non-uniform scaling (different values for scaleX, scaleY, and/or scaleZ) can cause shearing issues due to the axis not necessarily being in the same position and rotation.

The current workaround in SYNK is to completely forbid scaling on joints and only use translation & blendshapes for squash and stretch.

If for some reason we absolutely need joint scaling for squash and stretch, a complicated yet effective solution in Maya would be to isolate the Scaling on a separate node, which should end with “_env”, and bind the skin to this node:

Open

The “_env” joint contains all of the scaling information. 

There are some important things to note about the “_env” nodes. They never have any children (apart from constraints) because their scaling would affect the scaling of their children. They also never move nor rotate, they only scale and they get their scaling value by constraints or connections to the final rig.

1st joint (or transform - e.g.: Hand_zer) - Gets the default values from the default pose of the final control rig (isolate the joint orient and bake it - never changes once set) - This joint can be a child of other “_jnt” joints if needed.

2nd joint (e.g.: Hand_jnt) - Child of “_zer” that isolates the translation and rotation of the final control rig - Other “_zer” children hierarchy joints are children of this joint.

3rd joint (e.g.: Hand_env) - Child of “_jnt” (never translates or rotates) that holds the scaling independently (this one never has any children). - Only when using squash and stretch

When using “_zer” joints and “_jnt” joints, the skin should be bound to the “_jnt” joints, since these will have the correct animation transforms. When using “_env” joints for things like squash and stretch, elbow lock with IK stretching,... use the “_env” joints for skinning instead. Like discussed before, this will prevent scaling issues.

To bind the skin, head to Skin > Bind Skin.

When you bind your mesh to your skeleton, there are a few important settings you should use:

1. Skinning Method: Use the Classic Linear skinning method. The other options (Dual Quaternion and weight blended) are not supported. 

2. Max Influences: This is the max number of joints that can influence any single vertex on a mesh. Set this value to 4 for standalone games or more for film and animation.

3. Maintain Max Influences: Checking this box will ensure you do not unintentionally exceed the max influences while painting skin weights.

Open