Saturday, 27 October 2012

Older versions of Maya???

Wow, I just opened up the toolset in Maya2009 for the first time in a while and it's not good. There are a few issues that I wasn't aware of. The main AnimUI fails to open because I think there's some extra catches in the newer versions. I knew that none of the MetaData calls would work due to Python2.5 not shipping with the Json module so the question is, do I drop support for 2009/2010 completely or do I keep patching it? The UI call I can fix and there's already a catch in there to warn about lack of Json support. However, without Json the Scene Review will also fail as it relies on metaData to store the dict. Any comments? Red

Tuesday, 16 October 2012

MetaClass - extra candy for complex Json attributes

Ok here's an interesting question. At the moment with the MetaClass stuff you can serialize a complex python structure, like a dictionary, to a string attribute on the MClass Maya node which then means you can do something like this:

#make an r9Meta.mClass node with an attribute managed by the JSON handler

#return the original dict back from the Maya Node
all goodness so far, but what if the user then does the following?


mClass.newDict['A'] #2.0 ??????
You expect that would then modify the mClass attribute you added, wouldn't you? Well no, as the mClass.newDict returns a standard dict (by deserializing the Json string, which is then out of the scope of the metaClass code, it's just a dict and has no knowledge of the mClass itself.

So I've been thinking, what if the mClass.__getAttribute__ call that returns that dict actually returned a managed dict of my own type with an overloaded __setitem__ which would then push the changes back to the original mClass attribute? Well it works in testing, not sure if there's an easier way of linking these but I couldn't think of one. The beauty now is that you can do the following and this will pass the value back to the mClass and reserialize it back to the actual Maya string Json Attribute

mClass.newDict['A']  #fooBar
I'm still looking into this but it certainly makes the code side a hell of a lot more manageable and flexible when you're using this class



Monday, 15 October 2012


Well another day another toolkit in progress and testing. This is a really simple concept, a SceneReview tool that stores comments and review notes made by people across the studio as they open and comment on the scene file.

 The data is stored internally in the scene, if you make a comment then only you can edit it. If somebody else open the scene up and wants to comment, they 'Add a New Comment' which pushes the current one to the history stack so it becomes part of a tracked review for that scene.

 The cool bit is the 'Activate Live Review'. Dead simple, it adds a scriptNode to the scene so that when the scene is open the UI pops up and displays all the comments and history that have been made. If the Live Review is killed I delete the scriptNode and it no longer pops up (but the data is still there next time the UI is opened)

This'll probably make the next release in a few weeks after I've tested the Relative Pose code a little more deeply



Wednesday, 10 October 2012

Some updates and cleanup

Well I've been having a serious session on the PoseSaver and decided it was about time that I added the ability to load a pose RELATIVE to a given node. This is up and running in test at the moment. So the idea is that you select a node you know to be in the poseFile (ie a rigController) and as long as you have the 'relative' flag set and are in hierarchy mode then the pose will load relative to that MayaNode. This means if you have a walk cycle and store the start pose, then scrub to the end of the anim, you can now select a node and load the start pose at the end of the anim in the correct space relative to the given node.

It'll make more sense if I do a video but I know a lot of folks were asking if this was possible, so it's now in.
Also with the poseSaver I've removed the default behaviour that was reading in the filter stored in the pose, it seems to make more sense that the hierarchy filter is used from the UI and not defaulted to the filter stored when you made the pose. It's caught me out a few times now and I've spend half the afternoon going round in circles only to find that this was the culprit!


Thursday, 4 October 2012

Advanced Channel Management and attrMaps

I've been doing some more work on the channel management / LockChannelsUI and have come up with something pretty interesting. For those who don't know what this tool does, it's for managing what attributes, per node, are locked, keyable or hidden. There's nothing worse than getting a rig that has lots of sub-nodes with open channels for animators to abuse, this is aimed at doing something about that.

The first half is pretty standard and obvious, what channels in the hierarchy, or selected, do you want to manage. There's a specificAttr's field with RMB popup that allows you to grab attrs from the channelBox to include in the filter.

The cool bit is the attrMap. Lets say you're a rigger and have very carefully gone and locked everything you can from the animators but now need to unlock stuff to manage or tweak your setup, or you now have a new rig and want to lock the same attrs per node. With this you can select the top of your rig hierarchy, check the hierarchy box and store an attrMap for the entire setup. This stores the l,k,u,cb state of every attr, for every node in the hierarchy to an attrMap init file. The load restores each attributes status, either at a selected node level from the map, or for the entire hierarchy.

Now you can select the top of your rig, unlock and unhide everything so you can mess around, then just restore the attr status's from the attrMap afterwards!