Wednesday, January 27, 2016

Dev Experiments - Pepeland's Improved Bendy Bones

Over the weekend, I've been doing some experiments with the bendy bone improvements patch (original code by Jose Molina) that pepeland demoed at BConf15. To remind you of what this is about, here's are a few screenshots of the patch in action:

Three bones showing off how the bendy bone settings work: 1) Curve X/Y properties, 2) Scale In/Out, 3) Roll In/Out

Each coloured segment is a single bone

EDIT: Just to clarify any confusion, this is NOT Pose Sculpting. That is a separate project. See this instead for the latest updates.

So far, I've mostly been cleaning up the initial patch by Jose Molina, and trying to figure out what it does, how, why, and also trying to identify and fix bugs. For example:

Poor Koro...

Pinguino (Caminandes 3) is not looking too flash either!

I found yesterday that apparently it doesn't work so great with old Blenrig files. I'll have to look into why it's failing, but it'll either be the lack of version patching, or something more sinister :/

There's also a bug in how there are gaps between the bone segments (as shown in the viewport). Attempts to fix this so far have resulted in the deforms going crazy instead... so, maybe it's something we'll have to live with - it could well be a good way to indicate the different ways that these work?

Currently I'm only tinkering with this in a local branch, but I'll push the branch to the main repo soon when I figure out what's going on with these bugs. Until then, hope you enjoyed this little update!


  1. nice b-bones, i have a question about interpolation if you divide a b-bone in four parts and the mesh has for example twenty subdivision, each segment of the b-bone will take five mesh subdivisions each, its no smoothing or blending among segments on the skinning, Is there any plan to improve this?
    by the way those new parameter on the bendy will rock once it finish :3

    1. Interesting question - TBH, I've never really looked into deformation issues like this in depth. However, at one point, it did occur to me that it might be a good idea to look into how the patch handled things like this, as part of the testing process.

      Regarding the quality of bbone deforms in Blender: Now that you bring it up, I'll take a look while I'm digging around in there. There will either be a simple tweak/fix that can be done to improve things here, or at worst, I could refer back an interesting 2013 paper - "Differential Blending for Expressive Sketch-Based Posing" by Oztireli et al. - which defines 2 sketch-based posing algorithms, and an improved way of calculating deforms (compared to dual quats IIRC)

      In general though, I'm personally not very interested in working on deformations or deformation quality. IMO, it's often quite hard to tell the difference between some of the subtle differences between different techniques/versions. Besides, enough people work on that stuff, that there doesn't need to be another "me too" ;)

  2. Looking cool, but if I observe correctly, these results are achievable with curved bbones already no ? Although these alleviate the need for an intermediate bbone for taking care of the "curve" factor.

    1. Daniel's talk at BConf explains much of the rationale for this.

      Here's my take:
      With traditional bbones, you need at least n + 2 bones (and often, it comes out more like n + 4 or n + 5, when taking into account the need for extra control bones on top of the deform bones), while here you only need n.

      For example, here you can accomplish these thing using just a single bbone by tweaking the settings on it, whereas with traditional bbones, you need to have a directly connected bone before and after the bbone to act as its handles. As a result, you can't actually move the bone around freely without it causing unwanted deforms.

      The main problem with needing all these extra bones to get a controllable setup is that it also makes it a lot more complicated for non-specialist riggers to get in there and set up simple rigs when the need arises. That is perhaps the more significant bottleneck.

  3. Sound reasoning, rig complexity should be improved on where possible.

  4. Very very interesting subject. I wish you will achieve this

  5. Thanks for looking into this patch Aligorith. If possible, could this replace the current 'Curved Bones' options under the Deform section? I find b-bones subdivs and their interpolation hard to debug, and often have unpredictable behaviour. Plus this new feature more or less does b-bones subdivisions better IMHO.

  6. Have you thought of putting shape keys on bones? I ask because these can be handy when deforming meshes that also have shape keys, to keep the two in sync.

    1. Hmm... that's an interesting idea, though I'm not entirely sure how/why it would be useful, and/or whether in practical terms it just ends up being more hassle than it's worth?