[Maya] Meta node data structure design question

I’m starting to write some meta node code at work. Anyone else here use meta node networks in Maya?

I’m trying to determine what types of methods to put in the meta node class. It will contain methods for traversing and editing the actual meta node network, but should it include methods for operating on that network (like pose mirroring, exporting, validation, etc) or should that functionality all live separated from the meta node classes?

This boils down to a more general python structure question. Is the meta node only aware of other meta nodes in its network and how to query/remove/add them? It would then be up to separate functions to actually use those networks for any operations.
Should they be separate functions? Or should I be subclassing the core class and adding those additional methods to the subclasses? This seems similar to what Mark has done with Red9, but I’m curious if all additional functionality gets added onto the subclasses or if a lot of the operations sit as functions that take a metanode as an argument?

This question is a bit rambling/train-of-thought, but I’m chasing ideas around my head so that’s how it’s comin’ out!

Thanks

my $.02:

As a general principle you have to balance two different needs:

  1. How easily can you traverse a node network and find what you want in the abstract, without doing too much type casting or name checking?
  2. How easily can you get at the methods and properties of a given node?

These tend to cut against each other because you want to do traversal tasks in a fairly abstract way – which would imply, for example, that you have a generalized knowledge up ‘upstream’ and ‘downstream’ instead of specifics about which kind of plug to follow from which kind of node. On the other hand, some nodes offer abilities or information which others lack and you’ll need to have access to that without too much boilerplate reflection code.

One trick which I’ve found useful is to keep the nodes pretty simple and put all the smarts into different types of traversal classes which can have a similar interface but which have all the smarts about how to get around the network: you can pick a generic traverser which only follows connections up to a root, or a complex one which knows how to find and all the parts of an IK system. I like this better than jamming all the smarts into the node classes because it is easier to subclass actions than data: if you push too much into the node base class, it ends up becoming very bloated or hopelessly generic.

Operations (like mirroring or whatever) would be built up using appopriate traversers to collect nodes and then separate operations class that just work on known subnets but don’t have to worry about finding things.

If you haven’t already, check out Red9 Meta Data; https://apps.exchange.autodesk.com/MAYA/en/Detail/Index?id=exchange.red9.studiopack.autodesk.com%3Ared9studiotools%3Aen