Unity 2D Game Development Cookbook

For this recipe, we need a Maya scene with a 3D model, any model with at least one material applied to it. A textured model is provided with the contents of this book.

In this recipe, we will show you how a model is exported from Maya using the default FBX exporter panel and how the FBX file will get imported in Unity.

The operation of exporting FBX files from Maya is simple: select the actual root node in the hierarchy and click on the Export button. But, as you can see, unless we use some precautions, the result of importing an FBX file from Maya is that the model is flipped by 180 degrees on the the y axis in Unity. This happens because the blue arrow that represents the z axis in Maya points in the opposite direction in Unity. As a consequence, the model shows its back to Unity's camera.

As we write, there are rumors that this issue is going to be solved in forthcoming Unity versions. For now, we will provide custom solutions we have used ourselves.

Open the scene again with the model we used before and be ready to follow our instructions.

In this recipe, we will show you how to use groups and hierarchies in Maya to export a model that will not show its back once it gets imported into Unity. Have the Maya scene open on your screen.

By using one group for flipping the model on the y axis and another to make a selection featuring neither rotations nor translations for the export, we made sure that the FBX file won't have any unexpected rotation or position offsets that will affect its behavior once it gets scripted into the code in Unity.

Another technique we will only mention here is to use your programming skills and code an AssetPostprocessor class to handle the process automatically.

AssetPostprocessor is a class in Unity, provided with several methods to act on the pipeline for importing assets into Unity.

What one could do is add a custom attribute to the model in Maya, something like turn me 180 degrees on the y axis when imported, and let the AssetPostprocessor class read this attribute and perform the transformation.

You can learn more about the AssetPostprocessor class by checking the scripting reference guide at http://docs.unity3d.com/ScriptReference/AssetPostprocessor.html.

For this recipe, you just need the Maya model we used so far.

As you can see, there is quite a lot that can be tweaked with regard to exporting FBX files from Maya. What we offered here was a basic outline that will do for most cases. It is very likely that, depending on the specific need that would rise with your own project, you may need to use different settings on specific tabs. In such cases, we suggest you to refer to the official Unity documentation, where an entire section dedicated to exporting from Maya is available.

Anyway, at some point, you will have determined the optimal settings configuration for your project and won't need to reset them every time. Once you get your optimal configuration, the only change will be with regard to the Animation tab. Don't worry about it now; we'll get to importing animations soon.

If you check Unity's reference manuals (http://docs.unity3d.com/Manual/HOWTO-ImportObjectMaya.html), you may learn that Unity actually imports native Maya files, which means you can directly open Maya scenes (*.mb and *.ma files) in Unity. You can therefore ask, Why export FBX files into Unity at all?

There is more than one reason actually; one that is worth $4,000 is that FBX files are far more shareable than native Maya files. For example, to open a Maya scene in Unity, you must have Maya installed or the file won't open. If you expect to exchange files between people on their own PCs, you cannot assume that each one of them will have a Maya license. It will thus be safer to use formats that don't require additional costly software, as is the case with Maya (almost $4,000 per license).

That said, it is still quite useful to open Maya scenes in Unity. For example, in Unity you can immediately check the result of modifications made on a file in Maya without the need to export an FBX file with each new edit. Also, as already stated, Maya LT is going to export FBX file directly into Unity.

For this recipe, we will basically resume from where we left the previous recipe. After having exported the model from Maya, launch Unity. By default, Unity always opens up to the last project you worked on.

As already said with regard to the export settings in Maya, what we provided here was a default reference to set an FBX file imported in Unity. You may need to change some of these settings based on specific matters related to how you modeled your object in Maya and\or how you exported and\or planned to use it as a Unity game object.

We suggest you experiment with Inspector settings to get a wider grasp of the meaning of each setting and refer to the Unity documentation available at http://docs.unity3d.com/Manual/HOWTO-exportFBX.html when you have questions.

When exporting animations, two approaches are possible. One, which we will adopt in this book, is to keep things on separate files. With this approach, we export one FBX file for the model, the materials, and the rigging (as we did before), and one FBX file for each individual animation, such as idle, run, jump, and the like.

The other approach is to export everything on a single file. In this case, the exported FBX file will consist of the model, materials, rigging, and a timeline containing the frames for the entire animation set of the character. We will discuss this second approach later.

As usual, we took care of providing the required assets (animated Maya scenes for the model) in case you don't have any.

As we will see in the following recipe, where we will edit the settings of the imported animation in Unity, what we get is an FBX file containing an animation clip named idle, which represents the idle animation for our character.

As we said before, it is possible to trace the animation clips on a single file\timeline and export all character animations in one FBX file; in this case, however, additional operations are required when compared to the one-file-one animation technique.

With a single file containing all the clips, Unity is not capable, by default, to read the timeline imported from Maya and automatically detecting the individual clips, and you end up with a single, most likely long, timeline named track01 containing all the animations.

So you have to split the whole timeline by yourself, naming each clip individually and manually setting the start and end frames for each one of them in Unity Inspector.

If you think about a typical working pipeline with different people taking care of different operations, you may find your animators manually writing a text file of some sort with information regarding animation clip names and their reference frames. The animators then pass on this text file to someone responsible for taking care of importing animations in Unity. This last guy would also be responsible for typing the data found in the text file into Unity Inspector. A way of doing things that can easily lead to human errors, as you can imagine...

This is the reason why we prefer using separate FBX files for each animation clip.

It is also possible to automate the exporting process so it doesn't become a time-consuming activity, but you may need a programmer for this.

The idea is to script a piece of code in MEL to handle the job. MEL is the scripting scaffold of Maya: any operation you perform in the Maya editor has an equivalent instruction in MEL. Since performing hardcoding in the MEL scripting language would go beyond the scope of this book, we just provide a few references here for those interested. The list of MEL exporting commands is available at http://download.autodesk.com/us/fbx/20112/Maya/_index.html.

An example MEL script, courtesy of James Kyle, is available at http://www.jameskyle.net/2013/03/maya-to-fbx-batch-export/.

For those of you who are interested in automating the exporting process, there are ways, pretty elegant too, that require advanced programming skills.

One way is to create a Maya Embedded Language (MEL) script that reads the scene in Maya and exports what you need, based on the settings you define for the exporting process. MEL is the programming language behind Maya; any operation performed in Maya can be converted into a scripting instruction that will achieve exactly the same result. By using MEL, you can thus create a script that automatically exports animation clips into Unity on one or more FBX files, helping you save time (and reduce the risk of errors).

Another option is to configure Maya to generate an XML file that describes the animation data stored in the timeline of a model (animation names, starting\ending frames, and the like), and then read this XML file from Unity to automatically create the required FBX files.

Both these approaches are very similar to using the post-processor to read custom attributes from Maya, as we discussed earlier.

If you'd like to go that way, you can refer to the following links:

Again, we pick up from where we left the previous lesson. Open Unity and select the animated FBX file in the project panel.

Let's begin with a few words on the topic of root motion, as Unity Inspector displays several options about it.

Root motion has to do with controlling the actual position of the mesh with regard to its collider while animations are being played. Most animations happen in place, meaning that the mesh and the collider don't actually move around as the character is animated. This may be the case for examples of walk and run animations.

There are other animations though that require the mesh and collider to actually move or rotate in the 3D world as the animation is played. Actions such as strafing, jumping, and other in-game specials require the mesh and the collider to change their position and rotation in the 3D world as the animation is performed.

By setting the properties of Root Rotation and Root Position groups, you control whether the collider should rotate or move with the mesh during specific animation clips.

In a walk animation, the start and stop root orientations and positions in world space are identical. In such cases where animations are acknowledged by Unity with a green light in Unity Inspector, it is recommended to flag the Bake into Pose option in the Root Transform Rotation group and set Root Node Rotation from the drop-down menu. Also, flag Bake Into Pose in the Root Transform Position (Y) group and set Root Node Position from the menu.

As for the Root Transform Position (XZ) group of options, the manual recommends using them for long, idle animations, where the repetition of many frames could lead the mesh to drift from its collider in the long run. In such cases, it is recommended that you bake the position on the x and z axes as well.

Latin speakers used to say "Repetita iuvant," meaning repetition helps. The settings provided here are to be intended as general, default settings that may not fit into any situation. For example, you may find yourself having to set Scale Factor in the Model tab for the animated FBX file too in order to prevent the animation from not fitting the model rig. Alternatively, you may need to tweak the Root Transform Rotation and Root Transform Position settings differently, depending on how you rigged\animated your model with specific animation clips. As usual, we recommend that you refer to the Unity documentation at http://docs.unity3d.com/Manual/AnimationsImport.html whenever you have questions.

The Rig tab in Unity Inspector displays an option that we didn't mention here: Animation Type. You configure this option to select whether you want your character to be animated as a humanoid or a generic object, as it could be with a vehicle, a ball, or whatever.

Also, when a rigged FBX file is imported into a project, Unity automatically creates a so-called avatar out of it. This task is generally performed automatically by Mecanim, the built-in tool responsible for animation setting and management; we will discuss this in detail in Chapter 3, Animating a Game Character.

Mecanim has routines that examine the skeletal configuration of a rigged model imported in Unity and then recompute it into a general template it can interpret. This template is called the avatar. Once an avatar has been created, other animation clips can be targeted to that same avatar. This is how multiple animation clips are linked to a single character model in Unity.

In the recipe, we configured the model scale and material in the Model tab only for the static version of the model; in the Rig tab, we set the Avatar Definition option to Create for this model. For animated clips, on the other hand, we didn't configure the Model tab, and we set Avatar Definition to Copy From Other Avatar with a reference to the static avatar. This assumes Mecanim succeeds in interpreting the rigged model.

There are cases where for some reason Mecanim is unable to correctly compute the avatar; alternatively, you may just want to make changes on your own. In such cases, it is possible to manually edit the avatar in Unity Inspector and check that all bones required by Mecanim are correctly named and in place.

A recipe about setting up the avatar would go beyond the scope of this book, as it has a lot to do with modeling and rigging techniques, which are beyond the scope of this book.

Refer to the Unity manual at http://docs.unity3d.com/Manual/AvatarCreationandSetup.html. Besides this, if you are interested in delving more into this matter, we suggest the many tutorials available on websites about game development and 3D graphics. For example, digital tutors offer many exceptional tutorials about Unity in general and Mecanim in particular; we recommend you check them out.