Tuesday, September 21, 2010

[Rigging FAQ] Porting rigs from 2.4x to 2.5 - What you need to know

So, you've got an "awesome" rig that you set up in the old versions of Blender, and are now looking at migrating to 2.5. Will it still work? Are there any things you need to be aware of?


By and large, your rigs should still work. BUT, I do strongly recommend that you play around with the new functionality and see if/how much better your rigs could be if you started from scratch in the new system.

Now, having said that, the main things that should cause rig breakage in 2.5 are:
  • Anything scripted or that requires Python 
    • PyConstraints -  see explanation about why they aren't coming back in the near future
    • PyDrivers - the Py-API has changed, and so has the driver system. See this introduction to the new driver system. In short, use 'variables' instead of plugging data-access phrases into the expression, and forget about trying to use a specially named Text-block to store functions (for the next few months at least).
    • Script-Links and Space-Handlers - these were very hacky kludges that didn't totally fit in well with Blender's overall pipeline
  • Drivers - see this post for details about the new system.
    • As mentioned before, the greatest changes have happened with the PyDrivers. 
    • 'Local' rotation is not quite calculated the same way as it used to be. Now, the xyz-values you animate are used directly where possible (to avoid the problems described here). Hence, constraints are often not taken into account. If you used to need this for elbow-flexing stuff, consider using the 'Rotational Difference' variable type instead of grabbing the rotation about some axis directly.
    • Rotations are in radians instead of degrees (though in the rest of the UI, they are presented in degrees, as it's more appropriate in those places). This shouldn't cause rig breakage, but you should be aware of this when setting up drivers.
  • Armatures and 'Proxies'
    • 'Proxy Protected Layers' - the way that this system works in 2.5 has changed, though I'm not sure if it's really for the better (also, Cessen and I agree that this current layer-locking mechanism is just not fine-grained enough - i.e. past its use-by date). Anywho... in 2.4x, putting bones on 'protected layers' simply meant that they were correctly synchronised with the source rig whenever you loaded the file (and some things like constraints were not removable/changeable), so most riggers would just make all layers protected (including those with the control bones) so that animators could not break the rigs but could still work with up to date versions of them. Now, the 'protected' part of the name really applies, and you can't modify them in any way. This means that control bones must not be on such layers anymore. IIRC, there have been some changes which make this better.
  • Dependency on 'Speed' or 'Time' IPO-Curves - this only really affects Shape Keys, Curves (and Follow-Path constraint using these), and Objects. These two were really just hacked into Blender in the past (they were evaluated separately to the rest of the animation system, using special calls, etc. that everything using them needed to recalculate). If you were using these, you may want to look into the new ways of animating curves, etc.
  • Use of anything in the "Animation Hacks" panel for Objects - this includes "Slow Parent" and "Time Offset". Except in the Game Engine (if that thing even works), these options DO NOT work anymore. They were fundamentally broken by design in the first place, and are totally incompatible with the new animation system (and with depsgraph based systems too). Forget about using these, and of reporting any weird behaviour you may get while trying to report these. I'm going on record for saying that "I'll not be fixing these".
Anything I haven't mentioned here "shouldn't" have changed (or enough) to cause rig breakage.

There are however many new and improved features in 2.5, that should make rigging much nicer in general. Here are just some of the highlights:
  • Drivers - I've mentioned them already, but will mention again, that the driver system is now much-improved from the old 2.4x system. There is proper separation of Driver data from Animation data.
  • Constraints - while existing constraints haven't undergone any/many changes in general, there have been some new ones added.
    • Follow-Path constraint (while old) now has a 'Fixed Position' setting that lets you animate (and drive) the position along the curve.
    • Damped Track constraint is basically what the Track To constraint should have been but isn't. Use this instead of the latter if you need eyeballs or anything tracking a controller.
    • Copy Transform constraint basically just copies all the transforms of the target, saving the need for adding all 3 of Copy Loc/Rot/Scale to deform bones.
    • Spline IK constraint (works for bones only) provides a better way to get nice tail deformations. I should point out here that it should be used as part of a 'deformation' armature vs being in the same armature as the control bones (to deal with dependency issues).
  • Meta-Rig - while not totally finished, this allows you to import your own rig parts, and adapt them to your characters.
  • Custom Properties for Bones - no more adding Script constraints to get custom property storage, or any other funkiness
  • Choice of Rotation Mode/Orders for Object and Bones - animators are no longer restricted to trying to get their heads round Quaternions for Bones only. But also, be sure not to forget the possibility of turning on 'Axis Angle' for those objects rotating on a tilted angle (i.e. spinning planets) by using the 'axis' to set the tilt of the planet and the angle to rotate around that axis.
  • Bones can be used as Hooks too - hooks are a way of specifying some controller to deform vertices directly, which was especially useful for curves. Now, you can use bones as the controllers, instead of just using objects.
I'm not quite sure that there is something that I've forgotten to mention. But, this should be a good springboard for things to play with.

[EDIT 25Sep]: I forgot to mention that"Bone Heat" automatic weighting method has now replaced the old auto-weights method, and should (barring any regressions, which you should report) work in the same way. So, you should look for "Automatic Weights" instead of "Bone Heat" in 2.5.

Happy rigging!

1 comment:

  1. Oh! you have a blog too!

    Yeah thanks for all the improvements. I've always gone by the multi-armature motto.
    Are there any dependency issues you foresee in using multiple armatures ( ie one deforms, one animated ) while linking a rig over?

    ReplyDelete