This brief course is designed for the current CG industry professionals who would like to expand their technical understanding of Autodesk Maya software, and learn how best to utilize its advanced features to build efficient and robust CG pipelines.
The architecture section covers the fundamentals of the Maya data model and some of its core features. It is by no means going to be an exhaustive reference, but it should provide a keen understanding of Maya mechanics that will allow you to design better solutions and troubleshoot problems.
The vast majority of all user interactions with Maya happens through the manipulation of either the DG or DAG. The DAG and DG are two seperate systems and serve different purposes.
DG (Dependency Graph) is really at the heart of Maya, it takes part in modeling, animation, and simulation. The purpose of the DG is to take some input from the user, such as numeric values or geometry, perform some work with this data, and output a new result to the user. The DG can be visualized in the Node Editor or the Hypergraph (Connections mode).
At its core, all the work is performed by individual, self-contained nodes. Each node defines a series of attributes to accept input data and output the work product. These nodes can be connected together through their attributes, therefore constituting the dependency graph.
You can create cyclic connections between nodes in the DG (ex. constraints) as long as there is no direct affects relationship between the connected attributes (or DAG side effects).
The attributes defined by the node represent a kind of an interface for the node to the rest of the graph. Maya supports attributes of various types, such as simple numeric attributes for integers and floats. In addition, complex attributes are supported and can hold data such as string, numeric arrays, and geometry.
In many cases it is useful to treat a group of related attributes as a single entity (ex. color or translation), for this purpose Maya provides a concept of Compound Attributes. A compound attribute behaves as a parent container to any number of child attributes of arbitrary type. Two compound attributes that have identically defined children can be safely connected together in the DG.
Any attribute can also be defined as an array, in which case it can hold an arbitrary number of child elements of the same type. Each array element, visualized by square brackets in the GUI, can be independently set or connected via a sparse index (note that array indexing is 0 based).
Note that Maya documentation recommends that array plugs should not be connected together.
Additionally, attributes have several other properties that control their behavior, such as keyable and locked.
You will frequently see a reference to attribute plugs in Maya documentation and API usage. You can think of an attribute as a description or template defined for a node type, while a plug is an actual physical entity for the attribute on a specific instance of that node.
DAG (Direct Acyclic Graph) is essentially the object hierarchy, it builds on top of DG and provides a way to describe the parent-child relationships. You can visualize the DAG in the Outliner or Hypergraph (Hierarchy mode). This DAG relationship can further be modified using the Parent or Group commands.
You can traverse the DAG hierarchy using the arrow keys, up-down to navigate the parent-child relationship, and left-right to navigate the siblings
Practically speaking there are two types of objects that are involved in defining the DAG hierarchy, a Transform node and a Shape node.
A transform node defines a transformation in space. The transformation can be modified by setting the values of translation, rotation and scale attributes. A transform node can have any number of children and at most a single parent.
You can visualize the transformation in the Viewport by turning on Display->Transform Display->Local Rotation Axes
The transformation data computed by the DAG is made available to the DG through several attributes on the transform node:
These attributes can freely participate in the construction of the DG, however keep in mind that, because of the computation performed by the DAG, they have an implicit dependency on the translate, rotate, and scale attributes of their ancestors in the hierarchy.
For any given transform, in order for Maya to figure out where it is located in space, it needs to walk up the parent transform until it reaches the scene root and combine all the transformations along that path. For this reasons, deep hierarchies of transform nodes should be avoided if possible to improve the scene performance.
You can set the Inherits Transform attribute to Off to make it so that the transform node ignores the transformation of its ancestors in the hierarchy, this can be beneficial if the transforms are used for grouping purposes only.
Another type of DAG node is shapes, such as mesh, nurbsCurve, or locator. Shape nodes are necessary when it is advantageous to display persistent visual representation of graph data in the 3D view, such as mesh geometry or light direction. However, unlike transforms, shape nodes do not provide neither the parenting nor transformation information, therefore shape nodes are required to have a transform node as a parent to define where in space geometry is located.
A set of transform nodes, starting with the scene root to a given transform node or shape node is known as a DAG path. It is expressed in Maya as a string with the nodes in the path separated with the pipe ‘|’ character, for example |pSphere1|pSphereShape1. Maya allows DAG nodes to have the same name as long as they are not direct siblings in the DAG hierarchy, therefore a full DAG path provides a unique identifier for a specific DAG node. In addition, attribute names and component indices can be part of the DAG path as well.
Note that it is generally a good practice to make sure every node has a unique name across the entire scene. Likewise, it is also recommended that custom scripts are written to handle duplicate names by always referencing the full DAG paths of nodes.
Maya supports instancing of DAG nodes. Instancing allows a node to have more than one parents and therefore appear to be in several different places at once, without actually duplicating the underlying data. All instances of a node share the same attribute values and geometry data, however you can assign a unique material to each instance. Therefore, instancing is practically useful for shape nodes, and can be used to greatly reduce the scene size and improve its performance.
In order to be able to refer to an instanced node, a full DAG path is required.
You might have noticed that attributes that are related to DAG are always arrays (ex. worldMatrix or worldMesh), this is necessary to accommodate instancing.
Keeping track of system or semantic relationship between different DG and DAG nodes is often required for Maya workflows as well as custom tools and pipeline components. Therefore, Maya provides a couple of different mechanisms for doing so, Message Attributes and Sets.
An attribute of type message is unique in that it holds no value data, instead it can be connected in a one to many relationship. These connections can be queried to determine the relationship between the nodes.
An objectSet is an important type of DG node, and it is relied on heavily in deformation and material assignments. Sets can reference DG and DAG nodes, as well as geometry components. In the case of DG nodes, they do so by creating connections between the message attribute on a DG node and the dnSetMembers[] attribute on the set, where as for DAG nodes, the connection is made between the instObjGroups[] and dagSetMembers[].
Maya implements several geometry types, including polygonal meshes, curves and surfaces. Each geometry type has an associated shape node that allows geometry data to exist in the DG and be displayed in the 3D view.
While there are some differences between these shape nodes, they all have a basic set of attributes for incoming and outgoing mesh data, as well as local component edits.
| Purpose | Mesh | Curve & Surface |
|---|---|---|
| input | inMesh | create |
| output | outMesh | local |
| world output | worldMesh[] | worldSpace[] |
| edits | pnts[] | controlPoints[] |
These attributes could be used to unlock a couple of valuable workflows. For example, geometry data held by the shape node can be updated by following these steps:
Another practical workflow utilizes the edits attributes to manipulate geometry without using a deformer. These attributes can be set via scripting as well as receive direct connections. However, there is an important difference in how edits are applied to meshes compared to curves or surfaces. In the case of meshes, the pnts are always applied as relative offsets to the mesh, regardless of whether there is an incoming connection to the inMesh attribute. Instead, controlPoints applied as absolute positions for curves and surfaces when the create attribute does not have an incoming connection, but applied as relative offsets when it does.
Maya considers all component positions to be relative to the shape’s parent transform, this space is typically referred to as Object Space. This also applies to values in pnts and controlPoints attributes. Therefore, for many workflows it is often advantageous to keep the parent transform at world origin, which keeps component positions values relative to world space.
You can use a combination of Modify->Freeze & Reset Transformations to bake the parent transformation into the component position values.
Note that when using API, in order to perform any operation on geometry components in world space, DAG path needs to be used to initialize the function object.
Deformation in Maya is done by using a subset of specialized DG nodes, which receive input geometry, change it, and output it. However, to accommodate some workflows such as operating on select components, Maya inserts additional nodes into the graph for some bookkeeping. These nodes are the groupParts, groupId, and set.
Each deformer gets a set associated with it which conceptually holds a reference to the components of the geometry that it being modified by the deformer. However, Maya actually stores component sets as part of the shape node, instead of on the set node. Maya inserts the groupParts and groupId nodes in the construction history to provide this information to the shape.
Note that by default groupParts and groupId nodes are hidden, but you can make them visible by turning on Show->Show Auxiliary Nodes in the Node Editor or Hypergraph.
The groupId node has a single job to generate a unique ID that is used to identify the set within a shape, while the groupParts node stores the component indices to be used for a given group ID. Since Maya keeps track the raw component indices directly, deformers are particularly sensitive to operations that cause topology changes.
In addition to creating a couple of auxiliary nodes and a deformer set when creating a new deformer, Maya will also duplicate the target shape and use the copy as the input to the deformer. It will then connect the output of the deformer to the target shape. By convention, the duplicate shape is called Original and is set to be an Intermediate Shape in order to hide it from various views and prevent unwanted editing.
Note that a lot of workflows in Maya, and various custom tools, expect that there will be just one intermediate shape under the transform, therefore it is a good practice to check for and delete orphaned intermediate shapes. The easiest way to do so is by using the Hypergraph (Hierarchy Mode) and turning on Options->Display->Hidden Nodes.
Finally, when any deformer is applied to a shape for the first time, a tweak deformer is also inserted into the construction history right after the Original shape. Thereafter, any changes made to the geometry points will stored on the tweak node instead of the pnts or controlPoints attributes of the shape node. This configuration helps to preserve the relative nature of the edits, especially with deformers that involve orientation such as skinCluster.
Note that Maya discovers the appropriate tweak node by looking at the incoming connection to the tweakLocation attribute on the shape node.
Almost all of the data that is going to be generated in Maya will be saved as a Maya Scene File. There are two file formats that are supported, Maya ASCII and Maya Binary and for the most part they can be used interchangeably. A scene saved in a Maya Binary format would often end up taking significantly less space on disk when compared to the same scene saved as Maya ASCII. Therefore if disk space is at a premium, Maya Binary would be a better choice. Moreover, highly networked and cloud based pipelines would also benefit from smaller file size to reduce bandwidth loads and improve upload speeds.
However, if file size is not a significant concern, Maya ASCII offers a couple of important benefts over the binary version. First, it is a human readable format which can be instrumental in debugging and scene recovery. In addition, Maya ASCII format will work well with modern revision control systems, such as Git or Mercurial, while standard text diff tools can be used to compare and merge versioned scene files.
Perhaps the most valuable asset management workflow in Maya is File Referencing. Referencing establishes a hierarchical relationship between two or more scenes and makes it possible to load the contents of a child scene into the parent scene. The key feature is that the actual data is not copied to the parent scene, but instead remains stored in the child scene file. Since the parent scene is only responsible for tracking a limited set of edits to that data, this can significantly reduce the file size of Maya scenes, especially in downstream departments such as animation and lighting.
Referencing has multiple benefits in production. Primarily, file referencing allows multiple individuals to work together on the same project in a collaborative, cross-disciplinary, and non-linear way. Assets can be worked on independently and concurrently while allowing updates to propagate through the pipeline.
When a reference is created a new Reference Node is added to the scene, and it is responsible for holding all the information about the reference as well as any associated reference edits.
You can inspect the reference node and its reference members in the Outliner by turning on the appropriate Display flags.
Typically, a references are read and loaded when the scene is opening, however you also have the option to reload a reference from disk in case an updated version is desired. Likewise, a reference can be offloaded if necessary in order to improve interactive scene performance.
Note that while any Maya scene can be referenced, it is best to use File->Export Selected or Reference->Export Selection As Reference (Outliner RMB) to create new reference scenes, this will avoid referencing redundant and unnecessary default scene objects.
Maya allows a limited set of modifications that can be applied to objects from a referenced file. The following types of edits are supported:
All these edits are stored as a set of commands (ex. setAttr, connectAttr) in the reference node and therefore remain local to the parent scene. However, Maya does provide a workflow to save reference edits to an external file so that they can be reapplied to other instances of the same reference.
Most of the difficulties that arise when using file referencing in production often have to do with the failure to reapply reference edits when changes are made to the child scene. This happens because reference edit commands are saved with the full DAG path to the referenced objects. Therefore, if the child scene changes the DAG hierarchy, it is very likely to invalidate existing reference edits in the parent scene leading to undefined behavior. Similarly, renaming nodes or attributes in the child scene can result in edits that fail to re-apply.
You can use the referenceEdit command with the -changeEditTarget flag to updated the mapping of failed edits with respect to naming changes made in the referenced scene.
When a reference is unloaded (or swapped for an alternative proxy representation), if it has any DAG hierarchy edits, Maya will create a dummy Foster Parent DAG node. This node will be used as the temporary parent for any DAG nodes that were parented into the referenced hierarchy, and it will exist in the scene until the reference is reloaded and edits are re-applied. In those cases when the parent nodes were deleted in the referenced scene, the foster parent node will remain in the parent scene, indicating that additional intervention might be necessary to resolve failed edits.
Unfortunately, if Maya fails to apply any of the reference edits during the loading process, it does not issue any errors or warnings. Therefore, it is recommended to implement a custom sanity check for failed edits to make sure that breaking changes do not sneak into production. If all the failed reference edits are deemed to be no longer necessary due to legitimate changes to the child scene, they can be removed by using the File->Clean Up Reference action.
You can delete any reference edit by using the Remove Selected Edits button in the Reference Edits dialog, however in order to delete a successfully applied edit, the reference needs to be unloaded first.
It is possible to make reference edits that will modify the construction history on geometry shape nodes, however there are a couple of inconsistencies in behavior.
As discussed in the Original Shape section, Maya will typically create a duplicate shape node to use as the source for the deformation construction history. However, if the geometry shape is referenced, Maya will instead use the referenced geometry as the original shape and create a new shape to use as the output (named with suffix Deformed). This can cause some problems propagating future changes from the refenced scene, for example if additional attributes were added to the geometry shape node in the child scene, they would not be present in the Deformed duplicate and thus might not be sent downstream to lighting.
In contrast, other workflows that modify the construction history, for example, deleting a component, will instead use the duplicate shape node as the original source. This can be equally as problematic because the geometry data stored in the duplicate shape node, that is now the source for the construction history, will not be updated by changes made to the child scene. For these reasons, if construction history edits are expected, it is recommended that the geometry shape nodes in child scene have existing construction history.
Working with referenced files, it is likely that you would encounter scene objects that have the same name and even the same DAG path. Therefore, in order to avoid name conflicts, referenced objects are typically added to a Namespace. A namespace is an additional qualifier that is prefixed to the object’s name, separated by the color (‘:’) character. In effect, the it becomes part of the object name, therefore it is also possible to have a DAG path with nodes that are in different namespaces. Multiple namespaces can be combined together, although for practical use it is recommended to avoid arbitrary deep namespace hierarchies.
The file reference has the ability to point to a single file on disk. Of course, the file can be updated by another artist at anytime. This creates several issues, first there is no way to know that a referenced file has been updated during the Maya session unless you reload the scene or manually reload the reference. Second, there is no way to opt out of picking up the latest changes, even if they might cause breaking changes in the parent scene. For these reasons, to get the most out of file referencing a versioning scheme needs to be employed. Unfortunately, at this time, Maya does not provide any comprehensive tools for versioning of scene files, with the only exception being the File->Increment And Save action.
Note that the Increment and Save action is implemented in MEL and it’s implementation can be used as reference for a more comprehensive custom solution:
scripts/startup/incrementAndSaveScene.mel.
Incremental save is an important tool for artists to begin versioning the work, the missing component for file referencing requires the ability to semantically identify which incremental save is the latest or current version. The basic implementation of this can be easily accomplished by using a symbolic link (symlink) mechanism of the file system.
Alembic is an open source file format primarily designed for interchange of static and animated geometric data. The idea behind the use of alembic is that it can take complex, animated scenes and convert them into application independent set of baked geometric results. It is strictly designed for scene archival and retrieval of data, and not for any kind of dynamic scene manipulation. Alembic file format supports the following geometric data types: Points, Curves, PolyMesh, SubD, FaceSet (part of SubD or PolyMesh), NuPatch, Camera, and Light, which are defined in the AbcGeom library.
At the core of an abc Alembic file is an Archive which holds a hierarchy of Objects (very much like the DAG). Objects optionaly can have Properties. The property values are written and read as Samples at specific times. However, the Alembic does not provide any means of interpolating the sample values itself, if required any interpolation needs to be performed by the plugin implementation. The properties for reach of the supported types is defined in the Schema.
Maya implements support for Alembic format through a couple of plugins, AbcImport and AbcExport (plugins might not be loaded by default). In addition to using Alembic for interchange geometry data with other application, it can also be used within a Maya production pipeline. This is possible because Maya converts Alembic data to native geometry data and appropriate shape nodes, which makes it possible to use the standard editing tools with Alembic data. Specifically, since Alembic bakes complex setups down to pure geometric representation, it is well suited to be used as the product output from from animation.
Note that unlike regular Maya Export Selection action, the Alembic Export Selection to Alembic action will not export the parent DAG objects in the hierarchy.
The Alembic import plugin also implements an Alembic node, which is responsible for reading the data from the specified file on disk, one sample at a time. The output of the Alembic node is connected to a new shape node that is also created by the import command. The AbcExport plugin does not save the material and shading network from the Maya scene, therefore when opening or importing an Alembic file, it will be assigned the default material.
Of course, it is possible to assign the material infomraiton to the imported Alembic geometry, however it takes some additional planning to make sure it remains propery attached. Maya provides an option to merge incoming Alembic data with existing geometry in the scene. Specifically, if Maya detects identical DAG hierarchy it will connect the Alembic node output to it, instead of creating new objects. Therefore, any material information assigned to those objects will be preserved.
It is a good idea to do a single frame Alembic cache publish from an rigging or animation scene (even before the rig is finalized). This will provide the look development artist with an Alembic structure they can import and begin to apply their material assignments to.
Note that if you re-import the cache with the Merge option, if there is an existing Alembic node attached to an object, it will not be deleted, only disconnected, requiring additional cleanup.
There are some shortcomings with importing Alembic caches. Even though the Alembic node holds a path to the Alembic source file (similar to a reference node), it is not possible to change it in the scene. Furthermore, because the import process generates connections from the Alembic node to DAG objects, if the source Alembic file has been updated in a way that requires new connections to be made, this will not be done automatically. An alternative and often preferred solution is to use file referencing with Alembic caches.
Another implementation of Alembic in Maya is the gpuCache plugin, and while it can also load export and import Alembic files it is intended and optimized for a very specific use case. Unlike AbcImport, the GPU cache does not create Maya shape nodes for display of geometry, instead it consolidates the read and display functionality into a single gpuCache shape node optimized for display in Viewport 2.0. Also, unlike AbcExport, the GPU cache plugin can export Phong* and Lambert material information that will be used during viewport display. However, due to performance considerations, no edits can be applied to the cache geometry or transforms. These features make GPU caches ideal for large, heavy, and static data such as set decorations.