BBones Ease in/out don´t update the mesh deformation at current frame #48988

New Issue

Daniel Martinez Lara · 2016-08-01T00:58:10+02:00

Daniel Martinez Lara commented

2016-08-01 00:58:10 +02:00

Blender Version
build 01d5d28

Short description of error
BBones Ease in/out don´t update the mesh deformation at current frame

Exact steps for others to reproduce the error

1 -open "3 Bones Arm.blend"
2 -Select up arm bone and change Ease in/out values

Result: the bone Ease in/out values dont´t afect to the mesh deformation at current frame,

Daniel

3 Bones Arm.blend

**Blender Version** build 01d5d28 **Short description of error** BBones Ease in/out don´t update the mesh deformation at current frame **Exact steps for others to reproduce the error** 1 -open "3 Bones Arm.blend" 2 -Select up arm bone and change Ease in/out values Result: the bone Ease in/out values dont´t afect to the mesh deformation at current frame, Daniel [3 Bones Arm.blend](https://archive.blender.org/developer/F330585/3_Bones_Arm.blend)

Joshua Leung was assigned by Daniel Martinez Lara

2016-08-01 00:58:10 +02:00

Daniel Martinez Lara commented

2016-08-01 00:58:10 +02:00

Changed status to: 'Open'

Daniel Martinez Lara commented

2016-08-01 00:58:10 +02:00

Added subscriber: @pepe-school-land

Campbell Barton commented

2016-08-01 04:40:19 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2016-08-01 04:40:19 +02:00

Tested, dragging ease in/out values on the arm updates the mesh as expected. (both frame 4 and 5)

Joshua Leung commented

2016-08-01 05:42:41 +02:00

Hmm... it took a second look to confirm that this is in fact happening (bd11d91)

And checking with the original patch also shows that it wasn't working originally either :(

Hmm... it took a second look to confirm that this is in fact happening (bd11d91) ![3 Bones Arm - bd11d91.png](https://archive.blender.org/developer/F330694/3_Bones_Arm_-_bd11d91.png) And checking with the original patch also shows that it wasn't working originally either :(

Thomas commented

2017-03-05 16:00:36 +01:00

Added subscriber: @ThomasSeidelmann

Thomas commented

2017-03-05 16:00:36 +01:00

Ease In and Ease Out values seem to be unusable for animation, because they only affect the resting pose of the Bendy Bone. This can be shown by binding an object to the bone and changing the Ease In / Out parameters in pose mode. The object does not transform because it only changes the binding to the bone. Another indicator for this is that the Ease In and Ease Out parameters are shared between edit and pose mode, in contrast to the other Bendy Bone parameters, which doesn't seem to make sense if they were intended for animation.

Note that easing may appear to be working correctly when the bone has no initial curvature given and the binded mesh is straight aswell. It still only changes how the binding is done, but in that case the binding directly translates to animation. After changing the easing here a dependency update must be forced, e.g. pulling on a handle afterwards. Unless using the new depsgraph.

BendyBoneProblem.blend

Ease In and Ease Out values seem to be unusable for animation, because they only affect the resting pose of the Bendy Bone. This can be shown by binding an object to the bone and changing the Ease In / Out parameters in pose mode. The object does not transform because it only changes the binding to the bone. Another indicator for this is that the Ease In and Ease Out parameters are shared between edit and pose mode, in contrast to the other Bendy Bone parameters, which doesn't seem to make sense if they were intended for animation. Note that easing may appear to be working correctly when the bone has no initial curvature given and the binded mesh is straight aswell. It still only changes how the binding is done, but in that case the binding directly translates to animation. After changing the easing here a dependency update must be forced, e.g. pulling on a handle afterwards. Unless using the new depsgraph. [BendyBoneProblem.blend](https://archive.blender.org/developer/F503319/BendyBoneProblem.blend)

Daniel Martinez Lara commented

2017-03-05 21:52:39 +01:00

Hi Thomas!
Ease in /out is soooo usefull for animation, using all the time.

Daniel

Hi Thomas! Ease in /out is soooo usefull for animation, using all the time. Daniel

Daniel Martinez Lara commented

2017-03-05 21:56:11 +01:00

So please don't unable it! :)

Daniel

So please don't unable it! :) Daniel

Joshua Leung commented

2017-03-06 12:45:56 +01:00

I looked into this a few weeks back, but only figured out what was going wrong when I saw one of the forums posts somewhere about this.

What's happening here is that since there's actually just a single set of the Ease In/Out properties (on the Bone, not PoseBone), the easing will be applied when calculating the restpose of the BBone. The armature modifier figures out how much to deform the geometry by looking at the "restpose" and "final pose" of the bone to figure out how much deformation needs to occur. But, since the easing has already been performed in the restpose, the armature modifier ends up not seeing any effects from the ease in/out settings, resulting in no changes.

Here's a quick hack to work around this issue:
bbone_easing_01.patch

Have a play with this to see if it causes any problems. For example, there are two tweaks that I think we might need to make before applying any fixes:

Maybe we need to use 0.0f there instead of 1.0f? Using 0.0 there would correspond better to having no ease in/out at all, but may cause artifacts?
Alternatively, what we probably should have done from the start was to also have two sets of settings for this too. So you could set easing for the restpose and also for the final pose. Dunno if that would be of any use though... we can try that if this simpler fix is too restrictive :)

I looked into this a few weeks back, but only figured out what was going wrong when I saw one of the forums posts somewhere about this. What's happening here is that since there's actually just a single set of the Ease In/Out properties (on the Bone, not PoseBone), the easing will be applied when calculating the restpose of the BBone. The armature modifier figures out how much to deform the geometry by looking at the "restpose" and "final pose" of the bone to figure out how much deformation needs to occur. But, since the easing has already been performed in the restpose, the armature modifier ends up not seeing any effects from the ease in/out settings, resulting in no changes. Here's a quick hack to work around this issue: [bbone_easing_01.patch](https://archive.blender.org/developer/F503945/bbone_easing_01.patch) Have a play with this to see if it causes any problems. For example, there are two tweaks that I think we might need to make before applying any fixes: 1) Maybe we need to use 0.0f there instead of 1.0f? Using 0.0 there would correspond better to having no ease in/out at all, but may cause artifacts? 2) Alternatively, what we probably should have done from the start was to also have two sets of settings for this too. So you could set easing for the restpose and also for the final pose. Dunno if that would be of any use though... we can try that if this simpler fix is too restrictive :)

Anna Celarek commented

2017-03-06 13:58:42 +01:00

Added subscriber: @AnnaCelarek

Norvell Maples commented

2017-03-08 02:44:10 +01:00

Added subscriber: @norv

Norvell Maples commented

2017-03-08 02:44:10 +01:00

I was wanted to pipe in... and say this seems to be all working properly using Blender 2.78c running on Linux Mint 18.1...
thus it might be isolated to Windows or other operating systems...

anyway please test to make sure I'm understanding the problem...

ThnX

I was wanted to pipe in... and say this seems to be all working properly using Blender 2.78c running on Linux Mint 18.1... thus it might be isolated to Windows or other operating systems... anyway please test to make sure I'm understanding the problem... ThnX

Thomas commented

2017-04-20 20:22:47 +02:00

Sorry that I didn't reply earlier, something came up that required my full attention. And since I am new to working with the Source Code I also had some setup work to do.

Anyway I finally managed to try the patch you provided Joshua and I can say it has certainly fixed the issues with easing in pose mode, which now behaves as I would expect. This comes at the cost of shifting the bug over to edit mode however. So the roles are pretty much reversed now. When using anything other than the default 1.0f in edit mode the model will snap when attaching it to the armature. I think this is because now the easing value only applies to pose mode and "reverts" to the default 1.0f on binding. Since the pose mode value is != 1.0f however, it will immediately apply a transform after binding, which shouldn't be there. I have extended the file to illustrate this (which of course only happens with the patch applied), just attach the upper model to its armature with automatic weights.

Regarding the tweaks you mentioned:

Should default Ease In/Out be at 0.0f instead of 1.0f? While having the default at 1.0f doesn't bother me personally, I think the default at 0.0f +- 1 represents the intention of the values most accurately and intuitively. Excuse that I am not familar with the code , but how do you think this may lead to artifacts? At first glance it seems like a simple remap of the value range. .............EDIT: Scratch that. I had this mixed up in my head. No the default at 1.0f is fine and I would not change it.
Should there be a pair of values for Ease In/Out as it is with the other properties? I think so, yes. However compared to the other properties these should have a relation between rest mode and pose mode, since the value assigned for the rest pose has to be, or rather should be, the default value for pose mode. Imagine this were not the case and they would have independent defaults of 1.0f. What are you gonna do when the user specifies a value of 2.0f for Ease In/Out in rest and pose mode (cranking it up from 1.0f to 2.0f twice)? You either apply the easing twice, which is unwanted double transform or you strictly only use the rest pose easing for rest pose and pose mode easing for pose mode, which fixes the double transform, but leads to snapping when entering pose mode from rest as the rest value is automatically set back to 1.0f along with the geometry, which is also unwanted. Hence the relation -> rest pose value == default pose mode value, but otherwise independent.

Regarding Linux: I gave Blender 2.78c a quick run on Ubuntu 16.04.2 LTS. Based on that I cannot confirm that this issue is operating system related. I was able to reproduce the bug as classified initially. After a first very quick look into the code and the changes of Joshuas patch I would have actually been very surprised if this were indeed an operating system specific issue.

BendyBoneProblem_Patch.blend

Sorry that I didn't reply earlier, something came up that required my full attention. And since I am new to working with the Source Code I also had some setup work to do. Anyway I finally managed to try the patch you provided Joshua and I can say it has certainly fixed the issues with easing in pose mode, which now behaves as I would expect. This comes at the cost of shifting the bug over to edit mode however. So the roles are pretty much reversed now. When using anything other than the default 1.0f in edit mode the model will snap when attaching it to the armature. I think this is because now the easing value only applies to pose mode and "reverts" to the default 1.0f on binding. Since the pose mode value is != 1.0f however, it will immediately apply a transform after binding, which shouldn't be there. I have extended the file to illustrate this (which of course only happens with the patch applied), just attach the upper model to its armature with automatic weights. Regarding the tweaks you mentioned: - Should default Ease In/Out be at 0.0f instead of 1.0f? While having the default at 1.0f doesn't bother me personally, I think the default at 0.0f +- 1 represents the intention of the values most accurately and intuitively. Excuse that I am not familar with the code , but how do you think this may lead to artifacts? At first glance it seems like a simple remap of the value range. .............EDIT: Scratch that. I had this mixed up in my head. No the default at 1.0f is fine and I would not change it. - Should there be a pair of values for Ease In/Out as it is with the other properties? I think so, yes. However compared to the other properties these should have a relation between rest mode and pose mode, since the value assigned for the rest pose has to be, or rather should be, the default value for pose mode. Imagine this were not the case and they would have independent defaults of 1.0f. What are you gonna do when the user specifies a value of 2.0f for Ease In/Out in rest *and* pose mode (cranking it up from 1.0f to 2.0f twice)? You either apply the easing twice, which is unwanted double transform or you strictly only use the rest pose easing for rest pose and pose mode easing for pose mode, which fixes the double transform, but leads to snapping when entering pose mode from rest as the rest value is automatically set back to 1.0f along with the geometry, which is also unwanted. Hence the relation -> rest pose value == default pose mode value, but otherwise independent. Regarding Linux: I gave Blender 2.78c a quick run on Ubuntu 16.04.2 LTS. Based on that I cannot confirm that this issue is operating system related. I was able to reproduce the bug as classified initially. After a first very quick look into the code and the changes of Joshuas patch I would have actually been very surprised if this were indeed an operating system specific issue. [BendyBoneProblem_Patch.blend](https://archive.blender.org/developer/F559556/BendyBoneProblem_Patch.blend)

Paul Szajner commented

2017-06-15 14:08:35 +02:00

Added subscriber: @sozap

Paul Szajner commented

2017-06-15 14:08:35 +02:00

I've got the same issue with a recent 2.78.5 build on linux .
I've made a screenshot of my scene :

Alternatively, what we probably should have done from the start was to also have two sets of settings for this too. So you could set easing for the restpose and also for the final pose. Dunno if that would be of any use though... we can try that if this simpler fix is too restrictive :)

I think this would be great ! To me using Ease in/out looks like an alternative to Curve Offset, that is (at least to me) easier to rig. It would also be more consistent to have edit and pose values , as it's hard to guess it's not the same behaviour as CurveOffset. It can be great to have an initial curvature in edit mode as well.

I've got the same issue with a recent 2.78.5 build on linux . I've made a screenshot of my scene : ![Capture du 2017-06-15 13-39-39.jpg](https://archive.blender.org/developer/F631739/Capture_du_2017-06-15_13-39-39.jpg) > Alternatively, what we probably should have done from the start was to also have two sets of settings for this too. So you could set easing for the restpose and also for the final pose. Dunno if that would be of any use though... we can try that if this simpler fix is too restrictive :) I think this would be great ! To me using Ease in/out looks like an alternative to Curve Offset, that is (at least to me) easier to rig. It would also be more consistent to have edit and pose values , as it's hard to guess it's not the same behaviour as CurveOffset. It can be great to have an initial curvature in edit mode as well.

Thomas commented

2017-06-20 18:09:02 +02:00

Good to see the problem confirmed by an actual linux user, thanks for reporting the issue paul.

Unfortunately it seems Joshua is otherwise occupied for the time being and I can not spare enough time at the moment to work through blenders code base and this issue in specific.
If this is not fixed in a few months I will probably come back to this and see if I can manage to fix it. It would help a lot in rigging the character I am working on atm, making the rig less complicated and faster to set up while providing the control needed. Being able to utilize the easing in pose mode is a key feature to achieve this in my opinion.

Good to see the problem confirmed by an actual linux user, thanks for reporting the issue paul. Unfortunately it seems Joshua is otherwise occupied for the time being and I can not spare enough time at the moment to work through blenders code base and this issue in specific. If this is not fixed in a few months I will probably come back to this and see if I can manage to fix it. It would help a lot in rigging the character I am working on atm, making the rig less complicated and faster to set up while providing the control needed. Being able to utilize the easing in pose mode is a key feature to achieve this in my opinion.

Luciano Muñoz Sessarego commented

2017-07-13 11:08:57 +02:00

Added subscriber: @LucianoMunoz

Luciano Muñoz Sessarego commented

2017-07-13 11:08:57 +02:00

any chance this bug gets squashed for 2.79?

Thomas commented

2017-08-07 20:46:41 +02:00

I created a fix for this issue. However I could use some help to take this further, since I believe two problems remain.

What I did:

Separated easing parameters for edit mode and pose mode, enabling the usage of ease in / out for both modes.
Adjusted all utility and convenience methods that I could find to support this new separation

Remaining problems:

The pose mode values simply override the rest pose ones. Imho this is desired, but it comes with a problem. When resetting the scale of the bendy bone the ease values are reset to a fixed value of 1.0f, but in reality it should reset to whatever the user set as rest value. The corresponding method, pchan_clear_scale(bPoseChannel *pchan), would need access to this value in one way or another. Any ideas on how to do this best?

The edit mode prieview of bendy bones does currently ignore the previous and next bones (the handles). This results in a false and misleading preview when using handles which are not aligned straight with the bendy bone. It seems this was done with the assumption in mind, that handles should be aligned straight with the bendy bones in rest mode anyway. However this assumption does not correspond to the programs behavior and imho is unneccessarily restrictive. Why should the user not take advantage of the inherent easing properties? The handles are being factored in and the preview should reflect that. Thoughts, agree, disagree?

Fix for basic problem (created for the current Blender 2.79):
BendyBones_PosemodeEaseInOut.patch

I created a fix for this issue. However I could use some help to take this further, since I believe two problems remain. What I did: - Separated easing parameters for edit mode and pose mode, enabling the usage of ease in / out for both modes. - Adjusted all utility and convenience methods that I could find to support this new separation Remaining problems: # The pose mode values simply override the rest pose ones. Imho this is desired, but it comes with a problem. When resetting the scale of the bendy bone the ease values are reset to a fixed value of 1.0f, but in reality it should reset to whatever the user set as rest value. The corresponding method, pchan_clear_scale(bPoseChannel *pchan), would need access to this value in one way or another. Any ideas on how to do this best? # The edit mode prieview of bendy bones does currently ignore the previous and next bones (the handles). This results in a false and misleading preview when using handles which are not aligned straight with the bendy bone. It seems this was done with the assumption in mind, that handles should be aligned straight with the bendy bones in rest mode anyway. However this assumption does not correspond to the programs behavior and imho is unneccessarily restrictive. Why should the user not take advantage of the inherent easing properties? The handles are being factored in and the preview should reflect that. Thoughts, agree, disagree? Fix for basic problem (created for the current Blender 2.79): [BendyBones_PosemodeEaseInOut.patch](https://archive.blender.org/developer/F698150/BendyBones_PosemodeEaseInOut.patch)

Anna Celarek commented

2017-08-08 09:44:19 +02:00

Thomas, I use the custom handles a lot in my rigs, and I agree with your point 2.
Currently it's quite tedious to have to align the handles while not seeing in edit mode what's happening to the rest pose.
Moreover, it's tedious to have to align them at all, especially when the bendy bone is askew and initial Curve XY offset, Roll or Easing is set (the tangent bone has to be aligned to an imaginary straight bone, not to the bent bone visible in viewport).

I think it would be much user-friendlier, if only pose mode manipulations of the handle bones were considered in pose mode. So the rigger would align the handle bones in edit mode however is convenient for the animator (the bendy bone should not react to that neither in edit nor in pose mode). The initial (rest pose) bending/twisting would come only from the edit mode Curve XY Offset, Roll, Scale and Easing. Then when in pose mode the animator manipulates the handle bones, the Bendy bones reacts to that (to the offset, basically), and also to pose mode changes of Curve XY Offset/Roll/Scale/Easing.

Thomas, I use the custom handles a lot in my rigs, and I agree with your point 2. Currently it's quite tedious to have to align the handles while not seeing in edit mode what's happening to the rest pose. Moreover, it's tedious to have to align them at all, especially when the bendy bone is askew and initial Curve XY offset, Roll or Easing is set (the tangent bone has to be aligned to an imaginary straight bone, not to the bent bone visible in viewport). I think it would be much user-friendlier, if only pose mode manipulations of the handle bones were considered in pose mode. So the rigger would align the handle bones in edit mode however is convenient for the animator (the bendy bone should not react to that neither in edit nor in pose mode). The initial (rest pose) bending/twisting would come only from the edit mode Curve XY Offset, Roll, Scale and Easing. Then when in pose mode the animator manipulates the handle bones, the Bendy bones reacts to that (to the offset, basically), and also to pose mode changes of Curve XY Offset/Roll/Scale/Easing.

Thomas commented

2017-08-08 20:45:37 +02:00

Hey, I like your suggestion to have the handles as offsets only. Should this affect both, 'Custom Handles' and inherent 'Parent / Child Handles'? I'd say yes for consistency and think it would be a good addition. Unfortunately I also see some problems:

It breaks backwards compatibility badly. All rigs which use bendy-bones without straight handle bones will break. This will even affect older rigs from before the big bendy-bone overhaul. This would be very problematic. Solution: Have a switch on the bendy-bone (probably in edit mode) to choose between the behaviors; something like "Use Handle Bones As Offsets Only".
Assuming the solution above: It does not help to solve the other two problems. And I would therefore put this on hold until they are fixed.
Someone needs to implement it. Well I am someone :) but I am also completely new to blender coding and not yet really comfortable with it and this seems somewhat complicated. I will look into it if the other two problems don't give me too much trouble, but I won't promise anything.

Hey, I like your suggestion to have the handles as offsets only. Should this affect both, 'Custom Handles' and inherent 'Parent / Child Handles'? I'd say yes for consistency and think it would be a good addition. Unfortunately I also see some problems: - It breaks backwards compatibility badly. All rigs which use bendy-bones without straight handle bones will break. This will even affect older rigs from before the big bendy-bone overhaul. This would be very problematic. Solution: Have a switch on the bendy-bone (probably in edit mode) to choose between the behaviors; something like "Use Handle Bones As Offsets Only". - Assuming the solution above: It does not help to solve the other two problems. And I would therefore put this on hold until they are fixed. - Someone needs to implement it. Well I am someone :) but I am also completely new to blender coding and not yet really comfortable with it and this seems somewhat complicated. I will look into it if the other two problems don't give me too much trouble, but I won't promise anything.

Paul Szajner commented

2017-08-08 23:45:08 +02:00

About your point 2/ it looks like old BBone behaviour when the bbone's curving was poping when switching bettwen edit and posemode. Now that we have also curving in pose mode what you're suggesting seems logicial and aligned with current design. Maybe having one bone influence the propertie (curvature) of another look more something beyond the scope of edit mode... Anyway this also put less try and error when settings theses bones. I think this change is for the best.

Thanks a lot for the patch and let see what Aligorith think about it ...

About your point 2/ it looks like old BBone behaviour when the bbone's curving was poping when switching bettwen edit and posemode. Now that we have also curving in pose mode what you're suggesting seems logicial and aligned with current design. Maybe having one bone influence the propertie (curvature) of another look more something beyond the scope of edit mode... Anyway this also put less try and error when settings theses bones. I think this change is for the best. Thanks a lot for the patch and let see what Aligorith think about it ...

Thomas commented

2017-08-09 20:32:06 +02:00

A quick update on the prevous fix which solves problem 1 and corrects a typo. Before tackling the edit mode preview issue I'll see if I can gather some information on the reasoning of the current approach. After a quick look my current solution would be to enable the "Custom Handle" options in edit mode as well (not only in pose mode as it is currently) to get access to them for drawing the preview. As far as I see this should be functionally unproblematic, but there may be a reason it was not done so in the first place.

The only problem I see is backwards compatibility as the place where these get saved in the file would probably change and the settings would then be reset in older files. I already ran into this issue with the fix I did so far, which also breaks the connection to previously saved easing parameters...

BendyBones_PosemodeEaseInOut_2.patch

A quick update on the prevous fix which solves problem 1 and corrects a typo. Before tackling the edit mode preview issue I'll see if I can gather some information on the reasoning of the current approach. After a quick look my current solution would be to enable the "Custom Handle" options in edit mode as well (not only in pose mode as it is currently) to get access to them for drawing the preview. As far as I see this should be functionally unproblematic, but there may be a reason it was not done so in the first place. The only problem I see is backwards compatibility as the place where these get saved in the file would probably change and the settings would then be reset in older files. I already ran into this issue with the fix I did so far, which also breaks the connection to previously saved easing parameters... [BendyBones_PosemodeEaseInOut_2.patch](https://archive.blender.org/developer/F702701/BendyBones_PosemodeEaseInOut_2.patch)

Joshua Leung commented

2017-11-19 15:15:25 +01:00

Changed status from 'Open' to: 'Resolved'

Joshua Leung closed this issue

2017-11-19 15:15:25 +01:00

Joshua Leung commented

2017-11-19 15:15:25 +01:00

Fixed in a819ef65c0.

Fixed in a819ef65c0.

Sign in to join this conversation.