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