Bl
Bl
Bl
Bl
Bl
You are here:   Home »  Products »  PolyTrans-for-Maya  
Bl



How Hierarchies Convert Between Maya, PolyTrans and Other 3D Programs




Arrow Overview: How Hierarchies Convert Between Maya, PolyTrans and Other 3D Programs

One of the truly hardest parts of writing a good data translation system is the proper and clean conversion of object hierarchy. Object hierarchy defines the relationship of one connected object to another, such as a human hand connected to the forearm, connected to the upper arm and then connected to the torso.

3D computer graphics complicates hierarchy conversion with such issues as pivot points, different methods of applying or inheriting transformations and related animation curves and whether object nodes can be directly connected to other object nodes or whether they can be connected to 'null nodes' (joints) only.

The entire jist of this overview is to explain that Okino's PolyTrans software does not allow object nodes to be connected directly to other object nodes. Many 3D software packages available today (3ds Max, LightWave, Maya, etc). began their lives in the early to mid 1980's as other lesser 3D software programs (CAD-3D, Videoscape-3D, Alias 1.0); in those days it was common to allow objects to be connected to objects. For our discussion, we define an 'object' as some type of data inside a 3D program which encapsulates raw geometry data, such as meshes, NURBS or quadrics. 3ds Max and LightWave still allow objects to be connected to objects at the time of this writing.

When Okino began development of its NuGraf and PolyTrans software in 1988 it realized the limitations of allowing objects to be connected to objects: if you move a parent object then all children objects move with it. Programs such as 3ds Max get around this limitation by internal hacks in which anti-transformations are applied to the object children to keep them stationary while the parent object is moved about the scene.

In 1988 Okino realized that a pure DAG hierarchy system would be much better to use to store object hierarchy. The idea came from the Alias Research 'Power Animator' software package of the time. In this system the hierarchy tree is formed by 'null nodes' (think of them as joint nodes) which form a type of 'skeleton'. The relative location of each node defines the location and orientation of each joint in a hierarchy. Then, the objects themselves (which contain the geometry) are hung off each null node.

To put it another way, the hierarchy tree is defined by 'null nodes' (no geometry) and all object nodes (which contain the geometry) are always leaf nodes in the tree.

Or to put it in very simple terms, PolyTrans only allows null nodes to be connected to other null nodes. In addition, objects can only be connected to null nodes. 12 years after choosing this system, we were surprised to see that Autodesk Maya implements a similar hierarchy DAG system, although using slightly different visual representation rules. In the latter part of this overview we will show how the PolyTrans hierarchy can be directly converted to equivalent Maya hierarchy for the same visual interpretation.

This can sound very confusing but the following diagrams are meant to provide a visual counter-explanation.

Arrow Hierarchy as Defined by 3ds Max (and LightWave)

In many 3D software packages which originated from the mid-1980's the software would allow objects to be directly connected to other objects, objects to be connected to null nodes, or null nodes to be connected to other null nodes. This is exemplified by the following diagram:

To reiterate, null nodes are nothing more than an object node with no geometry associated with it; they are used to define a relative position and orientation in a hierarchy or skeleton to which other children can use as a new local coordinate system. In PolyTrans lingo these null nodes are called 'Yellow Folders', or 'Empty Instances'. In 3ds Max these are called 'Dummy Objects' and in LightWave these are called 'Null Objects'.

These null nodes often contain a 4x4 transformation matrix that define the relative location and orientation in the hierarchy. In addition, they sometimes contain a 'pivot point' definition which defines yet another local coordinate system about which the animation, scales and rotates are to applied. How the pivot point is defined is completely different in PolyTrans, Maya, 3ds Max and LightWave (if only we could have all sat down and had a meeting in 1985 to come up with a general solution!). PolyTrans has the most general pivot point system (a secondary 4x4 transformation matrix); 3ds Max and LightWave provide for a translation-only pivot point; Maya assumes the pivot points are located at the origin of each mesh.

Arrow Hierarchy as Defined by Okino's PolyTrans and NuGraf

As mentioned above, Okino decided to implement its hierarchy system as a series of DAG nodes into a DAG tree (DAG means 'directed acyclic graph'). In this system the hierarchy is defined by connected null nodes, and objects can only be the leaf nodes in the tree. This is a good system because objects can be moved without affecting any of their children. In addition, if any branch of the tree is to be moved then only the parent null node has to be selected and transformed. If you don't want a specific portion of the hierarchy tree to be affected by transformations, then DAG trees implicitly allow for this.

The following diagram is a DAG equivalent to that same 3ds Max hierarchy diagram shown above. All we have done is to replace each object node with a new null node, and propagate the original object nodes to be children of the new null nodes.

This hierarchy behaves exactly the same as the original 3ds Max hierarchy. Several times per year we receive email saying that PolyTrans has bugs in it because the hierarchy has been mucked up. We assure all readers that the hierarchy will work the same in PolyTrans as it did in the source 3D software program.

Arrow Hierarchy as Defined by Maya

After we began development of the new PolyTrans-for-Maya software we quickly realized that Maya inherited (no pun intended) the same DAG hierarchy system as that used by the early Alias Research software packages, in particular Power Animator of the late 1980's (from which the PolyTrans DAG hierarchy system was chosen).

Although opaque to users, Maya too only allows null nodes to be connected to other null nodes, and objects only to be connected to null nodes (in comparison with 3ds Max and LightWave which allows objects to be connected to objects).

In Maya, everything works on the principle of 'Transform Nodes' with optional child 'Shape Nodes'. All the hierarchy nodes you see in the 'Outliner' or the 'HyperGraph' are actually just the Transform Nodes. These Transform Nodes contain the 4x4 transformation matrix, the assigned animation curves and the pivot point information. If there is geometry associated with the transform node then it is stored in a Shape Node which is made a child of the Transform Node; the material and textures are assigned to the Shape Node only. Normally the Shape Nodes are not shown in any display window inside Maya unless you enable the 'Shape Nodes' option.

The Maya hierarchy system is very similar to that in PolyTrans. Maya uses the concept of Shape Nodes connected to Transform Nodes whereas PolyTrans uses the concept of Object Nodes (equivalent to Shape Nodes) connected to Empty Instances (Transform Nodes). In PolyTrans the object nodes (turquoise icons in the user interface Selector Window) are always visible whereas in Maya they are implicitly made hidden. To make the imported PolyTrans hierarchy look cleaner within Maya, the PolyTrans Object Nodes are converted into children Shape Nodes of a corresponding Maya Transform Node; this will make the hierarchy appear cleaner.

Another nice benefit of this clean-up process is that the imported hierarchy into Maya will now appear to be exactly the same as it did in 3ds Max or LightWave. The relationship of the nodes, and the naming of the nodes will be the same in Maya as they appeared in 3ds Max or LightWave; however, Maya internally makes the distinction of having the object nodes be hidden children of the main Transform nodes which form the hierarchy tree.

It should also be noted that in certain cases PolyTrans may have to introduce new Transform Nodes into the Maya hierarchy tree when animation is present. As mentioned previously, Maya does not have the same capabilities to import pivot point information as other 3D programs, especially if the pivot is associated with a Transform Node with no child Shape Node. If a node-pair contains a Shape Node then PolyTrans will embed the inverse pivot point in the mesh vertices or NURBS Cvs; if a Transform Node exists with no corresponding Shape Node geometry them PolyTrans must add a new child Transform Node called an 'anti-pivot' node which will contain the inverse pivot point location and orientation. All of this is necessary to place the proper pivot points into the hierarchy graph when animation data is present.