With basic.super_copy types, limit transform constraints don't get passed on to controllers. #90288

Open
opened 2021-07-29 09:20:56 +02:00 by Beorn Leonard · 10 comments

Addon Information
Name: Rigify (0, 6, 3)
Author: Nathan Vegdahl, Lucio Rossi, Ivan Cappiello, Alexander Gavrilov

Short description of error
When using a any of the limit rotation, limit location or limit scale constraints on basic.super_copy rig types, the constraints only get applied to the ORG bone, and not the controller.
This messes with any other bones that may be driven by the main bone, as the driver points to the controller in the generated rig, and not the ORG bone.
It also means the controllers move beyond the deformation, which looks weird.

Surely it makes sense to apply the limit transform constraints to the control bones instead of (or as well as) the ORG bones?

Exact steps for others to reproduce the error
Create a single bone rig.
Add a second bone and make one of it's transform channels driven by a transform channel on the first bone.
On the first bone, add a limit constraint to whatever transform you are using to drive the second bone.
Make the first bone a basic.super_copy rigify type, and the second one a basic.raw_copy.
Generate the rig.

In the newly generated rig, the first controller will drive the second bone, and will continue driving it beyond the limits set in the limit constraint.

**Addon Information** Name: Rigify (0, 6, 3) Author: Nathan Vegdahl, Lucio Rossi, Ivan Cappiello, Alexander Gavrilov **Short description of error** When using a any of the limit rotation, limit location or limit scale constraints on basic.super_copy rig types, the constraints only get applied to the ORG bone, and not the controller. This messes with any other bones that may be driven by the main bone, as the driver points to the controller in the generated rig, and not the ORG bone. It also means the controllers move beyond the deformation, which looks weird. Surely it makes sense to apply the limit transform constraints to the control bones instead of (or as well as) the ORG bones? **Exact steps for others to reproduce the error** Create a single bone rig. Add a second bone and make one of it's transform channels driven by a transform channel on the first bone. On the first bone, add a limit constraint to whatever transform you are using to drive the second bone. Make the first bone a basic.super_copy rigify type, and the second one a basic.raw_copy. Generate the rig. In the newly generated rig, the first controller will drive the second bone, and will continue driving it beyond the limits set in the limit constraint.
Author

Added subscriber: @BeornLeonard

Added subscriber: @BeornLeonard
Member

Added subscriber: @OmarEmaraDev

Added subscriber: @OmarEmaraDev
Member

Changed status from 'Needs Triage' to: 'Needs User Info'

Changed status from 'Needs Triage' to: 'Needs User Info'
Member

The limit constraint does take effect on the second bone indirectly through the copy constrain on the ORG bone for me. Is the your issue with the fact that the controller doesn't also get the same limit constraint?

20220322-165311.mp4

The limit constraint does take effect on the second bone indirectly through the copy constrain on the ORG bone for me. Is the your issue with the fact that the controller doesn't also get the same limit constraint? [20220322-165311.mp4](https://archive.blender.org/developer/F12940093/20220322-165311.mp4)
Member

Just a poke regarding my inquiry above, otherwise, we will have to archive this for now.

Just a poke regarding my inquiry above, otherwise, we will have to archive this for now.
Author

Sorry Omar,
Yes that is the issue. It means that when you're animating, you can move the controller further than it should go, and thus your anim curves will bare no relation to what's actually happening to the deformation.
I'll admit it's not the hugest problem, but it's also not ideal.

A suggested behavior would be to apply the limit constraint to the controller rather than the ORG bone when "Affect transform" is checked.
This is when the rigger is explicitly specifying that the controller can't be animated outside of its limits.

Sorry Omar, Yes that is the issue. It means that when you're animating, you can move the controller further than it should go, and thus your anim curves will bare no relation to what's actually happening to the deformation. I'll admit it's not the hugest problem, but it's also not ideal. A suggested behavior would be to apply the limit constraint to the controller rather than the ORG bone when "Affect transform" is checked. This is when the rigger is explicitly specifying that the controller can't be animated outside of its limits.
Member

Changed status from 'Needs User Info' to: 'Needs Developer To Reproduce'

Changed status from 'Needs User Info' to: 'Needs Developer To Reproduce'
Member

Okay, thanks for the input. I will wait for the developers then.

Okay, thanks for the input. I will wait for the developers then.

Added subscriber: @Muncho

Added subscriber: @Muncho
Christoph Lendenfeld added
Status
Confirmed
Type
Bug
and removed
Status
Needs Info from Developers
Type
Report
labels 2023-10-10 10:51:31 +02:00

affect transform has been fixed here: #112601: Fix #112580: Limit Constraint with 'Affect Transform' not working properly in 'World Space'

however the issue with rigify not adding the limit constraint to the controller still remains

affect transform has been fixed here: [#112601: Fix #112580: Limit Constraint with 'Affect Transform' not working properly in 'World Space'](https://projects.blender.org/blender/blender/pulls/112601) however the issue with rigify not adding the limit constraint to the controller still remains
Sign in to join this conversation.
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender-addons#90288
No description provided.