Importing Maya ASCII to game

Question

I am currently working on creating an import-based pipeline for my indie game using Maya ASCII .ma as source format and my own format for physics and graphics as output. I'll keep stuff like range-of-motion attributes inside Maya, such as for a hinge joint. Other types of parameters that needs a lot of tweaks end up in separate source files (possibly .ini for stuff like mass, spring constants, strength of physical engines and the like).

The input is thus one .ma and one .ini, and the output is, among other things, one .physics and several .mesh files (one .mesh file per geometry/material).

I am also probably going to use Python 3.1 to reformat the data, and I already found some LGPL 2.1 code that reads basic Maya ASCII. I'll probably also use Python to launch the platform during development. Game is developed in C++.

Is there anything in all of this which you would advice against? A quick summary of things that might be flawed:

• Import-based pipeline (not export-based)?
• Maya (not 3DS)?
• Maya ASCII .ma (not .mb)?
• .ini (not .xml)?
• Separation of motion attibutes in Maya and "freak-tweak" attributes in .ini (not all in Maya)?
• Python 3.1 for building data (not embedded C++)?

Edit: if you have a better suggestion of how to implement the physics/graphics import/export tool chain, I'd appreciate the input.

Answer 1

As a general serialization format that's both human readable and human writable, has excellent Python support (and, well, any language support really), you might want to consider using YAML or JSON over ini files or XML.

XML could be acceptable in your case if you never generate files by hand.

One of the advantages of JSON and YAML is typing: both formats are parsed down to Python lists, dictionaries, floats, ints... Basically: sane python types.

Also, unless you're sure that every library you'll ever use works on 3.1, you might want to consider sticking with 2.x for a bit due to library availability issues.

Answer 2

If you really want to do this, you should be aware of a few things. The main one being that it's probably more of a hazzle than you'd first expect. Some others are:

• Maya .ma (at least until the current v.2010) is built up by mel. Mel is touring-complete, but the way the hierarchical scene is described in terms of nodes is a lot more straight-forward than “code”.
• Add error-handling early or you’ll be sorry later.
• You have to handle a lot of different nodes, where the transforms are by far the most obnoxious once. Other types include meshes, materials (many different types), “shader engines” and files (such as textures).
• .ma only describes shapes and tweaks; but very rarely defines raw vertices. I chose to keep a small “export” script inside the .ma to avoid having to generate all primitives exactly the same way as Maya. In hindsight, this was the right way to go. Otherwise you have to be able to do stuff like
  1. “Create sphere”,
  2. “Move soft selection with radius this-and-that from here to there”, and
  3. “Move vertex 252 xyz units” (with all vertices implicitly defined).
• Maya defines polygons for meshes; you might want to conve rt to triangles.
• All parameters that exist on a certain type of node are either explicitly or implicitly defined. You have to know their default values (when implicitly defined),
• Basically, an object is defined by a transform, a mesh and a primitive. The transform is parent of the mesh. The transform contains the scaling, rotation, translation, pivot translations, and yet some. The mesh links to a primitive and vice versa. The primitive has a type (“polyCube”) and dimensions (“width, height, depth”).
• Nodes may have “multiple inheritance”. For instance, a mesh instanced several times has a single mesh (and a single primitive), but multiple parents (the transformations).
• Node transforms are computed like so (see Maya xform doc for more info):

vrt = getattr("rpt")
rt = mat4.translation(vrt)
...
m = t * rt * rpi * r * ar * rp * st * spi * sh * s * sp

• I build my engine around physics, so the game engine wants meshes placed on physical shapes, but when modeling I want it the other way around. This to keep it generic for future applications (“meshes without physics”). This tiny decision caused me serious grief in transformations. Linear algebra got a brush-up. Problems in scaling, rotation, translation and shearing; you name it, I've had it.
• I built my import tool on cgkit’s Maya parser. Thanks Matthias Baas!
• If you’re going to do something similar I strongly recommend you peeking at my converter before writing your own. This “small” project took me three agonizing months to get to a basic working condition.

Answer 3

You should consider using an export-based pipeline or a standardized file format such as OBJ or COLLADA instead of re-implementing a .ma parser and replicating all the Maya internals necessary to interpret it.

The .ma/.mb format is not intended to be read by any program other than Maya itself, so Autodesk does not put any effort into making this an easy process. To parse it 100% correctly you would need to implement the whole MEL scripting language.

All of the Maya-based pipelines I've seen either first export content into a standardized file format, or run MEL scripts within Maya to dump content using the MEL node interfaces.

Note than Maya can be run in a "headless" mode where it loads a scene, executes a MEL script, and exists, without loading the GUI. Thus there is no problem using it within automated build systems.