Custom Maya Asset Pipeline & Deployment
Over the past few years, I have been developing a very portable asset pipeline deeply integrated into Maya. This pipeline has evolved and grown from its initial inception during my time at Blackrock Games from mid 2010. I used it as the foundation for the internal tools and pipelines of both Split Second 2 at Blackrock and Sesame Street Kinect at Microsoft Studio Soho, and it is currently being developed further at Studio Gobo. Each project I work on yields new problems that need solving and typically new tools that can be re-incorporated back into the general framework.
All UI elements were originally built using PyQT but I recently switched them over to PySide.
This is the main Tool shelf in Maya. From here the predominant content tools can be accessed.
It seems trivial at the surface level, but the entire pipeline is built around, and exists to service, four principle asset types. These are custom nodes identifiable within Maya's scene graph by type, developed as a Python plugin using both Python and the OpenMaya Python SDK. These can best be thought of as "containers" for specific data. The advantage of this system is that a lot of extraneous content can exist in any given scene file, but the asset pipeline only cares about the contents of these containers. A "one to many" paradigm is fully supported, meaning many assets of mixed types can be generated from a single Maya scene file.
These container nodes are accessed from the main pipeline shelf. They are defined by their types, "Static Mesh", "Skinned Mesh", "Animated Mesh" and "Puppet". These are fairly standard descriptions widely used in the industry and are pretty much self explanatory.
As they are implemented as custom node types, they also have their own icons used throughout Maya's numerous interfaces including the Hypergraph and Outliner shown below
In order to simplify the process of exporting the contents of these asset containers, I developed an Export Manager utility. This tool parses through Maya's scene graph and determines valid items for exporting. As each exportable asset can be identified by its type, its easy to filter out non-exportable data. Behind the scenes the Export Manager instantiates and populates corresponding classes for each exportable asset type - this also simplifies the final step of actually exporting the data associated with given assets as most of the heavy lifting has been done. It then performs basic validation and gives the user concise feedback presented in a simple UI as shown below.
The act of exporting assets is wrapped up in a right-click contextual menu. Other asset specific attributes can also be set from this menu, such as de-coupling animation puppets from one another to export animation in world space as opposed to attached parent space (useful for weapons that need to be animated in place relative to a hand but exported with no root animation to be re-parented in engine). In the current state, my pipeline is set up to leverage FBX as the final output format. However, due to the abstraction of the asset / scene management layer its a very easy task to implement an alternative output format which I originally did for Split Second 2 as it made use of an internally developed proprietary format for models and Havok Animation for animations. Assets can also be flagged to be a "Reference" which basically made them non-exportable.
Puppet Studio was developed as an interface for working with rigged character assets (Puppets). It is basically a simple library tool used to view and add Puppets to a given scene that handles all the management of this in a very non-intrusive manner. Puppet Studio integrates directly with the Export Manager, so Puppets are handled in a way that makes them immediately valid for export.
Puppets can also make use of Poses, which are created, accessed and applied using a simple Pose Library interface - eventually this will be more tightly integrated into Puppet Studio consolidating the two into one interface.
