I've been working on a Maya auto-rigging module (so original, I know). Like any good auto-rigger, it creates its fair share of dependency nodes. Personally, I always try to attain my results with node networks. Maya's other options are nice for mock-ups, but are problematic for finished rigs. Driven keys (SDKs) are good for making simple object relationships work, but I see them as really a tool for animators rather than riggers. My first reason is that Maya considers SDKs to be animation data - and as such, they can be destroyed (even accidentally) pretty easily. Secondly, anything they can do, nodes can do just as easily. And lastly, I find SDKs more opaque for fresh eyes trying to understand how a rig is going to work - that is, it hides more of what it's doing from the user.
The other alternative is Expressions, which, again, can be useful for mock-ups. They can be powerful and aren't (usually) hard to read, but they are notoriously slow and have a syntax which is unique but just similar enough to MEL to be obnoxious.
Uhh... this post is more than just a rant, I promise. The point is, my finished tools tend to make lots of nodes - and the one downside of node networks is they can clutter your scene (organizationally, if not computationally). You can tell how much of a neat-freak a rigger is by un-checking "DAG Objects Only" in the Outliner for one one of their scenes. Me? I like to keep things organized. I put my DG nodes in asset containers so anyone can immediately know what purpose they serve, and so I can safely and confidently remove any unknown, un-bundled nodes. Now, in an auto-rigging script, the easy way to do this would be to make an asset and set it as the "current" container, which makes it automatically capture newly created nodes. The trouble is, this captures all nodes, DAG and otherwise - and I don't want it messing up my pretty control hierarchies. I make containers for the clutter, not for the stuff animators need to use.
Note the scrollbar - this goes on for pages.
If we want to contain only the intermediate nodes, we'll have to create a solution ourselves. As is likely evident to any Maya API-familiar readers, the MDGMessage class can help. We'll create a callback for every new node created, inspect if it's DAG, and if not, put it in the asset. This old post on macaroniKazoo walks through a solution which, essentially, decorates the arbitrary function whose nodes you want to capture. It calls addNodeAddedCallback, then the arbitrary function arg (whose nodes you want to capture), then removeNodeAddedCallback. It returns the new nodes and the original function's return value. And it works pretty well! However, what happens if the user function errors out? We'll be left with the nodeAddedCallback still registered and no knowledge of its ID to remove it. Sure we can work through this, but why should we have to?
It reminds me of the potential for mischief allowed by not closing file objects after finishing with them. I guess constantly having to address situations like this with try/finally blocks for safe set-up and tear-down finally wore down the Python developers, so they introduced the with statement to streamline things. The only thing we have to do is define our set-up and tear-down tasks as a context manager, which is any object with the methods "__enter__" and "__exit__".
If we tinker with the original idea a bit, we can end up with this:
from pymel.api import MDGMessage, MMessage
import pymel.core as pmc
class NodeOrganizer(object):
"""Context manager to organize newly created nodes."""
def __enter__(self):
self.cbid = MDGMessage.addNodeAddedCallback(addIntermediateNode)
def __exit__(self, *args):
MMessage.removeCallback(self.cbid)
def addIntermediateNode(node, data):
"""Callback function, add new node to myContainer.
Callback passes two args, node as MObject and data (often None)."""
node = pmc.PyNode(node)
if isinstance(node, pmc.nt.DagNode):
return
pmc.container("myContainer", e=True, addNode=node)
# run autorigging function and auto-add new utility nodes to asset
with NodeOrganizer():
riggingFunction()Immediately we can see a couple differences. First, structuring the creation and removal of the callback as a context manager ensures that the callback will always be removed - one less potential hassle. To me, this seems to be the exact kind of thing that context managers are for. Second, we don't pass our arbitrary function as an argument - we just call it in the NodeOrganizer's context. I think this creates a nice division of labor which makes it more readable.
Of course, at some point we may want to do more with new nodes than just add them to some container. Towards this end, perhaps we could restore the function parameter to the context manager - but in this case, we could pass in the callback function rather than the node-creating function. Doing so will add another layer of abstraction to the class, and help us keep our code DRY. In the decorator implementation, this would still technically be possible, but two function parameters (and args for one of them) would make it more difficult to understand at a glance. Here's what that would look like in our example:
from pymel.api import MDGMessage, MMessage
import pymel.core as pmc
class NodeOrganizer(object):
"""Context manager to organize newly created nodes.
Abstractable - argument function is attached to callback, and must accept
exactly 2 args from callback: MObject (the new node), and data"""
def __init__(self, func):
self.func = func
self.cbid = None
def __enter__(self):
self.cbid = MDGMessage.addNodeAddedCallback(self.func)
def __exit__(self, *args):
MMessage.removeCallback(self.cbid)
def addIntermediateNode(container, node, data):
"""Callback function, add new node to given asset.
Callback passes two args, node as MObject and data (often None)."""
node = pmc.PyNode(node)
if isinstance(node, pmc.nt.DagNode):
return
pmc.container(container, e=True, addNode=node)
# run autorigging function and auto-add new utility nodes to asset
container = pmc.PyNode("myContainer")
with NodeOrganizer(lambda *args: addIntermediateNode(container, *args)):
riggingFunction()Notice that I also added a parameter to the callback function to let it use any container object, since we were trying to make things more abstractable. If we wanted to get really DRY, we could even make the add callback function a second parameter of the context manager, so as not to limit ourselves to just the nodeAdded message. However, this places a significant onus on the user to be familiar with various callbacks and what args they try to pass (though the context manager should still protect against phantom callback buildup). All in all, that might be too abstracted to be practical - but the idea is there for the using. Given the specific application to auto-rigging scripts, I think the nodeAddedCallback calling our argument function is the abstraction/concretion sweet spot.
Anyway, I hope this helps someone out! Registering/removing callbacks was the third application for a custom context manager that I've found during Maya tool development, the other two being managing the undo queue and the current Maya tool context. I'm sure there are many more uses. Let me know your favorites in the comments.