Red9 ProPack continues to grow from strength to strength

With GDC in full swing we thought it a good time to go through some of the recent features of our Red9 ProPack pipeline. ProPack is available in both nodelocked and floating studio license, supporting multiple projects with full Perforce backend support.

ProPack continues to grow from strength to strength, we've been working really hard with some key clients recently on some major new features and we're hearing from more and more studios looking for solid solutions for their animation needs. We can generally take a client from having no rig or pipeline to fully setup within a matter of weeks and that also includes facial rigs and data!




ART Rig Support:
Firstly the latest build of ProPack includes full integration for the Unreal ART Rig, allowing you to hook ProPack systems directly to the rig as if it were a native Red9 Puppet. This is a big advantage to anybody wanting a complex workflow over and above the base systems of the Unreal Art Toolkit.

ART Rig - Read More




Animation ReDirector:
The Re-Director has always been a big part of the ProPack but in the latest builds this is now an interactive tool, allowing for instant feedback and re-pathing of your complex animation data. 

Animation ReDirector - Read More




Rig Manager: 
This bridges the gap between any external Maya rigs and our ProPack metadata systems, allowing for fast binding to the underlying node setups and exposing all the tools with a few clicks.  This is particularly powerful when bound to facial rigs as it also then exposes all of our imageplane and camera management specifically aimed at facial animators.

Rig Manager - Read More




Red9 PuppetRig: 
Our PuppetRig continues to develop along with the toolsets that manage it. This latest version includes a new iterative FK>IK spine fitting system, designed to resolve the issue of poorly fitting ik spline fit to fk data. The iterative fit works a little like a secondary ik solver, trying to best fit the systems.

Red9 PuppetRig updates - Read More




Dynamic Timecode: 
Finally we'd like to introduce you to our dynamic timecode systems, designed to allow for seamless syncing of data from performance capture to final sequence, managing body, facial and audio data inside Maya, none destructive and fully integrated into the entire ProPack pipeline. This system was built alongside CloudImperium games to help them handle their massive moCap needs..

Dynamic Timecode - Read More


More to come including our powerful custom exporter systems aimed at taming your outputs to engine!

For more information don't forget to contact us!!

Red9 ProPack: Project and Perforce Handling

Red9 Consultancy Link

In this demo we go through our new Project Handlers, expose newly upgraded Perforce Integration and go through our r9File class object for all TDs out there wanting an easy life.

 This is a hugely important concept for anybody running ProPack, especially within a large studio environment, if you’ve got a demo build of ProPack please ensure you watch at least the first 5 minutes of this video as its a CRUCIAL concept within the pipeline!

 The Project Handlers manage all aspects of our systems, anything that requires a variable, a path, a class binding or a settings file they all inspect this system, allowing dependencies to be dynamically changed by simply switching the project mount.

 More importantly the system now has deep Perforce integration, managing both server and workspace connection per project. Perforce is also exposed within the Red9 Browser, allowing you to seamlessly browser through your full P4 repository directly within Maya with options to checkout, revert, sync, add etc ..

 Finally we go through the r9File handler, a high level file object that binds all of the project systems together, exposing both P4 handling and base OS management in a really simple python object for all TDs to use.

Please connect us for more details

Red9 ProPack – Butterworth Filter – Animation Re-Sampling on Steroids!

Read More Here

Coming Very Soon!!!

This is a huge new feature for any animators dealing with dense baked data. The Red9 StudioPack already has an interactive curve filter to deal with re-sampling animation curves but soon the ProPack will be getting an all new Butterworth algorithm, one of the main filter methods from MotionBuilder for cleaning up noisy data.

The Butterworth filter is actually derived from an audio filter so is superb at taking noise out and re-sampling animation data, we’ve taken this method and wrapped it into a neat, interactive tool inside Maya.

This will save anybody dealing with MoCap or facial data a massive amount of production time!!

Cheers, and don't forget to link to the "News" section of our new web-site for more updates on Red9

thanks

Mark

New Red9 Website!

Well we finally launched our new website and as part of that we have a new blog which will become our main point of reference from now on. This blog will still be active but mainly just for more random mutterings.

The new site also has a ton of details regarding the ProPack toolset, overviews of the key features and projects that we've been involved in.

red9consultancy.com

thanks

Mark

Red9 ProPack : Animation Re-Director Update

I wanted to share this huge update to the Animation Re-Direction system in the Red9 ProPack. This new setup has been driven largely by the needs of one of our clients dealing with mass MoCap and needing to straighten out data shot in a tight volume, a really tough thing to do without a tool like this.

The new setup not only keeps all the power of the previous setups, allowing us to direct animations via curves, shaping animations, but also now un-wrap animation data.



As usual if anybody has any questions or is interested in talking about this or our ProPack pipeline drop me a mail!

Many thanks

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

CameraTracker Vimeo

New CameraTracker Vimeo added, this is a really simple but useful little function for isolating motion when animating by tracking selected nodes with the current camera. This is going into the next release which will be in the next week or so, it's in testing at the moment.

Something I missed off was that the timerange the tracker uses is the same as all the other Red9 functions, either the current playback range OR your selected frameRange, highlighted in Red on the timeline.

cheers

Mark

New Features Coming soon!!

Well I've been busy over the last few nights trying to get a ton of updates into the pack.

PoseSaver now supports SubFolders:

SubFolders will switch the UI to display all child folders from the current PosePath, ie, PosePath/subFolders, selecting any of these will switch the UI to show poses in the chosen subFolder. I've clamped it to a single child folder as I really didn't want this UI to get out of hand. I guess it could expand with double click and single click commands but let's see how we get on. The Clear button will clear the subFolder text and thus return you to the root folder poses.

CameraTracker:

Also added is a tool that I used to death at Eurocom, an automated cameraTracker. This is great for moCap deliveries as it means you can just select a controller, or mesh and have the camera track the motion, saves continually shifting cameras to see deliveries. It's also great for seeing things like walk and run loops on the spot or aiming in on facial.

Working process: you select something for the tracker to aim at and choose either panning or tracking camera. The code will use the current camera in the current modelling panel and track the selected over time. As with all the Red9 code timeRange is either the current playback timerange, OR the area in the timeslider highlighted in Red. Tracking moves the camera, panning leaves it where it is and just aims at. This is a really simple bit of code, all it's doing is hacking into Maya's viewFit calls, the same thing you do when you hit the 'F' key. The option box lets you set the framestep used between samples.

Code Cleanups:

The AnimationFunctions class now takes a matchMethod arg which switches how nodes are matched during node processing. By default when it tries matching nodes in 2 hierarchy it allows prefixes, so SID_L_Wrist will match L_Wrist. I do a test to see if either name ends with the other, if it does it's considered a match. Now this can fall down if you have similarly named nodes in a hiererchy, like in facial you may have L_LowerLip and L_LowerLip_f, now these technically in the current setting will clash and may give unwanted results. So the arg flag is there to modify this. I've not yet exposed it to the UI but may add a settings optionBox in there somewhere to allow you to modify this flag.

 Note: the PoseSaver code already uses a more precise node match.

This new build is in testing at the moment

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

LockChannlesUI and AttrMaps

Another Vimeo video! This one goes through the LockChannelsUI which is fairly self explanatory hopefully. It also covers the concept of the AttrMap which for riggers is a godsend, a way of storing out the status of every channel in a hierarchy and restoring it when needed. The attrMap can be stored to file OR serialized to a node on the rig itself!

 

cheers

Mark

Red9 Studio Pack v1.28 Released - MirrorSetups

Just a quick note to say that I've just updated the download lists to the latest build v1.28. See previous posts about the updates.

I've also added a new MirrorSetup UI for setting up the Mirror Markers and added a Vimeo demo of the setup.

 

 Enjoy!

Mark

SceneRestoreContext context manager for your viewports

Thought I'd breifly go through the SceneRestoreContext manager in the Red9.General module as it's something that came up today at work. So what is it, well it's a context manager that 's designed to store, and restore all your viewport settings including:

• all viewport display options and shading states(for all 4 modelPanels)
• playbackOptions including units, times, timeranges and settings 
• scene units
• current audio set in the timeline and it's active state
• current main camera settings (tranforms)
• cameras active in all the modelPanels 

Basically just about everything there is that makes that current session look as it does. Why?? Well sometimes when you're processing data you want to do things to the scene which you really want to restore afterwards. Lets say you're batching a ton of anim data, opening files, switching cameras etc and at the end of processing you want the scene to be set back to how it was. Now this isn't a scene load, this is a cache of all the main ui element settings.

This can be run in 2 ways, the best is to use it as designed, as a context manager:

import Red9_General as r9Gen
with r9Gen.SceneRestoreContext:
    do your code here

Now anybody who's used context managers in Python will get the syntax here. The 'with' is doing all the work for you. On entering the call it runs the internal __enter__ call, then runs everything inside the tab (your code), then when complete runs the internal __exit__ call. The great thing about context managers is that even if your code bombs, the __exit__ will still get called and the scene restored to it's cached state.

You can of course use it as you want, so you can take an instance of the object, run the store then when you need to, run the restore:

store=r9General.SceneRestoreContext()
store.storeSettings()

do your code here

store.restoreSettings()

it's just a function call at the end of the day and might prove useful to others whilst designing tools. If you find anything that you think this is not catching let me know. There's also an AnimationContext thats used in all the animation tools and a HIKContext for managing the set state of HIK rig nodes.

cheers

Mark

Another Video, this one explains the filterHierarchy

 And another video, this one follows on from the AnimationUI demo and takes you through the crucial filterHierarchy control in Tab2. This shows you how to tailor the systems for your rig, how to search for specific nodes in a hierarchy and how to setup the filter priorities list.

One thing I didn't run through was how to tweak the filter once saved by RMB clicking on the newly saved preset and opening up the cfg file itself. You'll notice for example in the Morpheus preset that the name search had regex clamps on the list, these were just manually edited after I'd made filter to ensure that the name pattern search didn't include namespaces and was clamped to the end of the string name.... see regex explanations, here's a great reference:

http://docs.activestate.com/komodo/4.4/regex-intro.html

cheers

 Mark

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

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

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

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