Bottom-up rigging approach & Decoupling rigs

The general approach for rigging a character is to start building skeleton, define how it will move (control system) and then dive into deformation(enveloping process). This approach assumes that the target bind skeleton driven by the control rig is going to produce good deformation. Usually one should do some deformation tests first to make sure bind skeleton would deform the character nicely and then build the control rig. However if this is not done thoughtfully then you could get stuck with a rig that does not deform well. Of course we have tools at our disposal to correct the deformation if required, however this could significantly lengthen the skinning process and make it tedious.

Another approach is to start thinking about deformation and do the skinning first then build its control rig. I am working on a realistic character model for studying deformation based on musculature. Hence the focus is on getting the deformation looking as good as possible. The first stage is to built the bind skeleton and add most of the secondary deformation joints along with the enveloping process. This should give a better idea of how the skeleton would deform the mesh. We can go on refining the bind skeleton and deformation weights until we get a solid base. My goal here is actually go get the skinning closer to the final look and hook up the control rig afterwards that is created based on the bind skeleton.

Regardless of the approach we take, the goal should be to be able to focus on both deformation and control rigs while keeping them independent processes. By keeping control rig and deformation rig separate we can focus on one task without worrying about the other and work on them in parallel. Generally there will be some dependency between both rigs, for example matching the pivots for the movement and deformation or a joint driven by a surface that is deforming the mesh . But we can still decouple both the systems to a good extent. Also, it is possible to keep the pose based deformation independent of control rig reducing the coupling further.

In programming it's a good practice to keep the objects of the system independent so that changing one does not require to change the others. This is highly applicable to Rigging as well. If you are more into programming you should read Design Patterns by the Gang of Four. It's an excellent read.

Rigenerator: Rules Based Graph Traversal

It is not very difficult to traverse the whole graph in Maya and make a data structure to be able to analyze it. In "Rigenerator" I can select one node in the outliner and I am able to get all the nodes related to it in anyway possible. The next step I want to add is to be able to specify rules in the graph traversal algorithm so that I can restrict the network within the specified hierarchy. This is so that my "Rigenerator" tool can extract only a part of the rig.

My goal is to come up with some kind of short hand notation for specifying these rules. I am trying to come up with different possible scenarios to be able to generalize these rules. So for example, I can specify levels and combine it with a node type(s) and their relationships with the source node. This is just theory and hopefully I can find some way to implement this idea.

Rigenerator: Rig Code Generator, Milestone 1

Rigenerator is one of the toolsets from my modular rigging framework (which is still in very very early stage). My goal with this tool is to help riggers speed up the coding and modularizing of the rig components. This can also be used for copying, mirroring rigs of any kind. The first step for this tool is to generate the raw code which is the same as .MA file commands. There are some very useful functions in API to generate a lot of code directly (e.g. setAttr commands for given plug, check MPlug class). You can check an example plugin called MA exporter in devkit. Later based on this raw code this tool allows to organize it and add modularity.

In my previous planning, I wanted to work on this tool at a later stage. But, since I have to create many rig parts for the framework, I thought I would actually finish Rigenerator first. So I can create rigs in different ways and whichever I find the best, I can convert it into code using this tool. This will speed up the coding process for my rigs.

I have reached the first Milestone for this module. I am able to generate the raw commands to regenerate the rigs. I have planned many features for this tool which includes, mirroring, code analysis/modification, dg graph inclusion/exclusion options, mel or python options,  etc. I will post more on this as I make some progress.

Modular Rigging System : Goals

As I have started writing my modular rigging system, I am constantly thinking about the main goals. I feel that at each stage as I put a concept on paper or write code that should satisfy the main goals. After a lot of thinking I have decided on the following goals,

1. One should be to be able to change/extend pretty much everything in the system
2. All the parts of the system should be as much independent as possible
3. Whenever possible not be specific to Maya 
4. Editable template/skeleton/rig at any stage

So any module that I create can be changed or replaced. This will create very minimal core modules. We are not really defining the logic of rigging in the core modules. I think the core modules define the concept of modular rigging. And the modules that has some common logic for rigging are defined in core utility modules. Hence the core system modules represent only the idea of the modular rigging system.

Rigging modules should not be constrained to a personal workflow.
Example:
In general, there is a template system that lets us define blueprint of the rig and then we create joints and rig on top of it. So roughly there are three parts to this system, locators(guides), joints(skeleton), rig(controls). But,
what if I already have my joint chains created manually? What if I have my own guide system? or I want to change the way animation controls are aligned or created? etc...

There is really no right or wrong way to do things here. But I am doing my planning based on what I think a modular system should be.