Updates.... gearing up for a new release

Been a while since I posted any updates so wanted to keep you all abreast of what's been happening to the pack. There's been huge development gone into the core of this recently, lots of UI updates and workflow cleanup to make it all a bit slicker in general.

PoseSaver has had a lot of work and now lets you load poses in relative space. The idea is that you select a node you know to be part of a saved pose, I then allow you to load the pose such that that selected node remains in place, the pose is loaded relative to it. This has 2 options for rotate and translates which both allow either 'projected' or 'absolute' calculations. Projected does just that, for rotates it calculates the global direction (relative to the current working up axis), in general that's the Y-axis direction. So you select a node, I workout the difference between it's current direction and it's stored direction, then apply the pose to compensate that difference, in effect locking the node in place. If 'absolute' is selected then rather than calculating the general direction, I just apply the pose completely around that selected node, allowing rotate in all axis. Similar thing happens for translates, either relative to the groundplane, or absolute, allowing vertical offsets.

Now like most of the tools the posesaver relies on the filter being set in Tab2 (above). To help I've unlocked the Node Priorities field and allowed you to set those up from selected nodes. The Node Priorities are CRUCIAL for PoseLoading in relative space as I often need to know the order in which transforms are applied. Lets say in a general rig the Hips are a child of the Root ctrl, so if I offset the Hips BEFORE the Root then you end up with double transforms and screwed up data. This is where the priorities come in, in the above, I'm specifying that root_control is processed before hip_control. You only need to set priorities on those groups that may cause this double transform.

You'll also notice that in the searchPattern above there's a new operator 'NOT:' this is way of excluding nodes that match everything else in the filter. So in the above, L_Arm_IKBlend_cont would match the filter 'cont', but because it's also specified as 'NOT:IKIKBlend' it is then excluded. This is a great addition to the filters and is also going in the attribute search as we speak. In fact for the attr search I'm also going to add a '=' operator as well so you can also catch specific attrs with specific values.

MetaData has had more upgrades. Lots of work gone into the core of the MetaClass. mNode in the class is now a property that wraps the MObject itself, so it doesn't matter if you rename of parent the node, the object will always be in sync. I've also allowed the message attribute handler in the _getattribute__ block  to return both sides of any message links. This was needed as I've been testing the idea of casting the HIK characterProperties node to metaData and using it as our internal skeleton definition setup, but that node is wired such that the node is the child not the parent of the joints, hence the change.

Lots of other things happening so I'll keep you posted

cheers

Red

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

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
mClass=r9Meta.MetaClass('myNode')
mClass.addAttr('newDict',{'A':2.0,'New':'hello'})

#return the original dict back from the Maya Node
mClass.newDict  

all goodness so far, but what if the user then does the following?

mClass.newDict['A']=5.0

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'
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

 thoughts?

Red

SceneReviewer

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

cheers

Red

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!

Red

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!


Red

MetaClass : More attribute handlers added

I'm expanding the attribute Handling in the base MetaClass as some of the examples in the unittests made no sense to me. For example if I did the following I'd get the color values back from the compound float3 attribute but I couldn't set them:

mLambert=r9Meta.MetaClass('lambert1')
mLambert.color  #Result [(1.0, 1.0, 0.0)]

In fact the whole way Maya cmds wraps the handling of compound attributes is crap! So I've wrapped them in the latest dev build and to me, they make a lot more sense than default Maya, you can now simply do:

mLambert.color=(1,0.2,0.2)

and the compound3 attribute will be set correctly, the value accepts either a list or tuple with 3 values, any less will raise a managed ValueError.

Also in the new build, v1.26 the messageLink handling in the base class was upgraded so that setting message links, either multi or non-multi is now a simple case of:

mNode.myMessageAttr=['newLinkA','newLinkB']

If the attribute already has connections those are disconnected and the relevant attrs deleted on the old connected nodes. Again as I'm going through this and more people are feeding back I'm gradually expanding the MetaClass base. If you find any more issues with the attribute handlers let me know

Oh and in the current build of v1.26 the presets in the AnimationUI fail to manage the metaRig checkbox and  are a little bit flaky, this is fixed, just got to update the server.
cheers

Red