Red9 ProPack: upgraded FK>IK matching systems and ParentSpace management added to ProPack

Delighted to be able to announce a massive upgrade in the way that we deal with FK>IK systems and ParentSpaces within the Red9 ProPack pipeline. Key to this is a new Spine matching algorithm that we've hooked up to the Red9 PuppetRig to give us a really solid match between FK and IK spine systems, something that always been very difficult to achieve.

Also added are upgrades to the Limb matching to deal with FK twist when switching over to IK, new toe rotate extraction and full management of our Auto-Clavicle setup withing the rig. This allows clients to animate with the solver on but always bake it back down to clean extracted rotate data.

 
 

On top of all of this we've added ParentSpace matching to the systems so now you really can mess with the world space of the rig and always push systems around to match over time.

All of the new features also include a new SmartBake setup such that data can be matched to current keys within the system rather than per frame baked data, perfect for clients hand-keying animation rather than moCap data.

As always check-out our other updates on the news feed of our website or on our Vimeo Channel

thanks

Mark

MetaData Develop Conference Talk notes

http://www.developconference.com/seminar/Coding-a-Maya-production-pipeline-with-MetaData

The talk went well, and I promised I'd make these available so here the links. The PowerPoint has notes on it that I used to remind me but hopefully you'll also find them useful too. The videos that I showed during the talk are also now on Vimeo (just got one more to upload) I recorded these in the studio so they're a bit noisy, they were only intended to be used a video tracks to talk over, but I think they might help if you have the ppt next to you.

So, PowerPoint is here:   Power Point: MetaData in a Maya Production Pipeline

Videos:

Video 1: MetaData Attribute Handlers
Video 2: MetaData - MetaRig

Video 3: MetaData - MetaFacial in the Crytek Pipelines To follow:

Hopefully you'll find these useful, mail me if you have any questions about the talk, or Red9

thanks

Mark

Develop Conference - MetaData Coding in a Maya Production Pipeline

Develop Conference Talk

 I'm going to be doing a talk at Develop Conference in Brighton this year, going through how we've integrated the Red9 MetaData API into our production pipelines at Crytek. I'm in the middle of writing the talk and figuring out how much detail to go into.

The conference is happening 8-10 July and the early bird discount prices end soon.

http://www.developconference.com/Content/Develop-2014

Here's what I'm planning on, but if any of you out there are running MetaData I'd love your input too:

This talk will go through the benefits of integrating MetaData concepts in a Maya production pipeline. Red9 Metadata is Python API, part of the Red9 StudioTools, an open source toolkit freely available on the Autodesk Exchange website and authored by myself.

 In this talk I'll be showing how we've integrated this concept to all aspects of the Crytek Maya animation pipeline. Meta is used in our animation rigs as a separate schema / network to manage data, binding tools to the systems via a generic layer. It's used in our facial systems to manage relationships in code, breaking a complex system into manageable and logical chunks. We also use meta as the entry point for our exporter, the idea of connecting characters to export nodes which in turn connect to time and settings nodes.

Topics:

• The background, why? 
• The basics of the MetaData Api base class, what does it do and what benefits does it give us. 
• Basics of metaData internal attribute handling and auto-complete. 
• Factory class aspects, the core of the systems, walking nodes as classes. 
• Using Maya nodes as class representations to structure your code. 
• Class inheritance and attribute binding. 
• Practical examples in production. 
• Generic nature of metadata, how it lends itself to tool pipelines. 
• Subclassing, how's it's been heavily subclassed and expanded by the Morpheus2 project. 

See you there!

cheers

Mark

Coding a Maya Production Pipeline with MetaData

http://www.developconference.com/

Heads up.. I'm going to be doing a presentation at Develop in Brighton this year about how to utilize Red9Meta in a production pipeline, running through some internal examples of the tools and Maya dag structures that we're currently working on at Crytek. 

This will be an overview really, how and why metaData helps not just in constructing complex setups, everything from Exporter, Facial and Rigging pipelines, but also as a light coding api to deal more seamlessly with nodes in Maya.

For all of those doing the Rigging Dojo Character Engineering course, might be a good chance to catchup.

More details to follow but if there's anything in particular that you'd like me to include drop me a mail. 

cheers

Mark

Red9 Sound and Audio handler updates

Finally got round to doing a quick demo of the new AudioNode handler in the Red9 StudioPack. This one shows how you can use the 'compile' function in the sound menu to pre-compile multiple sound nodes in Maya so that you get a complete soundtrack to any playblasts. Anybody who's ever tried animating to multiple sound nodes in Maya, particularly when animating dialog will know how frustrating it is when you then try and playbladt that scene, and only get 1 sound track included!!

I also go through the new inspect code, capable of extracting metaData info from wav files including full support for Broadcast wav's. This is really useful to gain access to thiongs like internal timecode data. There's also extensions capable of extracting metaData from any media format, Mov, avi etc but for that you have to download ffmeg which I use in the inspect call.

I'm really keen to hear from those running MacOs or Linux, does the compiler work for you?

thanks (don't forget the donate button...cough...)

Mark

Red9 MetaData Part 4!!!!

At last!!!!

This one's a long time coming and requested by lots of people so... here it is, hope to god it makes sense!

Last part in the MetaData series, this one delves deep into subClassing Red9_Meta in your own classes. It goes through how to register those classes to Red9Meta registry, pointers as to what to overload, and the crucial __bindData__ func that controls how, and what attrs get initialized on the class node when it's created.

This hopefully completes the MetaData series, 4 long videos where I try and explain the concept and functions behind the Red9 MetaData api. If you've not already watched the first 3 parts check them out on Vimeo.

As usual please feel free to ask if you have any questions or want any pointers. There's a TON of stuff in there under the hood!

cheers

Mark

MetaHUD - Monitoring any attrs in the Maya viewport - ChannelBox integration

And another Vimeo!

This one goes through the MetaHud node integration that's now on the popup menu in the ChannelBox. Really useful for debugging setups and monitoring data inside your rigs. The idea is really simple, it's makes a simple metaNode who's attributes are all monitored, all I do is add attrs to that node and connect those attrs up to the data I want them to monitor. Because it's a node you can wire this up to your rig and have it live there, monitoring any data you may need when debugging.

Still work in progress so any suggestions are more than welcome!

cheers
Mark

Red9 MetaData Part3

Red9 MetaData Part 3! 

Third part in the MetaData series, this one starts to show you how to wire up a rig with the metaData backend

Any questions let me know

Mark

Red9 MetaData Video Part2

Second installment of the MetaData API demo's.

This one gives you an overview of the factory aspect of meta, how it can be used to walk systems and how the attribute handlers are designed to return python objects rather than just Maya nodes.

I'll follow this up with a more detailed breakdown of the metaRig class and handlers, plus more code detail. 

Any questions drop me a mail

cheers

Mark

Red9 MetaData API - Vimeo Part1

Red9 MetaData API Part1: 

This is the first of what will be a series of videos that go through the MetaData API concepts in Red9. This first demo goes into the attribute management of the class, how it can be used to easily manage, add, set and get any attr for any node inside Maya in a completely seamless Python manor.  The next few videos will delve into the more complex network structures designed with MetaRig and go through the factory class aspects of the api. The last in the series will show you how to subclass Meta for your own usage and why you'd want to..

Any questions fire away

cheers

Mark

MetaData....the what and the why?

Before I go and do a new set of Vimeo vid's on the MetaClass API in Red9 I thought I'd go through a few of the basics. This is kind of triggered from a few mails I've had from people asking what the concept behind the MetaData API is and how it might benefit them. MetaData is nothing more than an API, how you use it is down to you...

Part1 -The Factory:

So in a nut shell, it's a factory class with very careful over-loading of some of the key Python calls. The factory stuff really isn't that complex. It's one of those concepts that sounds hard but actually it's really simple. The idea with mine is that any Maya node with an 'mClass' attribute on it, where that attr value matches a pre-registered class, will return that class in all the get() calls in the api ..... example:

• 'myNode' has an attribute called 'mClass' who's value is 'metaRig' 
• 'metaRig' is a registered class that inherits from r9Meta.MetaClass 
• metaRig class is automatically registered to the systems by an internal function that maps all inheritances from MetaClass r9Meta.registerMClassInheritanceMapping()  

The factory part of meta goes like this:

• r9Meta.getMetaNodes() or r9Meta.getConnectedMetaNodes() will look first for nodes that have the mClass attribute on them. The search is clamped to registered nodeTypes managed by a call that can be run to register any nodeType to the systems so you can expand as needed.
• resulting nodes are passed in to the __new__() of MetaClass 
• the mClass attr 'metaRig' is matched to the registered class 
• that class is instantiated and returned back to you 

So what???????? Well imagine you do getMetaNodes() on your rig scene that has an mRig node 

mRig=r9meta.getMetaNodes(cmds.ls(sl=True)[0])[0] 

 Now mRig is a class object of type 'metaRig' and that is a subclass of Meta so has all the attribute handlers available. Basically that Maya node is now bound to a given class like Pymel does, you do pm.selected() on a transform you get back a pymel.Transform class object, you do the same on a light....etc. Well in the same way MetaClass does the same for any Maya nodes. More importantly by subclassing MetaClass you can bind your own classes up to your own nodes in any system.

So lets quickly look at the metaRig setup in the Red9 unitTests:

#cast the MayaNode to a metaRig object
mRig=r9Meta.MetaClass('RED_Rig')
assert mRig.L_ArmSystem.L_ArmSupport.mNode=='L_ArmSupport'
assert mRig.L_ArmSystem.L_ArmSupport.SUP_IKHandle[0]=='|World_Ctrl|L_Wrist_Ctrl|ikHandle1'

Note here that I can just use dot complete to actually walk the metaRig network. This is because by getting the attribute of type message the code looks at the linked nodes, if they too have the mClass attr they are returned as python metaClass objects too, so you can just keep walking down the tree. This makes finding nodes in complex systems like rigs an absolute doddle.

Part2 -Attribute Handlers:

So above we saw that metaClass gives you the ability to turn any Maya node into a class bound to that node, so what? Well in the rigs case it means that we can get data dead easily. This is because I've also very carefully managed all attribute calls via the MetaClass api. In doing the mRig.L_ArmSystem call above the code first tests the type of attribute, in this case a message, and uses the listConnections call to get back the data.

The attribute handlers in Meta seamlessly deal with getAttr, setAttr and addAttr, in fact addAttr manages all the flags for you, you can even add the attr without telling it the type, I derive it from the value you pass in if I can. Also you can pass ANY node into the MetaClass api, the node doesn't have to take advantage of the factory stuff, you can just use it as an attribute handler if you like. 
Hint: When a node is passed into MetaClass all attributes show on the dot-compete in the script editor ;).

Currently I support:

• floats 
• doubles
• ints
• bools
• strings    ( automatically serializes and deserializes to JSON if the value is complex)
• enums    ( allows you to set the data via the int or string representation )
• message ( get runs listConnections, returning mClass objects if found, set will automatically connect)
• doubleArrays (sets the structures up for you when adding)
• double3
• float3 

Even better, and here's where it gets fun, if you pass a python dict, or complex structure to a string attr, it's serialized and stored via JSON for you. Here at work we store our zero pose, generated by the
poseSaver, actually on the mRig node itself as a json string. Same way that the SceneReview serializing all the comment data from an internal dict straight to the 'time1' node in Maya. The AttrMap is also doing this when you serializeToNode.

Part3 - The Big One!

 The big one though is this..... any node in Maya that has the mClass attr, that is valid, will give you back the correct class automatically! You don't have to worry about what class to call, what function is in what class and if node==this do that, elif to this.... the node comes back as the correct Python object ready for you without any work. There is a direct correlation between the MayaNode and the class that manages it, like Pymel all the functions you may need, code in the class for that node. It keeps code clean and means that by subclassing you get all functionality for all similar node types for free, and get access to all the core stuff in Meta....which is expanding fast.

I've added a ton of hooks in there recently as I've been working with Josh Burton on the new Morpheus project. These all allow you to sub-class and register new types a lot easier. Most of the code we now write at work is based on Meta, either because it's so easy to get data and attributes back, or because we have many nodes for many reasons, facialRig, supportNodes, exportTags managing systems....

Hope that helps a little?

Have a read of the unitTests and examples folders in the Red9 pack, they're there for a reason and might shed some light on all of this ;)

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

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

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

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

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

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