Since apparently 2020 will be the year for a lot of improvements regarding rigging and animation, I figured I would make this proposal right now to hopefully gather some feedback and discussion early on.
Introduction
Right now most applications, Blender included, let you rig by creating objects, parenting and constraining them. While this gets the job done this requires a lot of surrounding custom tools which often times limit the riggers in a strict workflow.
A lot of studios end up developing or using Autorigs which often offer a component based workflow.
Autorigs offer a few strong points:
- Consistency between all the rigs in a given production Which in turns offers a few benefits:
- Easy to share animation between assets
- Minimize the room for errors while updating a rig (control names will be the same, behavior will be the same, etc.)
- Much faster workflow since the actual rigging is pretty much abstracted entirely from the rigger.
- Ability to quickly add new components to a rig. Want a character with 4 arms? 2 heads? it’s possible
However, in my experience, autorigs also come with caveats:
- They take the rig out of the rigger’s hand and lock him into making a rig that the autorig can make. If you need some custom behavior, you probably will need to make that a new component of the autorig or include that in a script that will be run once the rig is done building.
- Maintaining an autorig takes time and effort (My last job was being the full time maintainer of the an autorig for a year)
A workflow like that that is so widely used should, in my opinion, be part of the 3D Applications rather than be external tools.
Proposal
First things first a nodal view of the rig makes the most sense to me. With “Everything Nodes” coming, I’ll assume that this is the direction that Blender will take for rigging.
What I’m proposing is:
1. Rig Components.
In my mind, a rig component is nothing more than a node group, very similar to what the shader editor offers:
- You can expose internal data as inputs and outputs of the group.
- A component can be as complex or simple as you want it to be. here are a few examples of components I have in mind:
- arm, leg, spine, etc.
- A complete character rig.
- A chain with IK/FK switching.
- A simple bendy bone with drivers on each.
- They can be “instantiated” or duplicated. Modifying the original component should ideally be reflected to its instances, if the users wants that.
- They can be nested.
- The Complete character component would only be composed of arm, leg, spine components.
- An arm (or leg) component would be composed of:
- An IK/FK switch component.
- A bendy bone component for the upper arm and another one for the lower arm.
With the asset manager coming up, I think it would be really great to be able to quickly import components in any blender scene.
2. A sprinkle of proceduralism.
Let’s have a few examples of what I have in mind:
- You have your bendy bone component but you want that to be used in a game engine. You need a bone per bendy bone segment. The segment count would be exposed on your BBone component and when updated, blender would automatically create (or delete) deform bones and constrain them to the proper BBone segment via a Copy Transform constraint.
- You have an FK Chain Setup that has a “Chain Length” attribute. Just like with the previous example, this needs to create/delete bones based on the attribute.
You could also have a Bool attribute that if checked would add a BBone component on each of the FK bone.
3. Implement some constraint in the edit mode of the armature.
This would add the possibility to create Guide Bones that would drive the rest of the armature without the user having to move every single bone manually.
The edit mode constraints should not be related to the dependency graph outside of edit mode. It would be it’s own independent little thing that would absolutely not slow down the rigs in any way.
This would work really well in a component based workflow as component authors could expose the guide bones and hide the rest of the setup to the user, making it really simple and fast to add new component to your rig, even if the proportions are widely different from the original component.
I’m actually working on an addon that does exactly that. Being written in python, there are performance issues but you can see it as a proof of concept: GitHub - HolisticCoders/edit-bone-constraint: Add Constraints in an armature's edit mode to easily modify its rest pose
It basically implements a few constraints and a simple dependency graph that gets evaluated only while you’re in the edit mode of an armature.
On top of all of that, Blender could probably ship with its own curated components that non-rigger users could quickly use, letting them work on what matters to them.
Notes
I have purposefully not put much thought in the actual implementation (especially for the procedural part), just the end user experience.
My experience with rigging in Blender is still very limited as I’m mostly used to Maya. Forgive my ignorance if some of the stuff I said in the first part doesn’t apply to Blender. However I know the software fairly well in the other areas as I’ve been using it for a good amount of years.
The goal here isn’t to lay down a definitive version of this but more to open the discussion early on to make blender’s rigging the best it can possibly be.
Hopefully what I’m proposing makes sense to you and you see the benefits of it. 
And this approach looks great, want to reuse parts of a rig, but without fiddling my head around some complicated code