Full Demo Video at last!!

At last I've had time to sit down and do a full run through of the Red9 Studio Pack. Many more demos to come so watch out.

thanks

Mark

It's DONE!! Happy Christmas all!

Red9 Studio Pack v1.27

Well Happy Christmas all, as you may know I've been beavering away really hard on the Studio Pack and have finally nailed down a build that I'm happy with, I've just updated the download link with Studio Pack v1.27 final. What's changed, well if you're running metaData then you may want to check the __setattr__ and addAttr changes as I've modified the way that I handle attrs, specifically enums and message links. Thanks to Josh Burton and a few others for pushing things ahead and nagging me!

PoseSaver has had more work done on it and YES videos will be done over Christmas, after the beer and whisky has worn off that is. The PoseSaver module also now has a compare class for verifying that one pose matches another. This is designed initially for me to run in the unittests, but also a very useful production tool, being able to say that this pose == that pose with a tolerance for checking float data.

Anyway, Happy Christmas all, nag me for more info or just keep checking for the Vimeo posts over the new year.

Download from CreativeCrash
Download from Google Drive

Mark

More MetaData goodness

I've just been adding to the MetaClass addAttr() call such that it now supports 2 important new features:
Firstly I've wrapped it so you can pass in any of the standard cmds.addAttr keywords which means you can set min, max values etc whilst adding, something that's been requested a few times now.
I've also added double3/float3 support to the call so in one go you can do this:

self.addAttr(attr='attrName',type='double3',value=((subAttr1,subAttr2,subAttr3),(value1,value2,value3)),hidden=False, min=0,max=10)

Which will add a new compound double3 attribute 'attrName' with chuild attributes subAttr1 2,3, set their values to value1,2,3. It'll also push the min and max to these subAttrs and set the whole lot keyable and exposed to the channel box :)

Still thinking if there's maybe a neater way to pass the value data but we'll see. It's all pretty well documented in the code anyway.

cheers

Mark

Uncovered ;)

Well as you may have seen, I've finally come clean, see my other blog here for details!

Mark Jackson Blog

The power of the FilterSettings class

One of the guys from work asked me about this today and I thought I'd post it up here to show you just how you can use the power of the settings object to filter and organize nodes in Maya. In this example we have 2 rigs in the scene and I want to run a function that will scan both hierarchies for nurbsCurves who's name contains 'Ctrl' and match the nodes, then process the matches in pairs. filterSettings is a class designed specifically just to hold a set of args to be passed into the main filters, it's what the presets in the Hierarchy tab use and store for you.

Here we have the 2 Top nodes of both hierarchies selected. This is the CORE FUNCTION of the entire AnimationUI, it's how it processes matched pairs into something usable for the code:

import Red9.core.Red9_CoreUtils as r9Core

#make a settings object and set the internal filter types
filter=r9Core.FilterNode_Settings()
filter.nodeTypes='nurbsCurve'
filter.searchPattern='Ctrl'

#use the processMatchedNodes call to do all the work for you!
matched=r9Core.processMatchedNodes(cmds.ls(sl=True),filterSettings=filter)

#matched is an object which contains MatchedPairs, a list of tuples in
#the form [(source, destination)] This in turn lets us unpack the
#data in one go for processing
for source,dest in matched.MatchedPairs:
 print source
 print dest

The same filter can be passed into most of the Red9 functions and is used extensively across all the code. For example the above code is filtering hierarchies, so if we just wanted to search a single hierarchy we can pass the same filter to the FilterNode class:

filterNode=r9Core.FilterNode(cmds.ls(sl=True),filterSettings=fSet)
filterNode.ProcessFilter()

This is again a key concept in the entire pack so worth looking at if you're intending to use the code. 

cheers

Red

Red9 Studio Pack v1.27 - RC candidate :)

Well after a LOT of work v1.27 is pretty much nailed down. Huge list of upgrades both to MetaData systems, PoseLibs and in general across the board. I'm going to be doing a full video sweep of all the toolsets in the next few days and once done I'll push the build out.

A few last minute fixes are still going in but I'm really excited as this build has huge potential. MetaRig is now in full production at work and being battered, hence all the changes at the moment. I really want to nail down the api before shipping this one in case people start to use it internally like we're now doing.

Brief outline of changes:

• MetaData has multiple expansions and fixes to MetaClass and MetaRig. Too many to write so it's easier to just look through both the unittests and the example files. Some of these calls are to make it easier for you to subclass the code for your own use, particularly the 'getChildren' and '__bindData__' funcs.
• PoseSaver now fully supports relative pose loading, ie, loading the stored data relative to a given node. This supports projected and absolute modes. Projected is the pose offset relative to the current ground plane, with projected direction and translation, absolute is just that.
• PoseSaver now supports a PosePointCloud system to allow you to manipulate a rig in world space with geo reference. 
• PoseSaver UI has had a ton of upgrades to make it more user friendly, mainly in the RMB menu's
• FilterNode hierarchy filtering now supports an '=' and 'NOT:' operator so you can specify you want all nodes with x attribute where x=6. Or NOT:thisAttr which will exclude all nodes with the given attr. Again, take a look at the unittests
• Hierarchy tab in the AnimUI now has a RMB bound to the filterPriorities scroll to let you set these yourself and modify the order.
• SceneReview upgraded
• AttrMap now capable of storing the attrMap internally on a given node so a rig can have it stored as an attr on itself for re-loading any time you need.
• MetaNodeUI now supports a double click = select all children from selected system. Expanded RMB menu too.
• Mirror systems tweaked and finalized in code for mirroring animation and poses. This needs a UI to allow you to set it!

Still looking for more testers and feedback, particularly those on Linux/mac as I've tried to make this buils os independent but have no way of checking myself.

cheers
Red

Using MetaClass in your own classes

So in Red9 you have the power of a full MetaData api but how do you then expand and use that outside of the Red9 package? This came up recently with somebody inheriting from r9Meta.MetaClass in their own module outside of Red9. So I thought I give you a few pointers.

The first thing to note is that Red9_Meta builds up a global list of registered classes which inherit from MetaClass. Basically I need to know, when a node is passed into the MetaClass.__new__(), whether it's mClass attr (the string pointer that holds what class to instantiate on create) is in the known inheritance mapping. Think about it, I initialize the correct class object for you but the code needs to know if that class is available and registered in Python, otherwise I can't instantiate it for you.

This data is stored in global RED9_META_REGISTERY and in the Red9 pack that's setup in the Red9.core.__init__ by calling registerMClassInheritanceMapping()

All following!

Ok so Red9 is up and Meta knows about classes which have MetaClass as a base. By the way, this is found using the cls.__subclasses__(). But now you have a class outside of Red9 which is also using MetaClass and inorder for it to work correctly, you need to get that little bugger picked up and inside the RED9_META_REGISTERY!

This is all down to the order in which the modules are initialized. Lets say that you've booted Maya and Red9 is up. But you have a module in scripts which imports and uses Red9_Meta and it's not showing up in the meta registry. This is because until you import that module it won't show up in the subclasses cmd, and when you do import it, Red9 won't have it in the registry as it was imported after Red9 booted. So you need to first import your module, then force it into the RED9_META_REGISTERY by doing the following:

    #=========================================================================
    # Because we're now inheriting from Red9_Meta any reload on any module that
    # is instantiated from Meta will invalidate the RED9_META_REGISTERY. Here

    # we force the update on the Red9 internal registry
    #=========================================================================    
    from Red9.core import Red9_Meta as r9Meta
    r9Meta.registerMClassInheritanceMapping()  
    print '============================================='
    r9Meta.printSubClassRegistry()
    print '============================================='

Hope that makes sense, if not drop me a mail and I'll point you in the right direction! Red

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

Red9 Studio Pack v1.26 - released!!

Well it's finally tested and out, see download folder for the zip.

 Enjoy

 Red

Almost there.... v1.26 in testing

Now a Python Site-Package
Well I'm just tidying up a few loose ends before getting a new version ready for release. This is a BIG update with a lot of fixes so bear with me: The big change is that the systems no longer support the Maya module system, instead I've made it a proper Python site-package which makes it lots easier in many ways, it's also something that had been requested by a few people. I've updated all the docs to reflect this.

Main updates in Studio Pack v1.26:
MetaData has been fleshed out hugely since the last release, lots of additions and much better attribute handling across the board. There's a few good test examples that I'll ship which should take you through the MetaData basics. This is the core of the updates and has taken a lot time to nail down. It's also now threaded into the main UI's and FilterNode calls.

MetaData NodeUI: Added a new MetaData nodeUI for managing and finding MetaData in your scene. This has a RMB menu for filtering for specific class nodes.

Mirroring of Animation and poses is now supported via the MetaRig. This rely's on markers laid down when adding a MetaRig solution to your setups. I may in the future make this more accessible to non-coders and add a MetaRig UI for binding your rigs to the setups.

MouseMoCap: New RecordAttrsUI added in the menu which allows you to marker channels in the channelBox for recording, when you hit the record, the timeline is played and all changes to those attributes recorded and turned into keys.

Fixes:
CodeInspector in the ScriptEditor RMB menu now runs correctly from text selected in both the executer and reporter dialogues. I've also made this cross platform so hopefully the history inspect should run on Mac and Linux now. I'm testing a module called pyperclip which seems to do the job fine. The only limitation at the moment is that I'm doing an os.start(path) on the path I find and if you have Python installed, the default is to open the file in the standard Python shell rather than your editor. Trying to think of the best way to handle this limitation. Suggestions welcomed!

The timeOffset of animation on selected nodes would fail if you had AnimationLayers, this should now be fixed.

MetaData allows you to inherit from the MetaClass in your own code and have that code registered inside the systems. This will be explained in the examples that go out with the release.

cheers

Red

A few pointers for the new release

Red9 Studio Pack v1.26 is in testing at the moment with a few major upgrades.

Firstly it includes the upgraded MetaData systems, all of which are now integrated into the main AnimationUI calls, these hooks need testing but all seems fine so far.
With the MetaData I've also now added full Mirror animation and Pose support, based on the data that you bind up to the MetaData when it's added.
It also includes a MouseMoCap UI, something that somebody was requesting on one of the forums. It just lets you hook channels up from the channels box for record, then you hit the record button and any changes made to those channels get converted into keydata.

So a few pointers that have come up, be good to get others feedback on this stuff. These are comments on the api and code.

Question: * I'd somehow prefer it if mirrorData was a class/object
Yeah I kind of know what you mean. I was thinking of just a simple verified dict class that forces you to add
the correct data and pass that to the MirrorData arg. I guess I wanted to keep it simple when adding the metaData rather than having to make sure you build and pass in a mirrorClass settings object. The MirrorData ultimately gets built into a class when it's used by the r9Anim.MirrorHierarchy call, .getMirrorSets() builds the class dictionary up for the mirror sets which aree then processed in the main mirror calls.
One thing to note on this is that if you run without the hierarchy setup, the code will mirror matched pairs if it finds they're selected. Ie, you select left and right Feet, both of which have matching mirror slots, and their data will be exchanged. Now I could also have it search for the relevant matching pair object, so oyou select left and it finds right....not sure really. That might just be another wrapper call. Also if you have any center controls selected they're axis would be inverted.
Finally one thing I'm kind of stumbling on.... the axis by default works like this...

IF the mirrorAxis attr is found and has data, then those attrs will be inverted during the mirror
IF the mirrorAxis attr is found and has NO data, then no attrs will be inverted
IF the mirrorAxis attr ISNT found, then I use a default set of attrs to inverse

Does that makes sense? or do you think I should just stamp the defaults in the attr if you don't pass any in? That way the attr is always there and whatever it says is used.

Question: * MClassNodeUI().show() does not display sub FACIAL node from example (Doc's say it will display all)
This UI has an arg for mNodeType which by default is set to 'MetaRig' meaning it'll only show metaData nodes of type, maybe this should default to None so it does show all unless you want to filter it? At the moment it's only used by the Pose UI to find MRigs in the scene so you can choose the character to run the data to.

*Question: * The PoseFiles that get saved out currently load using the internal Filter that stored with the pose itself. Should there be an option to use either the internal PoseFilter, or the current UI Filter?
This is one that I'm mulling over at the moment. The backbone of all the systems is the FilterNode, the part that controls what nodes in a hierarchy get processed by all the functions. Now at the moment the Pose Loader uses the internal filter thats stored with the PoseFile. This has caught me out a few times and yes, I'm thinking that maybe there needs to be a flag in the UI to make this more obvious? thoughts??

*Question: *Should there be a UI to add the MetaData markers or do I leave this as a TD code solution?
What I may do is give people a really simple one that supports the predefined control functs (addWristCtrl.. etc) as well as an open add that wraps the main call addRigCtrl(). Not sure if the Mirror UI should be part of this or whether I should separate the UI's? Then again there's no real reason not to run the MetaData as it goves you so much more from a code point of view. Still a few more things to iron out, I want to be able order the ctrls in the dict that comes back, but not sure of the best way to do this at the moment.

Maya2009 - do I drop support?

Maya2009 do I bother????

Up till now I've made the Red9 compatible with Python 2.5 and therefore it'll still run in Maya2009. But with the MetaData setup I'm running the Json module which only came into Python in 2.6. So do I just say fuck it, and drop Maya2009 from support or do I include simpleJson in the packages and run that in case the import of Json failed?

Is anybody still running 2009?

New build needs testers!

Well I finally have a new build ready for testing! This has had a huge amount of effort put into it to integrate the new MetaData structures into the rest of the toolset. Whilst I was at it I also added a full MirrorPose/MirrorAnimation system that uses additional data supplied when adding a node to a MetaRig. There's a very detailed example file that latches onto the Morpheus Rig which should help guide you through my thinking so far.

Really keen to get a few folk testing this before I go too far off in my own direction. If you'd like to help drop me a mail and I'll add you to the test group.

thanks

Red

More Meta Fun!

Thought I'd share the current state of the MetaClass and MetaRig setups that I've been working on. The image above shows an initial test structure where the highlighted nodes are MetaClass network nodes. We have an initial MRIG node which is the entry point for all of this. Hanging directly off that are the main Rig controllers. We then have a SubMetaNode call ed Support with a Maya node hanging off it. Off the Support we also have a further MetaClass node called Facial which has lipsCtlr hanging off it. Now this is just a demo to show how we get round in this structure. The code for generating this is bellow

import Red9_Meta as r9Meta
import maya.cmds as cmds

mRig=r9Meta.MetaRig(name='MRIG')
mRig.select()

mRig.addRigCtrl('Chest_Ctr','Chest',boundData={'Side':'Centre'})
mRig.addRigCtrl('UpChest_Ctr','UpperChest',boundData={'Side':'Centre'})
mRig.addRigCtrl('Head_Ctr','Head',boundData={'Side':'Centre'})
mRig.addRigCtrl('Root_Ctr','Root',boundData={'Side':'Centre'})
mRig.addRigCtrl('L_Foot_Ctr','L_Foot',boundData={'Side':'Left'})
mRig.addRigCtrl('Hip_Ctr','Hips',boundData={'Side':'Centre'})

support=mRig.addSubMetaNode(nodeName='SupportNode',attr='Support')
support.connectChild(node='Settings_Node',attr='ExportData')

facial=support.addSubMetaNode(nodeName='FacialNode',attr='Facial')
facial.connectChild(node='Lips_Ctr',attr='Lips')

Now the beauty of this is that because the MetaClass base wraps all the Maya attrs and autofills the python objects dicts, we can lituarally walk the dag graph with dot complete! So to get to the Lips we can simply do the following, all of which autocompletes in the Maya scriptEditor for you ;)

mRig.Support.Facial.Lips

Also because of the way the mRig manages the Controls all of the controllers added above show up in the autocomplete on the mRig node. So you can just go MRig.Head to get the headCtrl back. I'm trying not to restrict this stuff, I'd rather make this as open as I can.

Again, the thing to bear in mind is that the main python objects __getattr__, __setattribute__ have been modified so that getting and setting all data types from Maya nodes is automatic. This includes getting and setting Emums and Message links.

 I'll up the latest build of this module is now up on my Google Drive, see download link in the Tags

cheers

 Red

MetaRig Class, looking for testers and feedback!

Going to do more on the MetaRig for Rig handling and finally look to integrate it into the whole tool chain over the next few weeks, hopefully I'll have a build with this all functional ready for testing soon. The idea is that you wire your rig to a MetaRig node and then no longer have to worry about setting the filters up in all the Red9 Ui's, they'll all just automatically pick up any MetaRigs in the scene and act appropriately.

Why, well with this setup it won't matter what rig you have, or how it's setup, this is just hidden data that binds up to anything you throw at it. It also means that via the api I'm doing you can just grab any controller in code in a very object oriented manner from the Python calls. So if you have a MetaRig node simply doing a dot complete on it will show you, and return all the controllers wired to it. It also means that all your code from that point on becomes completely generic.

From the Class Examples:

#MetaRigging!
#-----------------------------------------------------------
#This class is a wrapper of the main class aimed at managing 
#complex rigs and finding controllers. Simple concept, you 
#make a blank mRig node and just hook the controllers up to it.

import Red9_Meta as r9Meta
mRig=r9Meta.MetaRig()

#add all given nodes to the 'RigCtrl' msglink
mRig.addGenericCtrls(cmds.ls(sl=True))  
mRig.getRigCtrls()  //returns : all RigCtrls from above
 
#note that the default mClass connect will allow you to still 
#add a list of nodes to a specific msg attr.
mRig.connectChildren(cmds.ls(sl=True),'mirrorLeft')
 
#From a MayaNode return all connected mNodes as mClass objects
mNode=r9Meta.GetConnectedMeta(cmds.ls(sl=True))[0]
 
#The above is the most basic use. Wiring all given nodes to a 
#single attr, the issue here is to find a specific controller 
#from the list? So we have a singular Add function which binds 
#the given node to a single message attr, suffixed with 'CTRL_' 
 
mRig.addRigCtrl('MyMaya_Ctrl_Hips', 'Hips'))
mRig.CTRL_Hips  //return : MyMaya_Ctrl_Hips
 
#Note that because of the autofill on the object, once you
#have a mClass Rig object you'll get a list of all the hooked 
#Controllers (added by this method) on completion in the 
#scriptEditor. Whats more mRig.getRigCtrls() will still give you 
#a full list of them back.

Also I'm going to bind up some extra data to each controller thats added for the mirror setups that I'm working on.

Looking for testers if you fancy getting involved let me know!

Red

OOps

So I released v1.24 and forgot to patch the scriptEditor inspect for Maya2010 and 2013. Just patched the version on the download link.

Maya Script Editor - Code Inspector

This is a neat little bit of integration to the script editor's popup menu that's going into the latest build of the Red9 Pack, v1.24.
I've added a new menu item to the ScriptEditor RMB popup, "Red9_InspectFunction", which uses either the whatIs command for MEL or Python's inspect module to then lookup the source function file for the highlighted text, if found it will open up the mel or python module in the default editor on your system. Really handy for debugging!
Since this video I've also managed to get it to run from the history scroll as well as the editor itself which makes it even easier.

r9Meta been playing

Just a few simple ideas but it all seems to make sense. So rather than having to always have a specific node that we use for metadata, I've removed all of that so that any Maya node can be passed in and managed by the same baseclass. Also been playing with adding a flag that when the Maya node is passed and the Python object made, it automatically pushes all the attributes from that Maya node directly to the Python Object, why? Well it gives you full auto-completion for all attributes in the editors which lets face it, when you're dealing with a big shader or material is a godsend!

Red9 - MetaClass Initial Demo from Red on Vimeo.

r9MetaClass Vimeo demo

This is a brief demo of the initial Red9 MetaClass Python API aimed at managing and wrapping data to a Maya MetaNode system. All data is serialized to Maya network nodes so is stored with the scene. There's handling for JSON serializing of complex data and retrieving that data back in a very neat and simple Pythonic manner, getting the data back directly from the Maya node but in a completely seamless way.

This is just the initial fleshing out, the long term aim to to provide a generic method of managing complex Maya rig structures and marking data without you having to write your own API. So you'd make an mClass rig node and hook the rig up to that making retrieval of controllers etc a doddle!

http://red9-consultancy.blogspot.co.uk/search/label/Download

All comments very welcome

r9MetaClass : fleshing out a new Meta data system API

I'm just starting to flesh out a new python based metaData system for Maya, aimed at serializing complex data and managing systems in a more pythonic manner. The idea is that on a MayaNetwork node we handle all attribute calls (__getattribute__, __setattr__ , addAttr etc) and if needed serialize complex data such as dict/lists etc via JSON to a string attr. When you do a simple attr call to the metaClass it checks the MayaNode and if it's a JSON managed string, will give you back the complex data as it was, handling all the deserialization for you.

So from the class object you can do the following where 'complexAttr' is just a JSON serialized string attribute on the MayaNode itself

node.complexAttr['Meta']   
#deserialize attribute and from the returned dict give me the key value ['Meta']

It also manages connections via message links, all wrapped in the same pythonic manner. The same standard node.attr call to a message attr will give you back a list of connections to that msg attr itself.

There are a few other neat tricks in there too that I'm testing, although not yet sure of the best way to manage some of these, such as the r9Meta.GetMetaNodes() which will give you back not just the MayaMetaNodes, but those nodes initialized to the correct class object ready for use.

Anyway, I'm looking for testers and some ideas as to how to expand on this. Initially I was going to use it as part of a generic Rig marking system but kind of thinking it could go way further than that.

Mail me if you fancy a play with the API. It's also included in v1.24 of the studioPack, just cjeck the Download folder

Red

Big update v1.23 - New PoseManager

I've just updated the Download folder with the latest build StudioPack v1.23. As always just follow the Download tag on the right, I leave all builds in my Google Docs drive. This is a big update for the PoseManager system with a  new UI and new Thumbnail support. Lots of extra functionality on the RMB in the UI too. I've also modified the setups to hopefully run under OSX and Linux with the help of a few friends. As always and suggestions or bugs are more than welcome.

I'll update this link with a Vimeo demo I've just uploaded at some point soon

Red

Red9 StudioPack v1.22 : PoseUI more support added

I've been tinkering away and think I have the first version of the PoseSaver up and running. I'm still in the process of changing the TextScroll UI to include thumbnail previews but the rest of the code is now running. I'm looking for testers to help get this nailed! There's a growing RMB menu bound to each pose entry also

Download as usual on my GoogleDocs:

Red9 Download Folder

Release v1.21 - changes to the presets

I've just uploaded a new build with many changes to the way the presets are handled and stored. This will mean that if you currently have any custom presets that you've made they may not load up in this build. I've had to do this so that the Pose format and the generic filter format are in sync with each other. This also potentially means you could read the hierarchy filter from a pose file directly (not yet supported in the UI)

I've also added a config writer for the UI itself so that the main Hierarchy and Pose tabs are all stored out. This is cool as it also means that if you have 2 Maya sessions open, changing the AnimUI in one session will get reflected in the AnimUI once opened in the second session. Seems like a far more controlled way of doing things rather than using the Maya OptVars.

As always, all feedback is welcomed

As always, the Download folder is here, in google docs RMB and click the Download option!

Red9 Download folder

Red

Red9 StudioPack v1.20 - PoseSaver

Well I've been tinkering away for a while with this and wanted to push a test version out with the new PoseSaver implemented. At the moment the UI is pretty basic, just a textScroll with some RMB menuItems but as I get more into this I'll do the usual icon support etc that everybody expects from a PoseSaver.

So what's different about this one? Well like the rest of the Animation UI this one runs off the Hierarchy filters, so from the selected root the hierarchy's are filtered and that result passed onto the poseSaver. The active filter (whats in the Hierarchy tab) is also stored internally in the PoseFile so the code uses the filter as it was when stored to reload the data. Maybe as an option I let you over-ride this? Also lets you load on selected nodes rather than passing through the filter if you only want to load the pose to certain controllers.

As with everything this is namespace independent, the short name of the nodes are used as a key in the pose dict (although the long path is used for the compare). I also store the index of the items in the hierarchy so that in the future you'll be able to map on index rather than name.

Finally something that I'm working on is the ability to load the pose IN-PLACE. Currently like most pose savers the data is loaded as it was stored so the pose will load in the same space as before. Now this is great, but what if you wanted to load that pose when the character is halfway up the stairs? So in the next version hopefully you'll be able to select a reference node (something you know is in the posefile) and the code will apply the offset between where that node is now, and where it was stored to the rest of the data. Basically shifting it in world space on the fly.

Anyway, all comments welcomed as usual. If you'd like to get involved drop me a mail

For the latest version go to the Download page and grab v1.2

Red