Page MenuHome

Fix for T48988 - Enabling bbone easing for posemode

Authored by Thomas (Anudiz) on Aug 17 2017, 9:34 PM.



This fix enables the usage of bbones easing parameters for edit and pose mode seperately. This allows animators to take advantage of the functionality and may eliminate confusion as the parameters now behave similar to other bbone parameters.

Note that splitting the parameters between the modes effectively creates a new parameter set. Blend files of previous versions do not contain this information and will have the values set to 0 on load. As it broke backwards compatibility for pose mode values anyway, I also took the liberty to rename the easing parameters in some places for consistency (which breaks edit mode values).

Diff Detail

rB Blender

Event Timeline

Thomas (Anudiz) edited the summary of this revision. (Show Details)
Thomas (Anudiz) edited the summary of this revision. (Show Details)Aug 17 2017, 9:38 PM

It would be nice to get some feedback on this.
In the grand scheme of things its small fry, I know. But it gives more power to riggers and animators nontheless.

Joshua Leung (aligorith) requested changes to this revision.Oct 1 2017, 2:52 PM

Currently, there are 2 main issues that pop out for me:

1) Loss of backwards compatability

IMO, it's better that we don't break backwards compatability by losing old values (i.e. as a consequence of the complete removal of the ease1 and ease2 vars).

From experience, I've learned that it is highly likely that there are rigs out there where those values were set to specific values to get the desired effects, but no drivers/keyframes were set for those values. If we remove the ease1 and ease2 vars completely, those static values cannot be recovered/version patched in new version of Blender (though keyframes/drivers should still be able to be salvaged relatively easily by fixing the rna paths).

2) Either/Or vs Basis+Offset

In general, most of Transform Properties and the B-Bone settings work on the concept that the "restpose" value is a base upon which the "pose" value is applied as an offset. However, in the patch, armature.c - 601/602 shows instead that this is not the case. Instead, if you have a non-zero value in EditMode, changing to Pose mode will result in an abrupt correction (to zero ease in/out).

If instead the code here was something more like:

easeIn = bone->easeIn + (rest ? pchan->easeIn : 0.0)
hlen    = easeIn * circle_factor

I think it would work better for preserving backwards compatability, and allowing users to set an initial easing value for the restpose (to match the geometry), while still being able to animate relative to this base value.

This revision now requires changes to proceed.Oct 1 2017, 2:52 PM

Thank you for reviewing this.

Regarding Point 1:
Alright I will change it to keep "ease1" and "ease2" as variable names. That will at least assure backwards compatibility in edit / rest and may help fix other issues should they arise.

Regarding Point 2:
From an animators point of view I would rather work with consistent, self-evident values (0 and 2 have fixed meaning) than offsets for easing, but I also see where you're coming from.

Using a rest value of 1 and a pose value of -2 or +2: Should blender cap at 0 / 2 regardless? Probably yes, at least at 0.
Should the possible offset values then be capped at -2 / 2 as well?
One issue I see with this all is that you can enter invalid offsets, where a change in value will have no effect because you are outside the valid range anyway.
And you have to keep the possibility to do this, because what is invalid or not depends on the rest pose. That seems messy and could be a nuisance when animating.

Do you have an idea which could fix this?

Thomas (Anudiz) edited edge metadata.
  • Changed easeIn and easeOut back to ease1 and ease2 to maintain maximum compatibility.
  • Implemented easing in base+offset fashion similar to other bbone parameters
  • Changed range from -5.0 to +5.0 similar to other bbone parameters

It should now behave as suggested. I am not sure if opening up the easing parameters to the -5 to +5 range with offset is better than before, but in my brief tests it had no negative impact either.

Here are just a few small comments on the code. I'll give the patch a try later today - all going well, I don't see any further big problems, or at least nothing I can't quicky fix :)


Mark these as const float too


Leave space between asterisk and text


Same as above


See earlier comments





Thomas (Anudiz) marked 6 inline comments as done.

Corrected minor problems

This should be good to go now.
If there's anything else to be done, please let me know.

This revision was automatically updated to reflect the committed changes.