Overview

Relevant Blog Posts

The Animation ReDirector system is something that we’ve wanted to do for many years, put simply it allows you to modify any animation via a motion path. It’s perfect for both VFX who may want to tweak the path an animation takes and games where it’s ideally suited for both cutscene work and in-game animation, giving you finite control of walks and blendspaces.

The key to this setup is that there is no connection between your character and our system, whilst we do create a motionPath, it only controls our internal data which we then cast back to your controls. There are 2 main modes, either re-directing your animation just based on a single pivot, or complete path based manipulation allowing you to tweak the path directly or via cluster controls.

The UI is complex as there are a lot of flags available to help you control the manner in which you setup the director path and how you cast that data back to your rig.

• Hierarchy control: This feeds in all presets from the StudioPack’s Animation Toolkit and the effect is exactly the same. The hierarchy preset controls how we find nodes in your setup, making it capable of redirecting any rig structure not just our MetaRig systems. You can set this preset up in the AnimationToolkit Hierarchy tab.
• Path options: Yes there are a lot of options here, all of which control the actual path and pivots created by the tool. We can control how the initial pivot point is extracted, whether the path is flattened down to the ground plane or tracks a given object. We can also control the number of CV’s built on the curve.
• Complex Path Adjustment: As it say in the label, this controls all the complex re-direction of the data allowing you to change the parameterization of the curve, add in control knots to make the curve easier to manipulate, blend your adjusted curve back to the original and straighten the curve automatically. Trust me, just watch the video!!
• Build buttons: We’ve tried to make things a little easier by guiding you through the process in the UI feedback. There are generally 3 steps to a redirect, firstly we build the raw guides, creating the path as a reference to your data. Secondly we cast your animation onto the nodes in our setup, caching / syncing the internal anim cloud. Once thats done you can modify the path as required. Finally when you’re happy you then cast the data back to your rig with the Apply button.

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Save

Overview

Relevant Blog Posts

The Animation Save/Load exposes our new animation format, designed from the ground up to be as flexible and feature rich as possible. Like our Pose format this allows us to load data in relative space, offsetting your animation in world space to match a selected node, a huge benefit when building up animation libraries. We also manage static, non-keyed attributes in the format as well as dealing with animation layers during the save process.

The format also integrates our timecode control systems, allowing start frames to be automatically calculated against a given rig, or audio nodes internal timecode.

• Hierarchy Preset: Like the Animation Re-Director this tool uses the hierarchy preset system, allowing it to work with any rig setup, or even just skeleton data.
• Save Options: Simple file prompt only but it’s worth noting that the animation format will automatically merge to memory any animLayers during the save. These will be restored after the save!
• Load StartTime: controls the frame that the animation data will be loaded from, this include options to offset your animation such that it loads and syncs to a given timecode reference.
• Load Nodes: control what object we load the data onto. More importantly we expose the “load relative too” option here which works like the pose saver, enabling us to load an animation in “relative world space” against a selected node.
• Load Timeline: what do we do with the Maya timeline after the load. This additionally controls the options for “Key Statics” which forces any static channel data in the file to also generate a keyframe, and blend range which culls a given range of frames front and back, blending the animation into current data.
• User Description: This allows us to add in a user description which is saved in the file, allowing notes to be passed around with the file.
• Internal Map: gives you feedback on the data before we load it, extracting the metaData from the file and giving you more details on what is about to happen.

MetaData Based Rigs:

When dealing with ProMeta based rigs such as our Red9 Puppet the codes going even further, storing not just animation curves but also collecting data from our exporter and audio systems to restore upon load. All of this functionality is expanded in the MetaNodes and wrapped for you making it a breeze to code around.

There’s been a ton of development since this first demo of the format (above ) however the base functionality is still the same. ProPack has also come on a long way since then and we’re now looking to offer ProPack to a wider audience! 😉

Dealing with Timecode!

As mentioned the animation format has full timecode handling internally, allowing data to be loaded and synced against a given source, be that a ProMeta rig with timecode or a BWav audio node. There are also tools in the ProPack to manage timecode on rigs and sync audio separately.

Overview:

The CharacterPicker relies on the Rig setup being bound to our Pro_MetaRig node setup, this was by design as the system uses the network wiring to find and expose the controllers. Without this abstract layer everything would have to be name based and that’s not a reliable way of finding data in large scenes. Because of the Meta Api wiring any custom rig to the setup is pretty straightforward but we’re always happy to help.

The CharacterPicker layout is totally flexible and editable, you can add or replace any number of buttons, including custom code based buttons and value sliders. The visual feedback in the UI is live, if you select controllers in the Maya viewport this will be reflected in the picker and visa versa. You can even drag select in the UI to select multiple controllers.

You can also add in any number of views to the Picker, by default we load the body and hand view but you can add or replace these, as well as add any image in the background. The data is bound to the mRig node, that means that each rig carries it’s own template for the picker and the UI is refreshed after any Rig is loaded.

Each click on the picker is also passed in with the Ctrl, Shift or Alt modifiers, allowing you to add / remove selections as well as select mRig Subsystems on mass.

Above are the 3 main modes for editing the current picker. The “Character Controls” selector exposes all controllers wired to the MetaRig not yet assigned to the picker, you just select from the UI to drop a new button in to the current view. The “Character Picker cmds” controls additional commands bound to each button, allowing you to modify the click command, bind more items to the RMB popup menuItems on the button, or control what happens when the sync function is called.

We’ve also added in a lot of the functionality of the Red9 Dag menus to the picker, exposing fast Pose management, IKFK matching and system resets, however all of this functionality is fully customizable if you’re not running the Red9 Puppet!

Overview:

The Red9 Puppet Rig and indeed any rigs that are bound to our Red9 Pro_MetaRig will create a custom RMB dag menu in Maya’s Viewport when you hover over a rig controller. These menu’s expose functions to speed up the animators workflows, giving them fast access to key systems such as resets, group keyers, system selections, ikfk management, visibility toggles, fast pose caching and timecode.

These menu’s are created and managed by the MRigs own internal dag function, bound to the class. Put simply it means that any rig can propagate its own set of bespoke menus. For example our base Pro_MetaRig class generates the menu you see above, however we also have facial sub classes and those create their own menus. This means a facial controller could expose functions for selecting eyes, brows etc all exposed by the rigs mNode.

Do we overload Maya’s dagMenuProc?

No, we’ve found a way to intercept Maya’s call to build its menu’s that doesn’t require any mel hacking. This means that if you have your own dagMenuProc code we do not interfere with it.

Overview:

The Red9 Browser on the surface looks like a simple file browser inside Maya, threaded for speed and with RMB click functionality, but don’t let looks fool you. This is an extremely powerful tool that allows you to have custom command execution on files of specific formats and a production proven batch system, flexible enough to handle the fast changing productions environments of today.

It’s been designed to allow you to easily hook your own functions to any file extension, allowing for quick and easy batching or patching of files on mass. More importantly it’s also the main interface through which we expose our Pro_To_BND call, our method of getting fbx data to map to the Red9 Puppet.

The Extensions Manager attached to the Browser is the heart of the tool, allowing you to add in your our functions and bind them to a specific file extension, either exposed when a single file of that type is selected, or when you have multiple files selected. You can also add in any additional file types as required.

Overview:

The Red9 Export Manager is designed to manage shots in the scene and expose those shots to the Run code. The actual functions exposed often change per client, tailoring them to fit specific pipeline requirements. For a number of clients this is their main game exporter interface, handling all outputs to engine.

By default we include flags to export fbx files from a rig, these are clean baked skeletal data, ideal for passing back to MotionBuilder as required. The r9Anim option generates our animation transfer file, perfect for building libraries of animation data up. The setup also exposes Perforce integration, adding all files generated to a clean changelist.

As well as base shot management the tool also includes AudioNode management, allowing you to attach audio to a character to denote what lines of dialog they are speaking.

All of shot data is stored in the r9Anim format and that allows us to maintain both the shots and the audio data when we load an r9Anim file. Imagine hooking up a cutscene with speech, being able to save the anim format and have that not just restore the animation, but also to re-load the shot markers and re-sync the dialog that was being spoken!

The crucial part of this is that each shot is a node in it’s own right, all managed by the MetaData API for ease of use. Because of this the setup requires rig to be connected to our Pro_MetaRig network as all the export loops are managed at the class level. The basis for this was the work done at Crytek when designing their export pipelines and explained in more detail in the Develop Conference talk done in 2014.

Overview:

We’ve worked really hard to bring you a set of timecode management tools which are unsurpassed, syncing body, facial and audio data is no longer guess work saving you weeks of work in production.

The Timecode Wrangler is the heart of the setups, designed to manage both audio and rigs bound to timecode and allowing you to re-sync data seamlessly. This is just a small part of the timecode management in the ProPack codebase. Audio must be in the BWav format the rigs must be bound to our Pro_MetaRig networks, again, this is easy to achieve without having to be tied exclusively to our PuppetRig (although we’d obviously like that!)

• Audio Offset Basic: this replicates the StudioPacks AudioOffset UI and simply allows you to move multiple blocks of audio around more efficiently.
• BWAV AudioTimecode: This allows you to sync audio back to it’s original internal timecode, or to sync it against a given node’s timecode by setting up a reference. This also respects the Maya “Production Timecode” mapping…. see below!
• mRig Timecode: This manages the timecode burnt onto a rig, allowing you to set the timecode in SMPTE or to simply copy timecode over from another rig in the scene. You can also manage connections to our HUD and see all the timecode in the Maya Viewport live!

The key to the tool is the way in which it extracts and uses the timecode, allowing audio to be synced with reference to a rig, or visa versa. The timecode data stamped onto a rig is also maintained and stored in the r9Anim format, allowing you to load animation from a library with reference to a given timecode!

We can pretty much time sync anything to anything automatically, allowing full performance moCap data to be synced without the worry of having to manually re-build scenes afterwards.

The Timecode Wrangle also exposes our Inspect tool, a simple click shows you all debug information on a piece of audio.

We also expose Timecode on the Timeslider, hooking into Maya’s hidden “production timecode” to allow us to remap the timecode shown to animators with ease. Here you’ll see we have a timecode of : 01:55:00:00 yet we’re still only at frame 240! This remapped timecode can also be passed in and used by all the sync tools.

Finally we also expose Timecode in the mRigs DAG menu’s, here exposing what rigs are connected to our timecode HUD in the viewports (seen in white at the top of the image). We can connect any or all rigs to this making it easy to check if all data is running in-sync!

Overview:

The Red9 Skin Saver is designed to give the technical artist a solid toolset for managing skin weight information inside Maya, saving and loading skin data in a robust manor.

Be confident enough to detach the skin from the skeleton and get the skins back just as you set them. Red9 skin saver stores the skin information one to one and the algorithm has several check statements to ensure the data is restore as expected, no messy maps or bodged workarounds. Data is stored per value and vertex id and that is what will you get back.

Extra Features.

• Selective load, able to load just a cluster of selected vertices or selected shapes. You may just want to load a portion of the data you stored, or separate the work between two or more colleges, collaborative skiing is made possible here.

• Skin debugging, this is especially important if your asset target is a game engine, we can ensure no vertex has more influences than your engine will support including dealing with any negative values hided in your asset. Make sure what you see in your viewport is what you see in your game!

• Remap skin data between joints, remap the skin from one joint to another or from multiple joints to a single joint, a good way to optimize skeletons or create asset LODS

The new Health Manager is deigned as a transparent way of checking, verifying and managing data within a Maya scene in a user friendly manner. This is managed by our HealthValidation Class, a simple wrapper class that contains test functions that you want to run within a given scope. The test are very simple Python functions which have to return a HealthStatus object that the UI then inspects. More importantly each test should ideally have a fix method bound to it.

The “Test_Rig_HealthValidation” text above was run on our production rig and you can see from the feedback just what failed in the scene, and all the exposed fixed methods. This is key as it lets TD’s easily design tests to validate external deliveries, rigs, animations, exporters or just general scene health, but all contained in a neat traffic light system.

Below is a snippet of one such test, this is our internal client delivery test, run whenever we get a new skinned character for rigging from a client. You can see how simply the class is setup, it’s just a subclass with an internal tests list containing tuples where the first argument is the test itself, the second is the expected returns from the tests. These are crucial and all of our publishing systems are based around this concept.

We’ve tried to make the API as simple and transparent as possible and it comes with a huge list of tests already available, all you need to do is create a new SubClass and add in the tests that you want that class to represent.

More info to follow!

Overview:

The ProPack API has a huge set of additional code features that we’ve exposed and wrapped to make the life of any TD using it easier.

importexport: This module controls all our file management and more importantly our SourceControl setups, including full Perforce integration.

optimizer: This module ties into our Health systems, a huge set of bespoke tests to keep your scenes clean. These also wrap into our HealthValidation framework, designed to validate assets against a given set of requirements.

project: The project module is booted and bound when Maya starts and is designed as a common object to hold all paths and relevant data at the client level.