Streamlining advanced rigging of B-Bone chains. #83908

New Issue

Alexander Gavrilov · 2020-12-17T20:28:26+01:00

2020-12-17 20:28:26 +01:00

This task describes the common reasoning and purpose behind D9493, D9469, D9626 and D9870, as agreed with @dr.sybren in chat.

Blender supports bones that bend according to the shape of a Bezier spline. It seems originally these B-Bones have been envisioned as something to be controlled by the animator directly, but in practice they are used as back-end components of more complex rigs, with completely separate set of control bones exposed to the rig user.

Although it may seem nice to aim for fulfilling the original vision, a much more simple and practical area of improvement is streamlining the mechanims required to attach the B-Bone to the controls in a complex rig. To that end, this outlines a flexible rig setup and a set of (reasonably general purpose) improvements to blender itself necessary to easily and efficiently create it. I think in general it is a good idea to design rigging tools together with a production quality rig, rather than by theorizing in a vacuum - a couple of years ago I got a definite impression that wasn't how Spline IK was designed when I tried to make a proper tentacle.

Goal

This task aims to design a new, more powerful, compact and flexible rig pattern for using B-Bones in a complex rig, while adding built-in features necessary for it to work.

For programmers, using an analogy of rigging to scripting, this is like aiming to design a good script pattern to address a common task in a scripting language, and then adding built-in language and library features necessary to support it.

Thus this task is inherently an intersection of rigging and Blender core development.

Rig Requirements

Use the minimum necessary number of bones.
The controls need not be oriented the same as the actual handles.
The rig retains behavior similar to built-in 'automatic' handles, but lets the user tweak handle rotation.
Scaling the controls applies reasonable scaling transformation to the chain.

Rig Design

Since controls should support arbitrary orientation, the rig requires a hidden bone for each control to act as an actual chain custom handle. Thus, the minimal setup is three controls, three handles, and two deform bones.

{F9515400,size=full}

The deform B-Bones are rigged in a standard way, using Copy Location + Stretch To. The core of the mechanism involves the handles and B-Bone settings.

Auto Handle Emulation

The first part of the handle mechanism is emulating the automatic handle behavior. Since the rig uses custom handles, this automatically switches off the built-in logic, which has to be replicated on the handle bones.

The standard auto handle math simply aligns the handles to be parallel to the line connecting the previous and the next control. This can be easily done via Copy Location and Damped Track constraints.

It may also be possible to imagine other automatic behavior schemes, e.g. averaging angles, so it is not necessary or appropriate to add special code for this task to Blender.

Applying Control Transformation To Handles

The next part is transferring local rotation and scale of the control bone to the handle bone, and there is a big area for improvement here.

The local transformation is chosen because it isolates animation applied directly to the control, and allows flexibility in parenting the control and handle bones.

Transformation transfer has to be done via a constraint that is executed after the auto handle emulation, because Damped Track completely overwrites rotation. Location of the handle bone doesn't matter, so the appropriate convenient tool to copy both rotation and scale in one go seems to be the Copy Transforms constraint. However, there are some issues to address:

Local Orientation Adjustment

First, since the controls aren't necessarily oriented the same as the handles in rest pose, their local space orientation is different, and simply copying its Local Space transformation would move the handle bone differently. Therefore it is necessary to convert between orientations.

This can be done with two additional bones per handle and control pair:

A child of the control, oriented the same as the handle in rest pose, without constraints.
A sibling of the control, oriented the same as the handle in rest pose, with a Copy Transforms (World Space) from child.

If the handle then copies Local Space transformation from sibling, it would move exactly as the control in global space (at least if their parent bones are still in sync). However, absent a powerful node system that allows arbitrary matrix math, this requires many additional bones.

Therefore, D9493 (inspired by the Custom Space feature) adds an Owner Local Space, which replicates the behavior of this setup as a new Target Space option.

The behavior cannot be replicated using Custom Space, because that mode is based on world orientations, and thus, e.g. using the control as the custom space would use the current world space difference between control and handle orientations, rather than their rest pose orientation difference. Both approaches undoubtedly have their use, but are distinct.

This new option is useful in other situations, whenever it is desired to copy local transformation between two differently oriented bones in a way that would make them move the same globally, barring parent induced deviation.

Shear Removal Tools

An unfortunate side effect of orientation conversion, however, is inevitable shear if the control is non-uniformly scaled. This happens both in the bone setup and the Owner Local Space mode. Shear is never desired and negatively affects various math, including matrix to quaternion conversion involved in B-Bone roll handling. Thus it needs to be removed.

There are two valid places in the computation where to remove shear - immediately after Owner Local Space conversion inside Copy Transforms, and after Copy Transforms to sanitize the final result.

The D9626 patch adds shear removal to the Limit Rotation constraint, which is justified for the same reason as the recent change to Copy Rotation: due to using Euler math the constraint already removes shear, but since conversion to Euler doesn't expect it, the actual rotation becomes nonsensical. An explicit shear removal to sanitize the input thus makes sense, and conveniently allows using the constraint without any limits set as a simple 'remove shear' operation. Any feature node system should include this as a node of its own.

The D9469 includes a simple check box to remove shear from the target input of Copy Transforms.

The need to remove shear is likewise not limited to this use case - only yesterday @jpbouza-4 asked about removing shear after Armature used to 'parent' to B-Bones. Patched Limit Rotation can be used for that purpose as well.

Combining Transforms

Finally, the transformation has to be combined with the auto handle transformation, which can benefit from more Mix options in Copy Transforms. There are two ways to use D9469 mix modes that may make sense:

Before Original (Full) + Limit Rotation to remove shear: This uses simple matrix multiplication for full effect, where non-uniform scale can affect rotation.
Fix Shear + Before Original (Split or Aligned): This effectively works like Copy Rotation + Copy Scale, except that scale is copied after a common synchronized shear removal step.

This is essentially using and viewing Copy Transforms as a matrix math node, and like removing shear more options are useful in other cases too.

Applying Handle Scale

Finally, it is necessary to apply control scale to the actual B-Bones in a way that looks good. Due to the orientation difference, it makes sense to actually use the scale that was just transferred to the handle bones. There are two issues here:

B-Bones only have options for X and Y scale (actually X and Z), but not lengthwise scale. There is an easing channel, but it is not really scale, as it affects the shape of the Bezier curve, but not the length of the segments.
Transferring scale would require 6 trivial drivers per control in the middle of a chain, and 3 at each end, which is insane performance and convenience-wise.

D9870 thus addresses these issues, adding Length scale channels, and simple toggles to choose which B-Bone scale channels to drive from the local scale of the custom handle bone.

Examples

This is an example of this setup, used to create the image above. It can be tested using a custom build of blender that contains these patches.

test-bbone-chain.blend

This setup is also the base of the new face rigging system being developed for Rigify, and this is one of the recent test generation results.

This task describes the common reasoning and purpose behind [D9493](https://archive.blender.org/developer/D9493), [D9469](https://archive.blender.org/developer/D9469), [D9626](https://archive.blender.org/developer/D9626) and [D9870](https://archive.blender.org/developer/D9870), as agreed with @dr.sybren in chat. Blender supports bones that bend according to the shape of a Bezier spline. It seems originally these B-Bones have been envisioned as something to be controlled by the animator directly, but in practice they are used as back-end components of more complex rigs, with completely separate set of control bones exposed to the rig user. Although it may seem nice to aim for fulfilling the original vision, a much more simple and practical area of improvement is streamlining the mechanims required to attach the B-Bone to the controls in a complex rig. To that end, this outlines a flexible rig setup and a set of (reasonably general purpose) improvements to blender itself necessary to easily and efficiently create it. I think in general it is a good idea to design rigging tools together with a production quality rig, rather than by theorizing in a vacuum - a couple of years ago I got a definite impression that wasn't how Spline IK was designed when I tried to make a proper tentacle. Goal **** This task aims to design a new, more powerful, compact and flexible rig pattern for using B-Bones in a complex rig, while adding built-in features necessary for it to work. For programmers, using an analogy of rigging to scripting, this is like aiming to design a good script pattern to address a common task in a scripting language, and then adding built-in language and library features necessary to support it. Thus this task is inherently an intersection of rigging and Blender core development. Rig Requirements **** 1. Use the minimum necessary number of bones. 2. The controls need not be oriented the same as the actual handles. 3. The rig retains behavior similar to built-in 'automatic' handles, but lets the user tweak handle rotation. 4. Scaling the controls applies reasonable scaling transformation to the chain. Rig Design **** Since controls should support arbitrary orientation, the rig requires a hidden bone for each control to act as an actual chain custom handle. Thus, the minimal setup is three controls, three handles, and two deform bones. {[F9515400](https://archive.blender.org/developer/F9515400/Screenshot_20201217_210242.png),size=full} The deform B-Bones are rigged in a standard way, using Copy Location + Stretch To. The core of the mechanism involves the handles and B-Bone settings. Auto Handle Emulation -------------------------- The first part of the handle mechanism is emulating the automatic handle behavior. Since the rig uses custom handles, this automatically switches off the built-in logic, which has to be replicated on the handle bones. The standard auto handle math simply aligns the handles to be parallel to the line connecting the previous and the next control. This can be easily done via Copy Location and Damped Track constraints. It may also be possible to imagine other automatic behavior schemes, e.g. averaging angles, so it is not necessary or appropriate to add special code for this task to Blender. Applying Control Transformation To Handles ----------------------------------------------- The next part is transferring local rotation and scale of the control bone to the handle bone, and there is a big area for improvement here. The local transformation is chosen because it isolates animation applied directly to the control, and allows flexibility in parenting the control and handle bones. Transformation transfer has to be done via a constraint that is executed after the auto handle emulation, because Damped Track completely overwrites rotation. Location of the handle bone doesn't matter, so the appropriate convenient tool to copy both rotation and scale in one go seems to be the Copy Transforms constraint. However, there are some issues to address: **Local Orientation Adjustment** First, since the controls aren't necessarily oriented the same as the handles in rest pose, their local space orientation is different, and simply copying its Local Space transformation would move the handle bone differently. Therefore it is necessary to convert between orientations. This can be done with two additional bones per handle and control pair: * A child of the control, oriented the same as the handle in rest pose, without constraints. * A sibling of the control, oriented the same as the handle in rest pose, with a Copy Transforms (World Space) from child. If the handle then copies Local Space transformation from sibling, it would move exactly as the control in global space (at least if their parent bones are still in sync). However, absent a powerful node system that allows arbitrary matrix math, this requires many additional bones. Therefore, [D9493](https://archive.blender.org/developer/D9493) (inspired by the Custom Space feature) adds an Owner Local Space, which replicates the behavior of this setup as a new Target Space option. The behavior cannot be replicated using Custom Space, because that mode is based on world orientations, and thus, e.g. using the control as the custom space would use the *current* world space difference between control and handle orientations, rather than their *rest pose* orientation difference. Both approaches undoubtedly have their use, but are distinct. This new option is useful in other situations, whenever it is desired to copy local transformation between two differently oriented bones in a way that would make them move the same globally, barring parent induced deviation. **Shear Removal Tools** An unfortunate side effect of orientation conversion, however, is inevitable shear if the control is non-uniformly scaled. This happens both in the bone setup and the Owner Local Space mode. Shear is never desired and negatively affects various math, including matrix to quaternion conversion involved in B-Bone roll handling. Thus it needs to be removed. There are two valid places in the computation where to remove shear - immediately after Owner Local Space conversion inside Copy Transforms, and after Copy Transforms to sanitize the final result. The [D9626](https://archive.blender.org/developer/D9626) patch adds shear removal to the Limit Rotation constraint, which is justified for the same reason as the recent change to Copy Rotation: due to using Euler math the constraint already removes shear, but since conversion to Euler doesn't expect it, the actual rotation becomes nonsensical. An explicit shear removal to sanitize the input thus makes sense, and conveniently allows using the constraint without any limits set as a simple 'remove shear' operation. Any feature node system should include this as a node of its own. The [D9469](https://archive.blender.org/developer/D9469) includes a simple check box to remove shear from the target input of Copy Transforms. The need to remove shear is likewise not limited to this use case - only yesterday @jpbouza-4 asked about removing shear after Armature used to 'parent' to B-Bones. Patched Limit Rotation can be used for that purpose as well. **Combining Transforms** Finally, the transformation has to be combined with the auto handle transformation, which can benefit from more Mix options in Copy Transforms. There are two ways to use [D9469](https://archive.blender.org/developer/D9469) mix modes that may make sense: 1. Before Original (Full) + Limit Rotation to remove shear: This uses simple matrix multiplication for full effect, where non-uniform scale can affect rotation. 2. Fix Shear + Before Original (Split or Aligned): This effectively works like Copy Rotation + Copy Scale, except that scale is copied after a common synchronized shear removal step. This is essentially using and viewing Copy Transforms as a matrix math node, and like removing shear more options are useful in other cases too. Applying Handle Scale ------------------------- Finally, it is necessary to apply control scale to the actual B-Bones in a way that looks good. Due to the orientation difference, it makes sense to actually use the scale that was just transferred to the handle bones. There are two issues here: 1. B-Bones only have options for X and Y scale (actually X and Z), but not lengthwise scale. There is an easing channel, but it is not really scale, as it affects the shape of the Bezier curve, but not the length of the segments. 2. Transferring scale would require 6 trivial drivers per control in the middle of a chain, and 3 at each end, which is insane performance and convenience-wise. [D9870](https://archive.blender.org/developer/D9870) thus addresses these issues, adding Length scale channels, and simple toggles to choose which B-Bone scale channels to drive from the local scale of the custom handle bone. Examples **** This is an example of this setup, used to create the image above. It can be tested using a [custom build ](https://builder.blender.org/download/temp-angavrilov-constraints/) of blender that contains these patches. [test-bbone-chain.blend](https://archive.blender.org/developer/F9515533/test-bbone-chain.blend) This setup is also the base of the new face rigging system being developed for Rigify, and [this ](https://pasteall.org/blend/075dbb849d854feeb3fdb24bf2935719) is one of the recent test generation results.

Alexander Gavrilov self-assigned this 2020-12-17 20:28:26 +01:00

Alexander Gavrilov commented

2020-12-17 20:28:26 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Alexander Gavrilov commented

2020-12-17 20:28:26 +01:00

Added subscribers: @jpbouza-4, @dr.sybren, @angavrilov, @Mets, @icappiello

blender-admin commented

2020-12-17 20:28:26 +01:00

This issue was referenced by bc8ae58727

This issue was referenced by bc8ae58727bf078df1fc5803a9de5c9eb984aeb7

blender-admin commented

2020-12-17 20:28:26 +01:00

This issue was referenced by 682a74e090

This issue was referenced by 682a74e0909ba4e669a3f282b3bc5da0ae81e4da

Ivan Cappiello commented

2020-12-18 09:51:56 +01:00

@angavrilov i believe this approach is correct.
The b-bones are used as support for more complex rigs mainly because the only way the animator can access a pseudo-handle/easing control is through sliders and properties that is very uncomfortable. On the other hand we can debate if this was the intended final implementation.

If there was some sort of visual handle mechanism for the user to be tweaked in viewport instead of accessing values, probably the b-bone would have been implemented directly in rigs (i believe this was the intent of daniel lara's easy-rigging).
Unfortunately seems nobody ever cared (or had time) to build an usable interaction between b-bone features and animators. That's why riggers are trying to inject b-bone features in their rigs.

When it comes to rigify, due to its modular approach, becomes pretty easy create a supporting system to expose the user controls that enable visual interaction with b-bones features. The patch seems to work in this path, allowing the riggers to correctly interact with b-bones "handles". So in my opinion is the clearer way to go since the patch basically extends what is the actual usage of b-bones.

Overlooking it from a general b-bone design pov, probably a better idea would have been discussing on how making the b-bone system more interactive in the viewport without accessing annoying sliders and multiple f-curve channels, but this in my opinion would be a giant design task and should be addressed by a team of developers in a major release.

@angavrilov i believe this approach is correct. The b-bones are used as support for more complex rigs mainly because the only way the animator can access a pseudo-handle/easing control is through sliders and properties that is very uncomfortable. On the other hand we can debate if this was the intended final implementation. If there was some sort of visual handle mechanism for the user to be tweaked in viewport instead of accessing values, probably the b-bone would have been implemented directly in rigs (i believe this was the intent of daniel lara's easy-rigging). Unfortunately seems nobody ever cared (or had time) to build an usable interaction between b-bone features and animators. That's why riggers are trying to inject b-bone features in their rigs. When it comes to rigify, due to its modular approach, becomes pretty easy create a supporting system to expose the user controls that enable visual interaction with b-bones features. The patch seems to work in this path, allowing the riggers to correctly interact with b-bones "handles". So in my opinion is the clearer way to go since the patch basically extends what is the actual usage of b-bones. Overlooking it from a general b-bone design pov, probably a better idea would have been discussing on how making the b-bone system more interactive in the viewport without accessing annoying sliders and multiple f-curve channels, but this in my opinion would be a giant design task and should be addressed by a team of developers in a major release.

Alexander Gavrilov commented

2020-12-18 10:21:40 +01:00

Thing is, the use case of B-Bones as back-end of more complex rigs isn't going away anyway.

Potentially it's possible to streamline things further here e.g. by implementing a new handle type that would use the default connected parent logic for the auto handle part, while allowing the handle to tweak rotation and scale - thus hard-coding and replacing the function of the three handle bones here.

However, complex rigs will still have reason to opt for the full handle bone mechanism because of additional automation. In the actual rigify face chains twist is interpolated along the chain using drivers on the MCH handle bones, and the eye adds constraints to make the chain automatically twist to follow the normal of the eye. That kind of specific automation is definitely out of scope for built-in logic and will still require the full rigging setup.

There is also the issue that the 'offset x/y' properties of the B-Bones aren't the greatest design - you actually need to set them to infinity just to rotate the handles 90 degrees. A separate handle (control) bone with quaternion rotation provides a much better representation.

Thing is, the use case of B-Bones as back-end of more complex rigs isn't going away anyway. Potentially it's possible to streamline things further here e.g. by implementing a new handle type that would use the default connected parent logic for the auto handle part, while allowing the handle to tweak rotation and scale - thus hard-coding and replacing the function of the three handle bones here. However, complex rigs will still have reason to opt for the full handle bone mechanism because of additional automation. In the actual rigify face chains twist is interpolated along the chain using drivers on the MCH handle bones, and the eye adds constraints to make the chain automatically twist to follow the normal of the eye. That kind of specific automation is definitely out of scope for built-in logic and will still require the full rigging setup. There is also the issue that the 'offset x/y' properties of the B-Bones aren't the greatest design - you actually need to set them to infinity just to rotate the handles 90 degrees. A separate handle (control) bone with quaternion rotation provides a much better representation.

Demeter Dzadik commented

2020-12-18 15:36:18 +01:00

I love the BBone scale features!

I'm a bit confused by the axis names though. Y axis has always been the length axis of the bones, as you point out here:

B-Bones only have options for X and Y scale (actually X and Z)

It is actually X and Z. But now in the UI it shows "X, Y, Length". I think keeping it as "Length" is totally fine, it's more clear than any letter would be. But I don't see the reason why it isn't "X, Z, Length" instead. I mean, sure, it is weird, and certainly not how I learned the alphabet either, but the fact that Y has always been the length axis of bones, has always been weird. I think it's better to accept the weirdness than refer to the same axis as both Y and Z in different options.
Ideally I would even go as far as swapping the indices around the python api and UI part of this, so I would expect bbone_handle_scale_start- [x] is X, - [x] is Length and - [x] is Z, and they are displayed as such in the UI, as "X, Length, Z". To me this seems like the lesser evil.
I would also split the Ease value into its own property instead of a 4th entry in that list, I think it would be clearer for addon developers who don't expect to find a 4th entry in a scale list, but perhaps that's just a nitpick.

As for the other features, they seem useful at least in improving the behaviour of bbone chains for face rigs, which is always nice. The growing number of options and UI clutter is a concern. I think to help this, we should choose defaults carefully, to make sure it aligns with the most common use cases. So in this case I feel like bbone_handle_scale_start/end values might want to start out enabled except Ease, but I could be wrong.

I love the BBone scale features! I'm a bit confused by the axis names though. Y axis has always been the length axis of the bones, as you point out here: > B-Bones only have options for X and Y scale (actually X and Z) It is actually X and Z. But now in the UI it shows "X, Y, Length". I think keeping it as "Length" is totally fine, it's more clear than any letter would be. But I don't see the reason why it isn't "X, Z, Length" instead. I mean, sure, it is weird, and certainly not how I learned the alphabet either, but the fact that Y has always been the length axis of bones, has always been weird. I think it's better to accept the weirdness than refer to the same axis as both Y and Z in different options. Ideally I would even go as far as swapping the indices around the python api and UI part of this, so I would expect bbone_handle_scale_start- [x] is X, - [x] is Length and - [x] is Z, and they are displayed as such in the UI, as "X, Length, Z". To me this seems like the lesser evil. I would also split the Ease value into its own property instead of a 4th entry in that list, I think it would be clearer for addon developers who don't expect to find a 4th entry in a scale list, but perhaps that's just a nitpick. As for the other features, they seem useful at least in improving the behaviour of bbone chains for face rigs, which is always nice. The growing number of options and UI clutter is a concern. I think to help this, we should choose defaults carefully, to make sure it aligns with the most common use cases. So in this case I feel like bbone_handle_scale_start/end values might want to start out enabled except Ease, but I could be wrong.

Alexander Gavrilov commented

2020-12-18 16:02:43 +01:00

The naming is very unfortunate, but it all started with the original choice to name properties Curve X and Y, which I copied when splitting Scale into X and Y. Now changing it is a backward compatibility concern involving user habits, python addons (Rigify will have to be changed for one, which is not something to accept lightly given that the timeline when this can go in is completely unclear, and I have to maintain a separate build to work on the rigs) and DNA property renaming. The choice to use 'length' is largely motivated by this: whether Y is renamed to Z or not, it will not be confused with the new length scale setting whether in the UI or by Python code.

Ease is actually very scaling related - if bbones directly used the Bezier parameterization instead of reprocessing to produce an arbitrary (uniform by default) distribution of segment length, changing ease would directly result in segment scaling. Linking Length Scale and Ease to somewhat restore that produces quite natural scaling motion in my perception. That's the reason for the Scale Easing checkbox, and having Length and Ease toggles (and array items) next to each other.

Enabling scale by default is iffy unless I deliberately make the options non-functional in the Automatic and maybe even Absolute modes. They are designed to be used with actual handles, not within auto-linked bbone chains.

P.S. I'm not against renaming the y properties to z, but as a separate patch that has to go either before all this, or after, so that Rigify can be immediately updated in master without having to branch and maintain that too.

The naming is very unfortunate, but it all started with the original choice to name properties Curve X and ***Y***, which I copied when splitting Scale into X and Y. Now changing it is a backward compatibility concern involving user habits, python addons (Rigify will have to be changed for one, which is not something to accept lightly given that the timeline when this can go in is completely unclear, and I have to maintain a separate build to work on the rigs) and DNA property renaming. The choice to use 'length' is largely motivated by this: whether Y is renamed to Z or not, it will not be confused with the new length scale setting whether in the UI or by Python code. Ease is actually very scaling related - if bbones directly used the Bezier parameterization instead of reprocessing to produce an arbitrary (uniform by default) distribution of segment length, changing ease would directly result in segment scaling. Linking Length Scale and Ease to somewhat restore that produces quite natural scaling motion in my perception. That's the reason for the Scale Easing checkbox, and having Length and Ease toggles (and array items) next to each other. Enabling scale by default is iffy unless I deliberately make the options non-functional in the Automatic and maybe even Absolute modes. They are designed to be used with actual handles, not within auto-linked bbone chains. P.S. I'm not against renaming the y properties to z, but as a separate patch that has to go either before all this, or after, so that Rigify can be immediately updated in master without having to branch and maintain that too.

Sybren A. Stüvel commented

2021-03-15 18:01:11 +01:00

Added subscriber: @pepe-school-land

Sybren A. Stüvel commented

2021-03-15 18:01:11 +01:00

@jpbouza-4 and @pepe-school-land: you were involved in the original Bendy Bones development (49aeee5a3d). What do you think of this proposal?

@jpbouza-4 and @pepe-school-land: you were involved in the original Bendy Bones development (49aeee5a3d). What do you think of this proposal?

Juan Pablo Bouza commented

2021-03-16 01:28:53 +01:00

Hi @dr.sybren! Well, I have been involved in many of the discussions regarding these features. I would welcome any improvement in bbones as there is a lot of space for that. These features look really nice, as they simplify the setup and at the same time they enable us to add more complexity to the deformation of bbones.

I think that in the case of bbones, there is room for making the UI more complex, as we don't have so many options and all the current options basically do the same thing but in different axes.

Changing the name of the Y axis to Z would be a desired change as it's hard to remember what the Y axis actually represents for bbones. Also, if Alexander adds the real "Y scaling" feature, I think it would be a necessary change. The thing is that losing backwards compatibility would be bad, but anyway, I would be willing to fix my rigs manually.

Hi @dr.sybren! Well, I have been involved in many of the discussions regarding these features. I would welcome any improvement in bbones as there is a lot of space for that. These features look really nice, as they simplify the setup and at the same time they enable us to add more complexity to the deformation of bbones. I think that in the case of bbones, there is room for making the UI more complex, as we don't have so many options and all the current options basically do the same thing but in different axes. Changing the name of the Y axis to Z would be a desired change as it's hard to remember what the Y axis actually represents for bbones. Also, if Alexander adds the real "Y scaling" feature, I think it would be a necessary change. The thing is that losing backwards compatibility would be bad, but anyway, I would be willing to fix my rigs manually.

Sybren A. Stüvel commented

2021-03-16 09:56:16 +01:00

In #83908#1130196, @jpbouza-4 wrote:
Hi @dr.sybren! Well, I have been involved in many of the discussions regarding these features. I would welcome any improvement in bbones as there is a lot of space for that. These features look really nice, as they simplify the setup and at the same time they enable us to add more complexity to the deformation of bbones.

👍

Changing the name of the Y axis to Z would be a desired change as it's hard to remember what the Y axis actually represents for bbones. Also, if Alexander adds the real "Y scaling" feature, I think it would be a necessary change. The thing is that losing backwards compatibility would be bad, but anyway, I would be willing to fix my rigs manually.

My gut feeling says that this should be possible to do with at least some degree of backwards compatibility, at least for blend files. Scripts would need updating, of course.

> In #83908#1130196, @jpbouza-4 wrote: > Hi @dr.sybren! Well, I have been involved in many of the discussions regarding these features. I would welcome any improvement in bbones as there is a lot of space for that. These features look really nice, as they simplify the setup and at the same time they enable us to add more complexity to the deformation of bbones. :+1: > Changing the name of the Y axis to Z would be a desired change as it's hard to remember what the Y axis actually represents for bbones. Also, if Alexander adds the real "Y scaling" feature, I think it would be a necessary change. The thing is that losing backwards compatibility would be bad, but anyway, I would be willing to fix my rigs manually. My gut feeling says that this should be possible to do with at least some degree of backwards compatibility, at least for blend files. Scripts would need updating, of course.

Demeter Dzadik commented

2021-03-16 11:37:30 +01:00

I would be okay with having to run a few search&replaces along the lines of "scaleiny"->"scaleinz" on my repositories if that's what we're talking about.

Backwards comp break for rigs I hope wouldn't be involved indeed... 👀

I would be okay with having to run a few search&replaces along the lines of "scaleiny"->"scaleinz" on my repositories if that's what we're talking about. Backwards comp break for rigs I hope wouldn't be involved indeed... :eyes:

Alexander Gavrilov commented

2021-03-16 11:58:08 +01:00

In #83908#1130395, @dr.sybren wrote:
My gut feeling says that this should be possible to do with at least some degree of backwards compatibility, at least for blend files. Scripts would need updating, of course.

Oh, renaming Y to Z is possible and not that hard. What I think should absolutely be avoided is calling the new length oriented property Y, because it will lead to a situation where old scripts would seem to work, but produce incorrect results - thus the Len naming that is distinct both from Y and Z.

Alternatively maybe the properties should be changed to be arrays of 3 elements, but that would be a way bigger task than just renaming.

> In #83908#1130395, @dr.sybren wrote: > My gut feeling says that this should be possible to do with at least some degree of backwards compatibility, at least for blend files. Scripts would need updating, of course. Oh, renaming Y to Z is possible and not that hard. What I think should absolutely be avoided is calling the new length oriented property Y, because it will lead to a situation where old scripts would seem to work, but produce incorrect results - thus the Len naming that is distinct both from Y and Z. Alternatively maybe the properties should be changed to be arrays of 3 elements, but that would be a way bigger task than just renaming.

Sybren A. Stüvel commented

2021-03-19 13:09:47 +01:00

In #83908#1130482, @angavrilov wrote:
Alternatively maybe the properties should be changed to be arrays of 3 elements, but that would be a way bigger task than just renaming.

I find it an interesting one, though. It would mean these translation rules:

curve_inx → curve_in.x
curve_iny → curve_in.z

Because of the latter, it will still be possible to detect such mistakes later.

For me the scope of this task (looking at the task description here) is not quite clear yet. It starts by mentioning that the BBone design has its limitations (fair enough), but then discusses all kinds of rig changes and talks about different constraint options. I don't see a section that comes back to the original topic of the task to summarize the changes needed in the BBone design.

> In #83908#1130482, @angavrilov wrote: > Alternatively maybe the properties should be changed to be arrays of 3 elements, but that would be a way bigger task than just renaming. I find it an interesting one, though. It would mean these translation rules: - `curve_inx` → `curve_in.x` - `curve_iny` → `curve_in.z` Because of the latter, it will still be possible to detect such mistakes later. ---- For me the scope of this task (looking at the task description here) is not quite clear yet. It starts by mentioning that the BBone design has its limitations (fair enough), but then discusses all kinds of rig changes and talks about different constraint options. I don't see a section that comes back to the original topic of the task to summarize the changes needed in the BBone design.

Alexander Gavrilov commented

2021-03-19 14:03:43 +01:00

In #83908#1132537, @dr.sybren wrote:

In #83908#1130482, @angavrilov wrote:
Alternatively maybe the properties should be changed to be arrays of 3 elements, but that would be a way bigger task than just renaming.

I find it an interesting one, though. It would mean these translation rules:

The trouble is that while there is a standard mechanism to support simple field renaming in DNA, changing the type is not really possible. As far as I know there are only two approaches:

Add new array fields to DNA while keeping the legacy ones, and add versioning code to copy data. The legacy fields would have to remain as long as backward compatibility is necessary.
Only convert the exposed RNA (Python) fields by using custom read/write callbacks, keeping DNA as separate fields.

Maybe somebody more knowledgeable in DNA could suggest something else, but these are my only ideas.

> In #83908#1132537, @dr.sybren wrote: >> In #83908#1130482, @angavrilov wrote: >> Alternatively maybe the properties should be changed to be arrays of 3 elements, but that would be a way bigger task than just renaming. > I find it an interesting one, though. It would mean these translation rules: The trouble is that while there is a standard mechanism to support simple field renaming in DNA, changing the type is not really possible. As far as I know there are only two approaches: * Add new array fields to DNA while keeping the legacy ones, and add versioning code to copy data. The legacy fields would have to remain as long as backward compatibility is necessary. * Only convert the exposed RNA (Python) fields by using custom read/write callbacks, keeping DNA as separate fields. Maybe somebody more knowledgeable in DNA could suggest something else, but these are my only ideas.

Mikhail Vigovskiy commented

2021-05-19 12:44:28 +02:00

Added subscriber: @upliner

Tristan commented

2021-05-27 20:43:13 +02:00

Added subscriber: @Plyro

Hadrien Brissaud commented

2021-05-30 15:58:47 +02:00

Added subscriber: @hadrien

Hadrien Brissaud commented

2021-05-30 15:58:47 +02:00

This can be done with two additional bones per handle and control pair:

A child of the control, oriented the same as the handle in rest pose, without constraints.
A sibling of the control, oriented the same as the handle in rest pose, with a Copy Transforms (World Space) from child.

This is what I have been doing so far with my bbone rigs, happy to know this is indeed the "recommended" way. It seemed overly complicated but I couldn't make it work in a simpler way.
On paper, we're basically looking for the effect of a parent-child relationship between the control and the handle... but since the spot is already taken, we need such a constraint to ignore all transforms inherited from the control's parent bone too, because that would result in double transforms. I am not entirely sure what this translates to in matrix math terms, but that's the idea anyway.

(reworded for clarity)

"Transformation transfer has to be done via a constraint that is executed after the auto handle emulation, because Damped Track completely overwrites rotation.

As a corollary, I suggest rounding up these constraints (copy transforms, damped track, and a handful of others iirc) and change them so they add to the transforms they're working on, instead of overwriting them. Right now constraints behave inconsistently in that regard and the consequence of that is often surnumerary bones, which contribute to a needlessly more complex rig.

> This can be done with two additional bones per handle and control pair: > > A child of the control, oriented the same as the handle in rest pose, without constraints. > A sibling of the control, oriented the same as the handle in rest pose, with a Copy Transforms (World Space) from child. This is what I have been doing so far with my bbone rigs, happy to know this is indeed the "recommended" way. It seemed overly complicated but I couldn't make it work in a simpler way. On paper, we're basically looking for the effect of a parent-child relationship between the control and the handle... but since the spot is already taken, we need such a constraint to ignore all transforms inherited from the control's parent bone too, because that would result in double transforms. I am not entirely sure what this translates to in matrix math terms, but that's the idea anyway. (reworded for clarity) > "Transformation transfer has to be done via a constraint that is executed after the auto handle emulation, because Damped Track completely overwrites rotation. As a corollary, I suggest rounding up these constraints (copy transforms, damped track, and a handful of others iirc) and change them so they *add to* the transforms they're working on, instead of overwriting them. Right now constraints behave inconsistently in that regard and the consequence of that is often surnumerary bones, which contribute to a needlessly more complex rig.

Andy Cuccaro commented

2021-06-02 00:49:14 +02:00

Added subscriber: @AndyCuccaro

blender-admin commented

2021-06-05 14:47:11 +02:00

This issue was referenced by edaaa2afdd

This issue was referenced by edaaa2afddb2132e56f39791e559b084b6df8773

Sybren A. Stüvel commented

2021-06-07 12:05:02 +02:00

Moving this to the Short Term workboard as discussed in the 2021-05-27 Animation & Rigging module meeting.

Moving this to the Short Term workboard as discussed in the [2021-05-27 Animation & Rigging module meeting](https://devtalk.blender.org/t/2021-05-27-animation-rigging-module-meeting/18846).

Paul Larson commented

2021-06-08 22:55:05 +02:00

Added subscriber: @GeorgiaPacific