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

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 hassle than you’d first expect. Some others are:

• Maya .ma (at least until the current v.2010) is built up by mel. Mel is Turing-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 ones. 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.