Rigging/Scripting - Autorig Catch Up
One of the main projects I’ve worked on over the years is my custom autorig solution in Maya. When I worked for a University animation program, I was at the head of the rigging department for film production. They had their own scripts that build all of the rigs modularly using Python. I am attracted to the approach of modular rigging, something often discussed in professional circles for character pipelines. However, I thought it was a miss that there was no UI support for students that may not have as strong of a Computer Science background to leverage the tools.
This was the initial basis for why I wanted to try to make it myself. Not only making smart, reusable rigs that could fit any creature type, but also make it user friendly so that Artists and TD’s alike would be able to understand the process.
In the free time that I did have in the last few months, I’ve been researching and developing my newest pipeline for my character rigs. In this post, I’m covering the three main iterations of this system I’ve gone through, the third being the foundation that I’m currently building my tools around.
#1 A Simple One-Directional Pipeline Approach
This was the first version I built when I was working on the rig for the Cheetah project. At a basic level, if you had something like an biped arm you wanted to build, you would make a three joint chain heirarchy and input the name of the top level joint. The script would read that hierarchy and then build out the basic systems like FK, IK, Stretch, etc. and you would continue on to each body part from there. There was then a tab that would find the existing module parts in the scene and use Python functions to parent them together. Finally, you would go to the shape tab and generate the default control shapes.
Main Issues: This was one of the first UIs that I made with Pyside2, and I generally find it to be unclear in what is clickable or selected. It takes up way too much space and would be hard to scale to other creatures. Taking all the buttons under each creature section and putting them under dropdown menus would remove the clutter for creature types that are not currently relevant to your project. Also, despite there being separate tabs for system tagging, connecting module parts, and making custom shapes, all of these boiled down to being one click operations with no customization, so the “Make” button should have done all three.
The most crucial issue is that I was designing these scripts without considering a bi-directional pipeline. Discussed by Dave Hunt in his GDC presentation, it’s basically guaranteed that the needs of a rig will change in a project, and therefore tools to automate the pipeline should be as reversible as possible. Anytime I wanted to make a change to a rig, I had to delete everything my tool created manually, and the code for the new feature, and then trial and error test it over and over, wasting more time than just doing the rig by hand would have taken.
#2 Name-Based Modules
This next iteration I took much further, where rigs built with my system would be compatible with tools further town the line, like IK FK matching and animation exporter/bake tools. This would allow me to take an animation on the full control rig version of the character and apply it bake onto the joints with a custom animation transfer tool. There is much more freedom in the systems that could be applied, and this would be written out to a .txt file as a function call with parameters determined by the widget settings here. When you load file, it runs the .txt as a python file that was written with this layer of UI abstraction.
Main issues: As with the first approach, I was relying too heavily on the names of the nodes involved. This requires a lot of heavy lifting on the user’s part, and names are fragile since they are easily changeable in the outliner. In order to safegaurd that it would take a significant amount of error catching that would need updating with every new module.
Writing out to a text file allows rigs to be edited and regenerated without messing around with the UI, but the .txt file could be messed up if it was accessed directly, and .txt files aren’t exactly great for protecting formatting. It also adds extra directory bloat, since I was also using .txt files for the animation exporter as well.
This is a better push towards a bi-directional solution since aspects of modules can be edited and regenerated on the fly. It could be further expanded on to allow animation “unbaking,” since I was already exploring how to reverse IK keyframes when making my FK/IK matching tools. I used this system for around a year.
#3 Current Solution
My current version aims to right all the issues I’ve had with my other tools that have made using them sometimes as tedious as using manual methods. Most of the rigging is now handled by custom attributes that are locked down and only editable with the UI. Now, naming doesn’t matter (for the user) because the scripts can regenerate names if they need them by concatenating various given parameters. A major goal of this version is to completely integrate the bi-directional pipeline idea, allowing a rig to go all the way from joints to exported animation, and then all the way back to catch any updates to skeleton, systems, or skin weights.
On that note, something that I haven’t yet built significant tools for is skin weighting, which is the other half of the rigging equation. While this project was initially an exercise in making an auto control rig, it is quickly expanding to handling an entire pipeline.
I also want to take this opportunity to explore and profile the heaviness of different rig approaches, namely native constraints, matrix nodes, and full C++ implementation. It is my ultimate goal for each component like an arm to be folded into its own custom node, where users can connect the shapes they want to use for their rig and alter systems based on node parameters.
Something that is being discussed by some rigging professionals like Raffaele Fragapane at Cult of Rig and Raf Anzovin at Notional Pipe is the idea of rigs as software. Since I’m already considering a Biped Arm its own class in my scripting, why not think of its existence in Maya the same way? I should be choosy in what data is allowed to enter and leave the scope of a body part, which will make connecting them to the larger rig system much cleaner.
In the short term I will be diving into making an arm rig, exploring all of the techniques and approaches out there, and then scripting which one I find works the best in my systems. I want to take this single module and all the tools around it as far as I can, and then apply them to other body parts that can be quickly generated with my tools.
