Rig encapsulation using Maya’s assets

Posted by on Sep 3, 2011 in Blog | 1 comment

I’ve been playing around lately with Maya’s assets, and I think they’re pretty cool. Following the example provided in Maya’s documents, I wasn’t too happy with the result. I had to play around a bit before figuring out how I want to use them. Here are my thoughts on some points after playing around.

There are two levels of encapsulation when working with assets: black boxing and attribute locking. Black boxing basically just hidesĀ  any non-published nodes from the Outliner so the animators can’t go getting into trouble with the guts of the rig. The guts of the rig is the proverbial “big red button”: leave a note saying “DO NOT TOUCH”, and it only increases temptation. Attribute locking goes through the entire asset and locks any attributes that have not been published.

There are a few problems with both of these encapsulation types. The biggest problems I have belong to the attribute locking. First off, any attributes you do not publish for the animator to use get locked and hidden. This means that for any attribute you want the animator to use, you actually need to publish. The problem with this is that every published attribute gets added to the asset node. This is a very useful feature, as you can publish your geometry visibility and controls visibility toggles, for example, and have them appear on the master node of the encapsulated rig, but when you have a hundred or so controls in the rig and several attributes per control that need to be published… well, yeah, it becomes cluttered and messy. All of a sudden a great feature has become completely useless.

Second problem with attribute locking is, locking certain attributes on certain nodes can actually break your rig. I wrote a MEL script on a previous production that was to go through all hidden nodes and lock all attributes on those nodes. I found that after doing this it would actually kill my IK handles and/or constraints (I didn’t bother trying to troubleshoot it much since it was obviously having major issues, so not sure exactly which nodes and attributes were having the problem). I thought Autodesk would have been taken into consideration with Maya’s assets, but apparently not. I ran into the same issue where parts of my rig just straight up broke after locking attributes.

The problem with black boxing, luckily, is a very small problem which can be easily fixed. The problem is that, although unpublished nodes are hidden from the Outliner, the animators can still select them when doing a select hierarchy command, so they’re not actually fully “black-boxed”. I fixed this by setting up two script jobs. The first script job is for when a scene is loaded. When the scene is loaded, it collects all asset container nodes, cycles through them, and appends the names of all unpublished nodes in each asset container to a shared array. The other script job is for whenever a new selection is made. When a new selection is made, the script job just quickly deselects the list of unpublished nodes we collected earlier.

One other issue I’ve run into is that when you add nodes to an asset, it essentially makes it impossible to work with it in the hypergraph. All of the nodes are stored in a container, and there is no isolating the nodes. If you select one node and tell it to graph just one level deep for inputs and outputs, it ignores you. You are looking at the entire node graph at all times, whether you like it or not. For this reason, I’ve actually made this entire process automated, and it is performed when the rig gets published. The script assumes you are organizing your rig scene a certain way, and then packages the rig accordingly. To explain further, when I start creating a rig, I have a hierarchy of group nodes set up that looks similar to the following:

  • master
    • controls
    • geo
      • highRes
      • lowRes
    • rig
      • joints
      • deformers
      • misc

The packaging script knows to expect these nodes. It collects all nodes under the master node and adds them into an asset. Then, it collects all nodes under controls prefixed with “CNT_” and publishes them so they will still appear in the Outliner when blackboxed. Once blackboxed, the “CNT_” prefix is kind of redundant since every single node you see will have “CNT_” in front. I like to remove the prefix during packaging so that the animator only sees “LeftArm” or “Neck”, for example. It makes the rig a lot more readable in the Outliner.

Also, the packager expects that all attributes found on the master node found above should be published to the asset. Although I am not using the Lock Attribute feature, publishing attributes still makes it so that those attributes appear on the asset node. There is a setting in the channel box that allows you to have these attributes then be visible whenever you have selected any object belonging to the asset. This can be nice as long as you keep the number of attributes low and they are something that affects the entire rig.

Oh, I almost forgot one other cool thing about using assets. It makes walking the hierarchy a sinch for animators. The up and down arrows do not take you to the shape node, or the group node you have your control parented to. It takes you directly to the next published node and skips everything else in between.

One Comment

  1. Just thought I would post in here that I haven’t had any more time to explore any of this. Would like to get back to it one day and play with it a bit more; see if there are any show-stopping problems I might run in to. This isn’t a top priority thing, but might just add a nice layer of protection to rigs while they are out in the wild. Curious to hear if anybody else out there has explored Maya’s assets at all. If anybody has, let me know what your experience was by leaving a comment.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>