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

New Issue

Beorn Leonard · 2021-07-29T09:20:56+02:00

Beorn Leonard commented

2021-07-29 09:20:56 +02:00

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.

Beorn Leonard commented

2021-07-29 09:20:56 +02:00

Added subscriber: @BeornLeonard

Omar Emara commented

2022-03-22 15:56:01 +01:00

Added subscriber: @OmarEmaraDev

Omar Emara commented

2022-03-22 15:56:01 +01:00

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

Omar Emara commented

2022-03-22 15:56:01 +01:00

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)

Omar Emara commented

2022-04-05 11:41:30 +02:00

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

Beorn Leonard commented

2022-04-05 11:57:01 +02:00

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.

Omar Emara commented

2022-04-05 12:22:53 +02:00

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

Omar Emara commented

2022-04-05 12:22:53 +02:00

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

Michael Bell commented

2022-12-03 13:42:23 +01:00

Added subscriber: @Muncho

Christoph Lendenfeld added

and removed

Needs Info from Developers

Type

Report

labels 2023-10-10 10:51:31 +02:00

Christoph Lendenfeld commented

2023-10-10 10:52:41 +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 Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

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