But thats not the point.  The point is I wanted to try and do it myself as an exercise. Its kinda tricky writing a nice serialization format and it was actually a fun little project.

Anyway, so what does it do?  Well, I wanted a text based serialization format that was easy to read and on the odd occasion hand edit.  You could write them by hand too if you’re feeling masochistic, but I strongly discourage it.  Having an easily readable, text based serialization format is terribly helpful for the occasions that you just want to crack the data open in an editor and see what the hell is going on.

Of course, you want to be able to write out interesting data too.  Which is obviously why pickle is incredibly appealing.  But pickle files are basically impossible for us mere mortals to read.  Plus they can also be abused by bad programmers (bad meaning incompetent or malicious).  I had a case recently where one of our tools was being hellishly slow.  So I spent a heap of time in a profiler trying to figure out why.  Turned out this particular tool, which was storing out data in pickle files, was pickling a database abstraction object.  The mere act of unpickling the file would cause a bunch of database activity.  In this particular case the tool was unpickling lots of these files which ended up taking a long time.  It took awhile to even bother looking at file loading as the culprit because the files themselves were only a few hundred bytes.

This is an easy mistake to make inadvertently in a language like python.

Pickle is amazingly cool.  Its also a VERY powerful tool to put in the hands of noobs and can sometimes cause headaches.

Anyway enough talking, lets look at some codez!

import os
from maya import cmds
import sobject

objToSerialize = sobject.SObject()
objToSerialize.sceneName = cmds.file( q=True, sn=True )
objToSerialize.currentSelection = cmds.ls( sl=True )
objToSerialize.someRandomDict = { 'data': os.getenv( 'USER' ), 'cwd': os.getcwd() }
objToSerialize.subObj = subObj = sobject.SObject()
subObj.interestingNumbers = range(3)
subObj.cyclicReference = objToSerialize

Kinda pointless data, but basically the objToSerialize object will be able to serialize itself to disk in a nice human readable way. The above code serialized to disk looks like this:

42035216:
	sceneName(str):c:/somePath/someFile.ma
	currentSelection(list):
		(str):pSphere1
		(str):pCube1
	someRandomDict(dict):
		(str)data(NoneType):None
		(str)cwd(str):c:\Users\macaronikazoo\Documents\maya\scripts
	subObj(*):42035376:
		interestingNumbers(list):
			(int):0
			(int):1
			(int):2
		cyclicReference(*):42035216

Thats fairly readable, right? Hardly a Dan Brown novel, but certainly easy enough to digest should you need to go poking around. And obviously if you need to get this information back into python, its as simple as passing either the string data to the Unserialize class method, or passing a filepath to the Load classmethod. Like so:

objToSerialize.write( '~/sobject_test_file.txt' )
unserializedFromFile = sobject.Load( '~/sobject_test_file.txt' )  #unserialize from file
assert objToSerialize == unserializedFromFile

Anyway – if you’re interested in taking a look at the code, feel free to! Its right here.

So whats new I hear you ask?  Well…

• Complete animation library re-write: It finally does what I’ve always wanted it to do – saving out both local space animation data AND world space animation data.  Which isn’t useful all the time, but sometimes it can be a real lifesaver.  Plus because the tool works based on selection, you can load part of the clip in worldspace and the rest in local space.  The tool still works and looks exactly the same, but under the hood things are much nicer.
• XferAnim is also a complete re-write to slot in better with the new anim clip.  They both share a lot more code now.
• Easier install: There are no longer dagMenuProc scripts that you have to rename.  The toolbox should setup the dagMenuProc automatically when it loads.  There is even an option that will attempt to setup the toolbox to auto-load on maya start (although I haven’t tested this on very many setups yet so its hard to know how robust this feature is).

So basically now all you should need to do is unzip the toolbox to your maya/scripts folder, startup maya and run the zooToolbox MEL command.

Enjoy!

Of course to look at failure we need to understand the initial goals first. Skeleton Builder (SB) is my second attempt at writing a rigging framework. Not an auto-rigger, although it is an auto-rigger.  But the part of the code I’m most interested in analyzing is the framework part. I’ll go into the difference in a bit. With SB I wanted to solve a bunch of problems.

1. Skeleton construction and joint alignment. I wanted to make it easy to construct arbitrary skeletons without burdening the user or the riggerwith joint alignment problems. I wanted consequent rigging code to be able to make guaranteed assumptions about joint alignment.
2. I wanted every skeleton part and every rig part to be introspectible from code. I wanted this so that rig parts could ask questions of other existing parts. This would allow them to be easily re-purposed and extended. It would also allow richer animation tools to be built upon them.
3. I wanted to be able to write a bunch of common code for a “limb” and have it re-used by biped arms, biped legs, quadruped legs, arachnid legs etc…  If not done via inheritance, then at least provide the same interfaces.
4. I wanted very little overhead to actually use the framework. I wanted to make it really easy to port existing rigging code over to use the SB framework.
5. And lastly I wanted to write a procedural UI to the framework so that non-technical users could use it and so rig coders didn’t need to write UI.

So those were the major goals.

The first was was a mixed success. While the tool makes it really easy to build skeletons without having to worry about alignment for most things, its not immediately obvious to users that this is the case. Ideally the alignment would change in real-time as they’re making skeletal adjustments. Also joints like wrist joints still needed to be oriented manually. This wasn’t terribly obvious to users either, which is fair enough. As an end user when you see everything being automated, you don’t really stop to think whether there is anything you might need to pay attention to. So the tool should have made more of an effort to point out user intervention is required in this case.

The second point was also a mixed success.  SB has a bunch of helper functions in it to make coding space switching super easy.  Setting it up was generally a single line of code per control, or if you weren’t picky you could even use the  ”auto space switching”. Space switching is amazingly useful and in fact, usually when I forget to put it on a control, I eventually hear back from an animator – “hey, can I get space switching on control X please?”.

Anyway the problem with space switching is that it is a confounding factor when you need to sort rig controls hierarchically. Space switching provides a way to effectively change the hierarchy. So without some way of taking this into account when you need to sort controls hierarchically, this can be a problem for a tool writer. So that in my opinion is a failure and I’m not even quite sure what the best solution is.  I mean its easy enough to write a function that takes space switching into account when doing a hierarchical sort, but how does a tool writer KNOW that they need to do this?

So lets go back to the bit about rigging frameworks vs auto-riggers.  Well the difference is basically architecture vs construction.  The framework is the environment the rigging code is written within.  When I started writing SB, I focused only on the framework side.  I had a pretty good idea what sort of functionality would be required, so I wrote that first.  Once I was happy with that, I took it out for a test drive by trying to write some actual rigging code using it.  This in turn pointed out some missing features in the framework which in turn caused me to re-write the actual rigging code etc…  This iteration cycle went on for a little bit and eventually out came the current incarnation of SB.

Basically a good auto-rigger should be built upon a good rigging framework.

Thats my brief analysis on the shortcomings of SB.  In general, like I said at the top, I think it has been very successful.  Its made me personally enormously more productive than I would been and it has been an amazingly enabling force for users of the tool as well.  But like I said, analyzing the failures is usually more instructive than analyzing the successes.

Anyway I’ll post more about it when I actually manage to ship it.  For now though, stay tuned.

For example, is there a way to query the FK controls from a given IK control and vice-versa? What about pole vector controls? Is there a way to ask which controls have space switching? If so can you query what the spaces are? What about which controls are affected by a given space switch? Given a joint can you get a list of the rig controls that drive it? You get the idea.

Animation tools are basically a layer that build on top of the rig layer. If the rig layer isn’t rock solid, then animation tools will be unstable or feature restricted or both.

Having some sort of programmatic interface to encapsulate the implementation details of your rig features is incredibly important if you want to be able to write useful and robust animation tools. Without this sort of high level rig API you’ll most likely make it difficult or impossible to write the sort of tools that will enable your animators to be more productive.

So if you’re writing a rigging system, try taking a break from it and building some animation tools. Exercise that rigging API you’ve been spending so much time on. Better yet, use all the animation tools you write as part of your unit testing to validate changes made to your rigging API. Remember, as a rigger your customers are both your animators and anyone who might write animation tools.

Now there are a bunch of different ways you can do this… This is just one way that seems (to me) like a good combination of rigor and ease of coding.

In Skeleton Builder, each rig part is encapsulated in a class that derives from RigPart.  The next step is to create an interface class which defines two methods – switchToFk and switchToIk.  Our rig part class will inherit from both RigPart and this interface class and will implement these two methods.  Our code ends up looking something like this:

import typeFactories
import baseRigPrimitive
class IkFkSwitchable(object):
  __metaclass__ = typeFactories.interfaceTypeFactory( baseRigPrimitive.RigPart.__metaclass__ )
  def switchToFk( self ):
    '''this method should implement the logic to switch to FK mode'''
    pass
  def switchToIk( self ):
    '''this method should implement the logic to switch to IK mode'''
    pass

class Leg(baseRigPrimitive.RigPart, IkFkSwitchable):
  #the code to implement this rig part goes here
  ...
  def switchToFk( self ):
    #implementation of this method goes below...
    ...
  def switchToIk( self ):
    #implementation of this method goes below...
    ...

As you can see here, the Leg rig part class implements the logic for switchToFk and switchToIk (otherwise an exception gets thrown). Now we can write a simple UI with a “switch to Fk” button and a “switch to Ik” button, something like this:

import rigPrimitives
import maya.cmds as cmd
from baseMelUI import *

def getSelectedSwitchableParts():
  '''
  returns a list of all RigPart instances that have at least one of their members
  selected
  '''
  selectedSwitchableParts = []
  selectedRigParts = rigPrimitives.getPartsFromObjects( cmd.ls( sl=True ) )
  for rigPart in selectedRigParts:
    if isinstance( rigPart, IkFkSwitchable ):
      selectedSwitchableParts.append( rigPart )

  return selectedSwitchableParts

class UserToolLayout(MelHLayout):
  def __init__( self, parent ):
    MelHLayout.__init__( self, parent )
    self.UI_fkButton = MelButton( self, l="switch to FK", c=self.on_pressFk )
    self.UI_ikButton = MelButton( self, l="switch to IK", c=self.on_pressIk )

    #this useful method sets up a scriptjob parented to the uI that triggers the given
    #method when the scene selection changes.  So this will update the UI when the user
    #changes the selection
    self.setSelectionChangeCB( self.on_selectionChange )
    self.on_selectionChange()  #call this to init the UI

    #make sure to call this so the form layout gets setup properly
    self.layout()

  ### EVENT HANDLERS ###
  def on_selectionChange( self, *a ):
    #need to explicitly cast here because of a bug in setEnabled
    selectedSwitchableParts = bool( getSelectedSwitchableParts() )
    self.UI_fkButton.setEnabled( selectedSwitchableParts )
    self.UI_ikButton.setEnabled( selectedSwitchableParts )
  def on_pressFk( self, *a ):
    for rigPart in getSelectedSwitchableParts():
      rigPart.switchToFk()
  def on_pressIk( self, *a ):
    for rigPart in getSelectedSwitchableParts():
      rigPart.switchToIk()

class UserToolWindow(BaseMelWindow):
  WINDOW_NAME = "ikFkSwitcherTool"
  WINDOW_TITLE = "Ik Fk switcher tool"
  DEFAULT_SIZE = 300, 45
  DEFAULT_MENU = None

  def __init__( self ):
    UserToolLayout( self )
    self.show()

UserToolWindow()

So this super simple little tool will update itself on selection change. It will let the user know whether the selected rig part can be switched from Fk to Ik or vice-versa.

Obviously you could make this a hell of a lot smarter. For example, you could inspect the rig parts, see which interfaces they implement and display the appropriate UI. You could also do things like have the IkFkSwitchable interface class define a getIkFkMode() method which would return whether the rig part is in Fk or Ik mode. This way you could only enable the appropriate button to make it even more obvious to the user the range of available actions.

Anyway hopefully you get the idea.

Anyhoo, g+ seems like its solved all of these problems in a way that makes complete sense. And its google. I manage all my photos with picasa because its just bloody easy. And I LOVE gReader. So anyway, hopefully it’ll be awesome. If you’re not using it, try it out. Look for macaronikazoo!

Writing a tool to do seamless Ik/Fk switching on an arbitrary rig is basically impossible.  After all, your particular limb setup might be a simple biped leg, a 5 jointed spider type leg, or a quadruped leg or any other crazy scenario.  Writing a single function to deal with all these possibilities, especially when you factor in the different ways these rigs could be implemented is basically impossible.

But writing the logic to do the switch for any of them in isolation is generally dead easy.  This is the sort of problem that object oriented programming was invented to solve.  In Skeleton Builder the way I solve these problems is like this.

In Skeleton Builder you write rig primitives. Each rig primitive is written to rig a particular sub-section of a skeleton and the code to do so is implemented in its own class.  So using the above examples I would have 3 classes: BipedLegRig, SpiderLegRig and QuadrupedLegRig.  Now on each one of these classes, lets define a switchToIk() method and a switchToFk() method.  So the switching logic for each rig type can be implemented independently on each of these classes.

Your code will look something like this:

import rigPrimitives

class SpiderLegRig(rigPrimitives.RigPart):
  #this class variable defines the alias' for the controls. controls are accessed using these alias'
  CONTROL_NAMES = 'legControl', 'fkThigh', 'fkKnee', 'fkAnkle'

  def _build( self, skeletonPart, **kw ):
    #the code to build the actual rig goes here
    ...

    #this is the list of nodes that will get connected to the alias' defined
    #in the CONTROL_NAMES class variable
    controls = ikControl, fk0, fk1, fk2
    namedNodes = ()

    return controls, namedNodes
  def switchToIk( self ):

    #this code grabs the actual control nodes based on their alias'
    legControl = self.getControl( 'legControl' )
    fkThigh = self.getControl( 'fkThigh' )
    fkKnee = self.getControl( 'fkKnee' )
    fkAnkle = self.getControl( 'fkAnkle' )

    #logic to switch from Fk to Ik goes below
    ...
  def switchToFk( self ):
    #logic to switch from Ik to Fk goes below
    ...

Then calling this switch method is as simple as doing something like this:

from maya import cmds

selectedControls = cmds.ls( sl=True )
if selectedControls:
  rigPart = rigPrimitives.RigPart.InitFromItem( selectedControls[0] )
  rigPart.switchToFk()

And voila. So now you can write a single UI that lets users switch between Ik and Fk for ANY part of the rig simply by running the above code.

I’ll write up another post with another example of a useful runtime tool that I’ve written that would be very difficult to do without a nice object oriented rigging framework to leverage.

So to make the zip file in the link above I ran this command:

pydeps /package pydeps.cmd

And that was it.  Simple eh?  Packaging isn’t terribly useful, but I figured I’ll most likely use this tool to generate future zooToolBox distributions.  I should be able to maintain a list of tools I want to include and pipe them into this command.  And it seemed like a useful thing for anyone who wants to distribute a neat tool without having to manually figure out what they need to include.

You may be wondering about the .cmd extension in the example above.  Well take a look at the zip file.  Basically .cmd files in windows are similar to shell scripts in *nix.  The tool will peek into a .cmd file to see if its a python script and if so, will include them in the dependency database.

So what else can you do with it?  The main features are the /i and the /d flags.  The /i flag will report all import dependencies for the given scripts.  By default it will report only immediate import dependencies, but you can pass it an depth integer as well.  For example if you wanted to know every single import dependency for a script (ie what the imported scripts import etc), you’d simply run this command:

pydeps /i 0 someScript.py

The /d flag will report scripts that are dependent on the ones you specify.  So just say you find some code you want to re-factor.  You can run this command:

pydeps /d 1 someScript.py

This command will report deep dependents for someScript.py.  By this I mean it will report every script that may possibly be using some part of someScript.py.  So for example, just say you import someScript into scriptA and then import scriptA into scriptB.  ScriptB will have access to code in someScript via its scriptA import right?  So now the pyDeps tool will report scriptA as an immediate dependent and scriptB as a deep dependent when run on someScript.

The other flag worth pointing out is the /tree flag.  This will print out a dependency tree for the given scripts.  This can be an interesting exercise – try running it on some of your tools.  I expect you’ll see some cross dependencies that you weren’t expecting.  It’d be kinda neat to do some big fat visualization graph of this…  I did think about this – in fact I figured if I bothered doing it, I’d just use maya’s hypergraph.  Build some nodes to reflect the scripts and connect em up.  If anyone ends up doing this – let me know!

Anyway, there are a few other flags – just run the tool without args to see the available flags.  Enjoy!

Anyway I wanted to get a little feedback from folks.  Is anyone still using zooCST?

I also might split the project into two – one with old horrible MEL only tools and the other with the shiny new python tools.  The MEL tools aren’t changing anyway so its not like continually including them in releases is helpful.

Thoughts anyone?  Feel free to leave a comment or shoot me email.

So do what exactly? Well, the idea is to run some function, and be able to capture all the nodes created while that function executes. I’ll talk a bit about my motivations for this at the end of the post – for now, lets dig into the code.

Maya provides quite a few event based callbacks that you can hook up using the C++ API. This hasn’t been easy to do before python came along without writing C++ code. This particular problem you could mostly solve without this API access, but not any way that would be performant.

from maya.OpenMaya import MObjectHandle, MDGMessage, MMessage
import apiExtensions  #this module makes the maya api bindings a little easier to work with

def getNodesCreatedBy( function, *args, **kwargs ):
        '''
        returns a 2-tuple containing all the nodes created by the passed function, and
        the return value of said function
        '''

        #construct the node created callback
        newNodeHandles = []
        def newNodeCB( newNode, data ):
                newNodeHandles.append( MObjectHandle( newNode ) )

        def remNodeCB( remNode, data ):
                remNodeHandle = MObjectHandle( remNode )
                if remNodeHandle in newNodeHandles:
                        newNodeHandles.remove( remNodeHandle )

        newNodeCBMsgId = MDGMessage.addNodeAddedCallback( newNodeCB )
        remNodeCBMsgId = MDGMessage.addNodeRemovedCallback( remNodeCB )

        ret = function( *args, **kwargs )
        MMessage.removeCallback( newNodeCBMsgId )
        MMessage.removeCallback( remNodeCBMsgId )

        #NOTE: the newNodes is a list of MObjects.  If you want node names do something like this:
        #newNodes = [ str( h.object() ) for h in newNodeHandles ]
        #this solution relies on using the apiExtensions module imported above
        newNodes = [ h.object() for h in newNodeHandles ]

        return newNodes, ret

So thats the code that does the magic. Its pretty simple, even if a bit awkward to use. Basically you pass it the function you want to run and all its corresponding args, and it will return the list of nodes created by that function, and the return value of that function.

Just a quick note – as it says in the comments if you don’t want MObjects returned you can easily return node names instead. Although if you’re using the apiExtensions module you can use MObject instances as if they were node names. You can grab the apiExtensions module from here, or just grab it out of the latest release.  Or if you’re a pymel kinda guy/gal, I expect you can instantiate the PyNode class with an MObject.

Moving on, here is a quick example:

from maya.cmds import *
def someFunc():
        spaceLocator()
        group( em=True )
        joint()
        polySphere()

        return 'some interesting return value'

nodesCreated, returnValue = getNodesCreatedBy( someFunc )
print nodesCreated, returnValue

Thats it. Doesn’t matter how the nodes are created, this function will capture them all.  You may also notice that the shape nodes for the locator have been included as well.  The nodesCreated list will quite literally contain ALL nodes created by the function passed in.

So whats it used for?

Just say I want to write a tool that will build a dynamics network on a given control chain.  I want to be able to turn this functionality on and off easily and I want to make sure when it gets deleted there is no cruft left behind.  First I write the code to build the network.  Then I write another function that will execute this code and capture the created nodes and put them in an object set or a container or something.

Skeleton Builder works in this way.  When a rig part is built the build method gets run inside this node capturing decorator and all created nodes are put into an object set.  So Skeleton Builder can easily delete a rig cleanly.  It can also more easily understand the relationship between a given node and a given part of the rig.

Another tool that uses this is the Dynamics Tool.  This tool will create a hair follicle setup and constrain a given list of objects to it.  It will then give you an interface to delete and create this setup on the fly, or bake the results down to keys.  The deletion of the hair setup is clean because ALL nodes are captured when the rig is created.

One minor thing to note – if you’re running maya 2009 there is a bug with removing node creation callbacks…  This bug is fairly harmless although it may result in noticeable slowdowns if you end up with lots of improperly removed callbacks.

Lets take a clothed hero character as an example. Breaking implementation of this character asset down into areas of expertise we’ll most likely have a character modeler, a facial modeler/rigger, a clothing sim guy and then the body articulation guy who may also be the guy who builds the puppet rig on top of the deformation rig.

Now obviously this could all be handled by one guy, but on most big productions it isn’t. After all, being a fantastic facial modeler/rigger is hard. Really hard. And it takes many years of work, practice and study to do really well. Similarly for simulation, modeling, deformation rigging and puppet rigging. There are very few people in the world who are fantastic at all of these. And even if you did give the task to one guy, it takes a long time to do all this work. Doing the tasks in a serial fashion is usually unacceptable. So you want to be able to split the work up, assign different people to get the job done and charge forth.

Making it possible to have many people work on a single asset however is kinda tricky. How do you funnel all that data together? Ideally you want to be able to build some sort of recipe to take a bunch of different pieces and splice them together. But this splicing process needs to be easy to use and ideally transparent.

As an example lets take body articulation. Lets build a proxy model – as close in proportions to what we think the final model will be. Ideally this proxy model will be some early version of the model that everyone is happy with. The articulation guy can then setup skinning and deformation rigging on this proxy geometry. Once we start getting revisions of the final geometry we can take this proxy geometry and transfer skeletons and weights onto the final geometry and spit out a rigged version of the actual geometry. This way the modeler and the rigger can iterate in parallel without to stepping on each other’s toes.

Lets take the face as another example. In a similar way we can have the facial guy start doing the facial rig on proxy geometry. As newer revisions of the geometry come in the facial rig can be transferred to the new geometry, tweaked as necessary and then spliced together with the rest of the body geometry. This finalized geometry can then be combined with the articulation pass we talked about above and sent down the pipe for puppet rigging, or simulation or whatever other requirements you have.

The transfer of data between the proxy geometry and the finalized geometry can be done in a variety of different ways. And which way you choose depends on the specifics of what you’re after. Using UV space to transfer data is probably one of the most reliable methods of transfer, but you can also use closest point.

So how does this recipe get run? Well there are a variety of ways of doing this, but this is what I did. I wrote a file format to describe the recipe. It basically was a format that recorded a bunch of operations such as LoadGeometry, MergeGeometry, CopySkinningAndSkeletonFromGeometry, ReplaceMaterial etc… These operations required various arguments which were also recorded. There was an editor which would allow you to setup these operations which were then saved to disk. Then in maya I wrote a file translator plugin which would run these operations and import the resulting data. This allowed us to reference these recipes into maya. So for example, just say an artist wants to see the latest version of a character’s skinned geometry and facial rig. They would simply reference in the appropriate recipe. Then the file translator would run the latest operations on the latest data and dump the result into the maya scene. So each time the scene is loaded the latest data is being operated on. So artists were always seeing the latest data without having to remember to publish their files or anything like that. The process was transparent.

Obviously people still need to communicate closely. The situation is akin to multi-processing. Some problems can easily be spread across multiple processors while others are not. And even problems that can be split up don’t always get faster when you throw more processors at the problem. Communication between people can be a bottleneck. There is definitely a sweet spot, it just depends on the specifics of the asset being produced.

The system I worked on used a proprietary data format which worked out ok, but we ended up implementing a lot of basic functionality.  Wrap deformation, soft selection, skinning, merging of vertices etc… It would have been a lot more powerful had I been able to use blender for the data manipulation because it has all of this functionality already.

Anyway… Maybe once blender is available as a standalone python module we can get all major 3d apps to implement blender exporters and a general system like this can be implemented. Blender as a 3d exchange format would be awesome. WAY more awesome than collada.

import bpy
scene = bpy.import( "c:/somefile.blend" )
for obj in scene.objs:
    ....
scene.save()

Imagine how cool that would be? You’d have the worlds most powerful, scriptable 3d/2d geometry library. It’d be awesome.

Incidentally, Houdini does exactly this as far as I understand. I don’t know much about houdini (apart from how unbelievably cool it looks) but I watched a video on this where they imported the houdini module from within maya, and then did a whole bunch of cool stuff and blatted it into maya. You could basically leverage a huge amount of houdini functionality in any app that runs python. It also means you can do a whole lot of stuff without the horrid cost of loading the UI.

As cool as it is that houdini can do this, it would be infinitely cooler if blender could do this.

How ’bout it blender devs? I think this feature would make blender amazingly useful to the games/film community. I’ll go into this a bit more in a future post.

def interfaceTypeFactory( metaclassSuper=type ):
	'''
	returns an "Interface" metaclass.  Interface classes work as you'd expect.  Every method implemented
	on the interface class must be implemented on subclasses otherwise a TypeError will be raised at
	class creation time.

	usage:
		class IFoo( metaclass=interfaceTypeFactory() ):
			def bar( self ): pass

		subclasses must implement the bar method

	NOTE: the metaclass that is returned inherits from the metaclassSuper arg, which defaults to type.  So
	if you want to mix together metaclasses, you can inherit from a subclass of type.  For example:
		class IFoo( metaclass=interfaceTypeFactory( trackableTypeFactory() ) ):
			def bar( self ): pass

		class Foo(IFoo):
			def bar( self ): return None

		print( IFoo.GetSubclasses() )
	'''
	class _AbstractType(metaclassSuper):
		_METHODS_TO_IMPLEMENT = None
		_INTERFACE_CLASS = None

		def _(): pass
		_FUNC_TYPE = type( _ )

		def __new__( cls, name, bases, attrs ):
			newCls = metaclassSuper.__new__( cls, name, bases, attrs )

			#if this hasn't been defined, then cls must be the interface class
			if cls._METHODS_TO_IMPLEMENT is None:
				cls._METHODS_TO_IMPLEMENT = methodsToImplement = []
				cls._INTERFACE_CLASS = newCls
				for name, obj in attrs.items():
					if type( obj ) is cls._FUNC_TYPE:
						methodsToImplement.append( name )

			#otherwise it is a subclass that should be implementing the interface
			else:
				if cls._INTERFACE_CLASS in bases:
					for methodName in cls._METHODS_TO_IMPLEMENT:

						#if the newCls' methodName attribute is the same method as the interface
						#method, then the method hasn't been implemented.  Its done this way because
						#the newCls may be inheriting from multiple classes, one of which satisfies
						#the interface - so we can't just look up the methodName in the attrs dict
						if getattr( newCls, methodName, None ).im_func is getattr( cls._INTERFACE_CLASS, methodName ).im_func:
							raise TypeError( "The class %s doesn't implement the required method %s!" % (name, methodName) )

			return newCls

	return _AbstractType

class ITest( metaclass=interfaceTypeFactory() ):
	def something( self ): pass
	def otherthing( self ): pass

class Test_implementsAll(ITest):
	def something( self ): pass
	def otherthing( self ): pass

class Test_subclassImplementsAll(Test_implementsAll):
	pass

class SimilarInterface(object):
	def something( self ): pass
	def otherthing( self ): pass

class MultipleInheritanceTest(SimilarInterface, ITest):
	pass

#will throw TypeError
class Test_implementsSome(ITest):
	def something( self ): pass

#will throw TypeError
class Test_implementsNone(ITest):
	pass

There are some simple tests at the bottom that demonstrate the idea.

As you can see, the class MultipleInheritanceTest has no methods, but its parent class SimilarInterface does implement the required methods, so the class passes without issue.

Anyway – I figured after the previous post I should at least finish the thought. The implementation in the last post wasn’t complete.

So I toyed around a bit this evening and came up with what you see below. It seems to work – at least for this trivial case. I’m not sure this is necessarily a good implementation, but it goes to show that its reasonably easy to do.

def interfaceFactory( metaclassSuper=type ):
	class AbstractClass(metaclassSuper):
		_METHODS_TO_IMPLEMENT = None

		def __new__( cls, name, bases, attrs ):
			subCls = metaclassSuper.__new__( cls, name, bases, attrs )

			#if this hasn't been defined, then cls must be the interface class
			if cls._METHODS_TO_IMPLEMENT is None:
				def _(): pass
				funcType = type( _ )
				cls._METHODS_TO_IMPLEMENT = methodsToImplement = []
				for name, obj in attrs.items():
					if type( obj ) is funcType:
						methodsToImplement.append( name )

			#otherwise it is a subclass that should be implementing the interface
			else:
				for methodName in cls._METHODS_TO_IMPLEMENT:
					if methodName not in attrs:
						raise TypeError( "The subclass %s doesn't implement the %s attribute!" % (name, methodName) )

			return subCls

	return AbstractClass

class TrackableType(type):
	_SUBCLASSES = []

	def __new__( cls, name, bases, attrs ):
		newCls = type.__new__( cls, name, bases, attrs )
		cls._SUBCLASSES.append( newCls )

		return newCls

class ISomething( metaclass=interfaceFactory( TrackableType ) ):
	def something( self ): pass
	def otherthing( self ): pass

class Something(ISomething):
	def something( self ): pass

If you run this code you’ll see a TypeError is raised complaining that the Something class doesn’t implement the otherthing method as soon as you import the script. Not when you try to instantiate a Something instance.

You’ll notice it only cares about methods being implemented – so if you wanted to force implementation of various properties in inherited classes, you’d probably need a few more conditionals in there – but I generally try to avoid properties. They feel dirty.

Anyway, nothing terribly useful, but I thought others might find it interesting.

The MelObjectScrollList class is subclass of MelTextScrollList – which is a wrapper to the cmds.textScrollList widget command.  The class provides a neat object oriented way to interact with the scroll list.  It hides some of the weirdness of the command (such as indices starting at 1 – WTF?!) and makes it possible to write object oriented code with all the good stuff you expect.

Back to the MelObjectScrollList – so the idea with this class is to use the textScrollList widget to display lists of data of any kind.  Want a list of dictionaries?  No problem.  Want a list of MObjects?  Vectors?  You get the idea.  You can pass any python object you want into the UI and it will display them in the widget, let users select them, and then return you the list of objects that the user selected.  Its very useful.

So how does it work?

Well, the base class contains most of the functionality you need.  There are two general cases.  If you want to display lists of objects that already have a reasonably sensible, user friendly string representation, then you can use the MelObjectScrollList directly:

import maya.cmds as cmds
from baseMelUI import MelObjectScrollList

w = cmds.window( 'test', t='test', h=300, w=300 )
c = cmds.columnLayout()
objScrollList = MelObjectScrollList( c, h=250 )
objScrollList.setItems( [ [], {}, ['some', 'list', 'of', 'strings'], dict, MelObjectScrollList ] )
cmds.showWindow( w )

def onSel( *a ):
	print objScrollList.getSelectedItems()

objScrollList.setChangeCB( onSel )

Incidentally I don’t normally write UI code like this – I just figured doing it this way might make it more available to folks who don’t use baseMelUI for their UI creation. Its also a good demonstration of how the library can be used in a mix and match way (even with pymel!).

So as you can see if you run this code (and have the zooToolbox – or at the very least, the baseMelUI module in your python path) you’ll see a window pop up with the above objects in it. They look just as if you’d called print on each one.

Now if you want to customize the way these objects are displayed in the UI, then you simply need to subclass the MelObjectScrollList and override the itemToStr method. Here is an example:

from filesystem import Path
from baseMelUI import MelVLayout, MelObjectScrollList, BaseMelWindow

class FilenameScrollList(MelObjectScrollList):
	def itemAsStr( self, item ):
		return Path( item )[-1]

class Test(BaseMelWindow):
	WINDOW_NAME = 'test'

	def __init__( self ):
		f = MelVLayout( self )
		self.fileListUI = FilenameScrollList( f )
		self.fileListUI.setItems( Path( "c:/windows" ).files() )
		self.fileListUI.setChangeCB( self.on_itemSelect )
		f.expand = True
		f.layout()
		self.show()
	def on_itemSelect( self, *a ):
		print self.fileListUI.getSelectedItems()

Test()

In this example you should see a window open up with a list of the file names in c:\windows. When you select an entry in the list, you’ll see the full path to that file printed in the script editor. The FilenameScrollList keeps track of the objects you put into it. It acts as a broker between the data and the UI. So using it simplifies code a heap.

Another neat feature thats built into the base class is view filtering. So building on the above code you can do things like this:

ui = Test()
ui.fileListUI.setFilter( '.exe' )

As you can see, once you run the setFilter() method the list now only displays files containing “.exe”. The UI still retains a list of all the files, but it only displays the items that pass the filter.

Lastly the other useful feature the class provides is re-ordering. The methods are “moveSelectedItemsUp()” and “moveSelectedItemsDown()”. You can easily hook up these methods to buttons, popup menus or whatever else you want.

from filesystem import Path
from baseMelUI import BaseMelWindow, MelHSingleStretchLayout, MelVLayout, MelObjectScrollList, MelButton

class FilenameScrollList(MelObjectScrollList):
	ALLOW_MULTI_SELECTION = True

	def itemAsStr( self, item ):
		return Path( item )[-1]

class Test(BaseMelWindow):
	WINDOW_NAME = 'test'

	def __init__( self ):
		f = MelHSingleStretchLayout( self )
		self.fileListUI = FilenameScrollList( f )
		self.fileListUI.setItems( Path( "c:/windows" ).files() )
		self.fileListUI.setChangeCB( self.on_itemSelect )
		f.setStretchWidget( self.fileListUI )

		v = MelVLayout( self )
		MelButton( v, l='up', c=self.on_up )
		MelButton( v, l='down', c=self.on_down )
		v.expand = True
		v.layout()

		f.expand = True
		f.layout()
		self.show()
	def on_itemSelect( self, *a ):
		print self.fileListUI.getSelectedItems()
	def on_up( self, *a ):
		self.fileListUI.moveSelectedItemsUp()
	def on_down( self, *a ):
		self.fileListUI.moveSelectedItemsDown()

Test()

NOTE: make sure to grab the latest baseMelUI.py from here. While writing this post I fixed a bug with the moveSelectedItems methods when a filter is set.

So a lot of the time I find I’ll author my skeleton, skin the geo and build the rig only to find that the skinning doesn’t hold up so well as soon as I strike a certain pose in the animation.

Some people solve this by having a “test suite” of calisthenics they put their characters through before they get animated. And sure, this can work well provided you have some way of describing these calisthenics in a generalized way that will apply to any and all characters that come down the pipe. A spider is going to need a different set of poses to a human, which will be different again for a multi-headed dragon which is different again from a snake like creature with 6 arms.

Anyway, this happens enough that I figured I’d try to alleviate the problem a bit. So I wrote a tool that will take skin weight edits made in the animation file, and push them back to the file the model geometry is stored in.

The process goes something like this.

You’re animating away, and you strike a pose only to realize you’ve got horrible shearing happening somewhere. So in your animation scene, with the pose that breaks the skinning you crack open whatever weight/editing painting tool you’re into and go about fixing the problem area. Now because you’re in an animation scene the skinCluster you’re editing actually lives in a completely different file.

So you run this tool. The tool grabs the skinCluster edits made in the animation scene and shoves em into memory. Then it removes the ref edits from the skinCluster node and saves the animation scene. Then it opens up the file the skinCluster node lives in and applies the fixed weighting it stored from the animation scene and saves the file. Finally it opens the scene you were originally in and voila. Just like that, you’re weights are fixed across the board.

Its not the worlds most useful tool – but it saves the occasional headache, and in fact gets used quite regularly. It makes it easy to edit/fix skin weights “in context” without any convoluted workflow.  And in fact having such a tool means minor skin weight polishing happens more frequently now than before the tool existed because its so easy to do.  Skin fixes can be done in any animation as soon as the problem is seen.

NOTE: maya supposedly has functionality to “Save Reference Edits” but as usual, it seems like a largely useless feature.  Has anyone managed to use it successfully?

Anyway, as useful as warnings and errors are, if you’re writing modular, re-usable code then writing stuff to the script editor isn’t always as helpful as it should be. Sometimes its hard to know exactly where a message is coming from. Sure, you can grep your code base, but sometimes even this isn’t that easy to do if the message itself is constructed.

In the olden days of MEL I would often try to put the function name at the beginning of the message in the hope of making it easier to track down the reference at a later date – but this wasn’t terribly ideal either. It required me to remember to do it, plus it was just one more reference to update when refactoring.

Python however gives you the tools to solve this problem in a nifty way. You can write a print handler that will figure out where in the code the print/warning/error statement happened and put all that in the message.

For example, I can write code like this:

printWarningStr( "WOW!" )

And the following message gets spewed to the console:

# Warning: WOW!: from line 14 in the function main in the script D:\someScript.py #

As you can see, in the message is encoded the warning prefix (it also turns the script line pink as per usual warning messages in maya) as well as the name of the function it came from, and the location of the script. You could also put the line number in there as well, but I figured I’d omit that for the sake of brevity.

Python is such an awesome language – so deliciously introspective.

So does this get done?

Well, I have two places that I setup this code. The first is in a generic, maya agnostic module so that I can use it in non-maya tools. It looks like this:

def generateTraceableStrFactory( prefix, printFunc=None ):
	'''
	returns 2 functions - the first will generate a traceable message string, while
	the second will print the generated message string.  The second is really a
	convenience function, but is called enough to be worth it

	you can also specify your own print function - if no print function is specified
	then the print builtin is used
	'''
	def generateTraceableStr( *args, **kw ):
		frameInfos = inspect.getouterframes( inspect.currentframe() )

		_nFrame = kw.get( '_nFrame', 1 )

		#frameInfos[0] contains the current frame and associated calling data, while frameInfos[1] is the frame that called this one - which is the frame we want to print data about
		callingFrame, callingScript, callingLine, callingName, _a, _b = frameInfos[_nFrame]
		lineStr = 'from line %s in the function %s in the script %s' % (callingLine, callingName, callingScript)

		return '%s%s: %s' % (prefix, ' '.join( map( str, args ) ), lineStr)

	def printTraceableStr( *args ):
		msg = generateTraceableStr( _nFrame=2, *args )
		if printFunc is None:
			print( msg )
		else:
			printFunc( msg )

	return generateTraceableStr, printTraceableStr

generateInfoStr, printInfoStr = generateTraceableStrFactory( '*** INFO ***: ' )
generateWarningStr, printWarningStr = generateTraceableStrFactory( '*** WARNING ***: ' )
generateErrorStr, printErrorStr = generateTraceableStrFactory( '*** ERROR ***: ' )

As you can see, this is a factory function that returns a function that will generate the message, and one that will actually print the message. You almost always want to use the print one, but if you ever need to generate an info/warning/error message using the same code, the generate function is available.

So the factory function allows you specify a print handler. It defaults to python’s built in print function (or statement if you’re pre 3.0), but this makes it easy to generate maya specific print functions using MGlobal.displayWarning and MGlobal.displayError. In another module I have the following code:

from maya.OpenMaya import MGlobal

generateInfoStr, printInfoStr = generateTraceableStrFactory( '*** INFO ***', MGlobal.displayInfo )
generateWarningStr, printWarningStr = generateTraceableStrFactory( '', MGlobal.displayWarning )
generateErrorStr, printErrorStr = generateTraceableStrFactory( '', MGlobal.displayError )

So in maya tools I simply use the above functions instead of print and voila – I get useful information in the console spew.

Anyway – not a super useful chunk of code, but I thought others might find such a technique useful. Its ~15 lines of code that occasionally saves me a grep of the codebase. Plus its good practice to have logging hooks like this in place.

Today I found an early piece of code I wrote. Its a useful chunk of code – parses config files.

Anyway I wanted to add some functionality to the code. See the config files it parses are often written by hand, and the format supports C-style comments. Currently the parser throws away the comments which is no drama if you just need read support – but a feature request came up that would require the writing of these files from a tool. So I need to preserve comments as best as I can.

Not a big drama to add the functionality except that part of the code I ended up having to touch involved one of the operator overloads – in this case the [] operator (__getitem__ in python). The existing overload was done in a super weird way (what I wanted to slap “past me” for). I made it so you could do this:

f = ConfigFile( 'd:/something.txt' )
f.read()
f[0, 2, -1, 9]

Which would navigate the config file document hierarchy. Why?! Well, probably because I was a n00b and figured it’d be “cool”. SLAP!

Anyway, whats the point here? Well, I guess what I’m trying to say is (apart from don’t write idiotic code) – if you’re going to overload operators be really really careful. Tracking down where the code is used is hard. You can’t really grep your codebase for anything in particular – after all, the whole point of operator overloading is so the interface to the action looks like a standard language operator. In this particular case it wasn’t a big deal – the code is used in only a few places. But if this code had wider use, it would’ve been a nightmare.

This is pretty obvious to anyone who has been coding for awhile – but after this recent reminder I figured a little PSA might save others some pain

just wondering what you are feeling are sticking points, what
area are you having to work hardest on now v. back in the flow

I thought the answer was worth more than a tweet, so here we are.  A quick bit of background to set the stage:  I started out in 3d as an animator.  I morphed into the role of a tech artist because those around me didn’t step up – technical leadership is important, and I guess it suited me.  I’ve discussed it here before (third paragraph) so I won’t bore you again.  But basically thats been my path.  I started out doing lots of animation, and have ended up doing not so much.  In fact, I have done very little animation during the last almost 5 years now.

For now the animation work I’m doing is very much a part time thing.  There are still loads of technical problems and improvements to be made, and honestly, I’m a much better technical artist than I am an animator.  But doing animation is something that I think is really important for me as a technical animator.  Using the tools I’ve written, working through the workflows I’ve helped define, having to deal with all the bugs, shortcomings etc of the work environment I’ve helped create puts me in the shoes of my users and forces me to see and understand the implications of my design decisions.  And I think thats really important.

Anyway – sticking points.  Well, the first would be the calibre of the folks around me.  ;)  Yeah, they’re all kinda good.  I mean, I was never the best animator, but the animators I work with literally are, some of the best.  I guess this isn’t really a sticking point – its more of an opportunity for me to learn and grow.

But the other big thing is the fact that its hard to stop thinking about the technical side of things while I’m animating.  Its been such a part of my mental process for so long that its really hard to turn it off.  And I think this is the biggest thing.  So many parts of the animating process have the potential to be improved, sped up, optimized, made easier etc…  And when I’m animating, all these thoughts are running through my head.  So just pushing those thoughts aside – or at least shelving them for later – is hard.

Like any creative process you do your best work when you’re in “the zone”. And getting into “the zone” is all about focusing all your thoughts on what you’re doing. Whether that be animating, painting, composing music or writing code – if you can push all thoughts aside except for those related to what you’re doing, you can usually get into this amazing mental groove. Its awesome. So I find it very hard to get in “the zone” when I’m animating these days. It doesn’t stop me from doing work, but it does make it harder and less efficient.

Anyway, Brad – and anyone else who was interested, I hope that answers your question!

Which is actually where the drag/drop functionality gets used.  So in this tool there is a canvas on which you can place “buttons” and arrange them in various ways.  These buttons can have somewhat arbitrary functionality, but by default they simply select objects.  The idea being that you can arrange them in the shape of your character such that picking the appropriate rig control is easy and intuitive (you’ve probably seen them before).  In viewport controls are great, but they can make the silhouette harder to read, and they’re sometimes hard to find which causes the animator to do more camera manipulation than is desirable.  Of course having to move the mouse/focus over to a picker tool isn’t ideal either but it definitely has its time and place in the toolset.

But again I digress.  So part of making the tool reasonably easy to use is to make it easy to arrange these buttons – and the easiest way to do that is to use a drag and drop paradigm.  Well, I guess technically the easiest way is to make it auto-magic, but that is a topic for a future post (and is an up-coming skeleton builder feature!  ;).

Anyway – so drag and drop.  I’ve never bothered with drag and drop in maya before.  Looking at the docs I figued it’d be straight forward enough.  And in hindsight it actually is straight forward – although when I was prototyping I was blocked by a horrible bug/shortcoming.

Currently I’m laden with maya 2009 – and the following doesn’t seem to apply to 2011 (not sure about 2010).  But in 2009 if you set a drop callback that returns nothing, or an empty list – the drop callback silently fails.  Thats right – no warning, no error, no exception, just silent failure.  In fact, for awhile there I figured perhaps drop callbacks hadn’t been implemented in 2009 for python.  It wouldn’t be the first widget to be incompletely exposed via python – look at the press command for the treeView widget (incidentally the tree widget wrapping in baseMelUI has a nice workaround for this)…

Just to be explicit – here is an example that fails:

def dropCB( * ): return []

By changing the drop callback to return [""] makes everything work as expected.

Anyway – hopefully this little nugget saves someone else a few tufts of hair.  Of course, after discovering this I found this page – which, while not talking python here would probably have put me back on track.

I’ve even been animating!  Man, its been a long time since I’ve done that.  It shows too – it’ll take me awhile to get back to where I was.  But thankfully I work with some amazing animators who will whip me into shape.

Anyway, it sounds interesting so you should definitely check it out!  If you’re not using an IDE to write tools with – you should definitely check this out.  For the longest time I wrote scripts in a text editor (I didn’t have much choice – MEL has no IDE) and when I started using wing a few years ago – holy cow!  Being able to set breakpoints and step through your code as it executes – and experiment with code inside a live, running script was a HUGE productivity booster.  I’ve not used a print statement for debugging in a long time.

Props to the Rigging Dojo guys for putting together great events for the community like this!

You can post comments using an existing google, twitter or facebook account so you no longer have to remember your account details specific to this site.

Anyway – please leave comments or send mail if you have an opinion either way!

Anyway I had an annoying bug with one of my tools the other day.  Basically I was passing in a node – lets say it was called “someNode“.  Anyway at the start of the function call it was totally valid, but by the end of the function it didn’t exist.  There were a couple of problems that teamed up to make it extra annoying.  The first is that objExists will return True if any node with the given leaf name exists.  So by the end of the function – objExists( “someNode” ) was returning True even though any other command would throw a RuntimeError.

As it turns out the function was creating a new node with the same leaf name.  So as soon as the new node was created, the name of “someNode” immediately changed to “|someNode“.

Now I know what you’re thinking – “Dude if you’d just use pymel you wouldn’t have had this drama!“.  And you’re totally right.  If thats the way you roll, good for you.  But I expect you know my stance on pymel already so I won’t go into it.  Honestly this exact case is probably the best reason to commit to pymel.  Those who have already made the transition to it possibly don’t even know what I’m talking about.

Anyway – the fix is easy of course.  And there are a bunch of ways you can go with it.  I went the route of casting the “someNode” object to an MObject at the start of the function, but I guess you could also detect the name clash before creating the new node and modify its name accordingly – which I guess is the only option you have if you’re using mel.  But it was a frustrating half hour of my life that I’ll never get back!  ;)