Monday, 22 November 2010

Basic scene and rig structure

It's impossible to overstate the importance of an organised approach to rig building. Even if the rig is a simple one it's a good idea to maintain good working practices at all times. As rigs become more complex and require ongoing work or bug fixing days, weeks, or even months after it was initially built a good scene and rig structure is essential if you are to stand any chance of making sense of it all.


Rig structure - separate out your systems.

Character rigs consist of three main sections.
  • Control/driver rig
  • Deformation rig
  • Exportable, skinned skeleton (unbroken hierarchy)
The exportable skeleton is an unbroken skeletal hierarchy. Meshes are skinned to this skeleton, and this is what is exported to game. It is driven by the control/driver rig and deformation rig by point and orientation constraints, but other than that it remains completely separate to all deform or control systems. This separation of systems is a key principle in rig building.



The control/driver skeleton is derived from the exportable skeleton. Because our export skeleton is kept separate we are not limited to keeping the driver skeleton as a contiguous hierarchy and this enables us to construct much more powerful control schemes.

Deformation systems are things like roll joints, pectorals and all the nodes associated with them. Essentially these are any deformation systems that are driven automatically and will vary from character to character.


Scene structure

There isn't necessarily any right way of organising your scene, this is just the way I choose to do it.


Everything is under a single top group called <char name_grp>.
For the purposes of this post, ignore the global scale group as it hooks into some custom tools I may get round to covering in the future. 
Here you can see the basic principle of separating the rig structure in the way the scene is organised. 
Deform contains all systems associated with automatic deformation - roll joints etc. etc. Also in here is the exportable skeleton. Control contains all the driver joints, ik systems etc. etc. that make up the control/driver rig. Mesh contains all the skinned exportable meshes, and anim_controls contain all the animation controls.



Expanding on control we can see that the division of the rig into easily manageable sections continues.


...and the same for deform. The root joint at the top of the hierachy is the  export skeleton.


I have a shelf script to create the basic groups:


select -cl  ;
group -n "_grp" -em;
group -n "DO_NOT_TOUCH" -em;
group -n "control" -em;
group -n "deform" -em;
group -n "mesh" -em;
group -n "anim_controls" -em;
group -n "global_scale" -em;
parent "control" "deform" "mesh" "DO_NOT_TOUCH" ;
parent "DO_NOT_TOUCH" "global_scale";
parent "global_scale" "anim_controls" "_grp" ;
addAttr -ln "controlList"  -dt "string"  |_grp;
setAttr -e-keyable true |_grp.controlList;
addAttr -ln "defaultState"  -dt "string"  |_grp;
setAttr -e-keyable true |_grp.defaultState;
setAttr "mesh.inheritsTransform" 0;

...you'll notice some extra attributes on there which I use later on to back up character set info and also store the state of the character set. This info is then used in some custom tools for a single-click character reset that places the control rig in the default pose.


Matt.

3 comments:

  1. Interesting stuff, there's definitely a debate to combine the deformation rig with the control rig. But i think I'm veering towards separating it too.

    ReplyDelete
  2. The benefits of separating them out becomes more apparent with characters of greater complexity, where the best skeleton layout and deformation solution isn't necessarily known from the start.

    By building a completely self-contained deformation rig before starting on control systems you create a work flow that allows you to iterate and improve a deformation solution in a much less destructive way.
    In an integrated solution, any changes you find you would like to make to joint placement or helper joints can effectively invalidate whole control systems. In this case one of two things happen; either (a)you make the update and waste loads of time rebuilding the control systems around the new joint positions or (b)can't make those changes due to project time constraints.
    Neither of these options are ideal, and both of them are avoidable.

    All control systems are logically derived from the deformation rig so it really makes sense to lock down joint positions and helper joint systems as much as possible before starting the control rig. The best way of doing this is by separating them out so you can fully test your deform rig independently of any control systems.
    Only when I'm completely happy with the joints layout and deformation systems do I build the control rig.

    There is some level of integration of deformation and control (for example combined driven/animateable muscles) but that comes later.

    I follow this process even for simple, lightweight characters. Working in this way also helps you achieve a nice separated modular scene structure which makes rigs easier to maintain - the more things you lump together the harder it is to work with later.

    Matt

    ReplyDelete
  3. Hi Matt,
    if you had a system to see the users visit to your blog, well that guy from Florence that is coming here almost every day it's me!! I'm learning a lot from your blog. Thanks so much.

    I would like to ask you something about this post.. In the picture at the beginning there is a difference between the layout of the deform skeleton and the export skeleton (the joint under the armpit is missing in the export skeleton).. if the control rig plus the deform rig control the export rig, shouldn't be the same ammount of joints in the export rig? or at least not a number less than the number of the joints in the deform rig?

    also I tried to make a test, and I found that I had to point and orient constraint the spine joints and also connect the scale of them (otherwise I was having a cicle behaviour from the stretchyspine system.. is this what you meant at the beginning of the post, when saying point orient and connection?

    thankyou very much , I hope you will have time to reply.. thanks
    Guido

    ReplyDelete