Limit rotation for transform constraint (local) bug #75078

New Issue

Henrik D. · 2020-03-25T17:52:34+01:00

Henrik D. commented

2020-03-25 17:52:34 +01:00

System Information
Operating system: Linux (Debian bullseye)

Blender Version
Broken: at least 2.79b up to current master (2.83.10)
Worked: I didn't test anything older than 2.79b, but that version didn't work already

Short description of error
The following only really applies to local transform selected in the limit rotation constraint,
and therefore only for Bones and Objects that have a parent. Objects without a parent seem
to disable the constraint entirely instead of using world space (also since 2.79b and probably before).

The Limit Rotation constraint with "For Transform" turned on will not apply the
limit on the transform in special cases. If the XYZ Euler is at one of the rotations that
can be expressed in multiple ways, it will prefer one over the other internally before
the limiting is done. This is very counter intuitive and should be considered a bug
when the checkbox says for transform and also works like that for most cases.

To add on top of that, if the rotation mode is not XYZ Euler it really doesn't work.
It will still use some internal rotation and clamp that, while the numbers in the rotation
transform UI will go wild. At least if for transform is toggled on, it should use the
selected rotation representation.

Exact steps for others to reproduce the error
Open up the attached blend file with the armature and tweak the Y-Rotation of the selected Bone.
You should see a sudden unexpected jump.
rotlimitbug.blend

**System Information** Operating system: Linux (Debian bullseye) **Blender Version** Broken: at least 2.79b up to current master (2.83.10) Worked: I didn't test anything older than 2.79b, but that version didn't work already **Short description of error** The following only really applies to local transform selected in the limit rotation constraint, and therefore only for Bones and Objects that have a parent. Objects without a parent seem to disable the constraint entirely instead of using world space (also since 2.79b and probably before). The Limit Rotation constraint with "For Transform" turned on will not apply the limit on the transform in special cases. If the XYZ Euler is at one of the rotations that can be expressed in multiple ways, it will prefer one over the other internally before the limiting is done. This is very counter intuitive and should be considered a bug when the checkbox says for transform and also works like that for most cases. To add on top of that, if the rotation mode is not XYZ Euler it really doesn't work. It will still use some internal rotation and clamp that, while the numbers in the rotation transform UI will go wild. At least if for transform is toggled on, it should use the selected rotation representation. **Exact steps for others to reproduce the error** Open up the attached blend file with the armature and tweak the Y-Rotation of the selected Bone. You should see a sudden unexpected jump. [rotlimitbug.blend](https://archive.blender.org/developer/F8430799/rotlimitbug.blend)

Henrik D. commented

2020-03-25 17:52:34 +01:00

Added subscriber: @HDMaster84

Henrik D. commented

2020-03-25 17:52:52 +01:00

No description provided.

Henrik D. changed title from ~~Limit rotation for transform constraint bug~~ to Limit rotation for transform constraint (local) bug

2020-03-25 18:39:45 +01:00

Sybren A. Stüvel commented

2020-03-26 08:56:42 +01:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2020-03-26 08:56:42 +01:00

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

Sybren A. Stüvel commented

2020-03-26 08:56:42 +01:00

Worked: I didn't test anything older than 2.82a

Please spend some time to figure out whether this is a newly-introduced issue or has been in Blender for longer. This will help the developers to address this faster.

> Worked: I didn't test anything older than 2.82a Please spend some time to figure out whether this is a newly-introduced issue or has been in Blender for longer. This will help the developers to address this faster.

Henrik D. commented

2020-03-27 20:32:37 +01:00

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

Ankit Meel commented

2020-03-28 16:03:50 +01:00

Added subscriber: @ankitm

Ankit Meel commented

2020-03-28 16:03:50 +01:00

report seems correct, as an edge case.
What should be the output @HDMaster84 ? not momentarily bump up the bone while going from 89 to 91 ?

report seems correct, as an edge case. What *should* be the output @HDMaster84 ? not momentarily bump up the bone while going from 89 to 91 ?

Henrik D. commented

2020-03-28 18:18:14 +01:00

From the Manual (https://docs.blender.org/manual/en/latest/animation/constraints/transform/limit_rotation.html)

For Transform

We saw that by default, even though visually constrained, the owner can still have rotations
out of bounds (as shown by the Transform panel). Well, when you enable this button, this is no
more possible – the owner transform properties are also limited by the constraint. Note
however, that the constraint does not directly modifies the rotation values: you have to rotate
one way or the other its owner, for this to take effect…

So I would expect first, that there is no bump in between 89 and 91 in the scenario I have given and
second that it would do it for the transform in the mode set for the transform (XYZ Euler, ZYX Euler or
whatever), which would go hand in hand (I think one can not be achieved without the other being at least
partially fixed). If that setting is set to Quaternion or Axis Angle, then the current behaviour is fine, since
it just works differently mathematically.

I suspect that the limit rotation constraint currently uses the rotation matrix or quaternion to limit
the rotation by first converting it to XYZ Euler, then doing the limiting and then converting it back.

I didn't look into the code but I think there is two ways to handle this better (fixing the problem)

If the rotation mode setting is set to some Euler, make it use the inital Euler values and mode for limiting.
Add an option to the limit rotation constraint for the rotation mode used by it

 (which would give more flexibility, but would not fix this the gimbal lock problem, but instead a
 euler order can be selected than has he gimbal lock at a different rotation)

This will increase stability when using the limit rotation constraints and make it possible to use
it for example for hands, as there the best Euler Order seems to be XZY or ZXY when limiting
is wanted. (Without limiting, Quaternions would be better for smooth interpolation I guess)

From the Manual (https://docs.blender.org/manual/en/latest/animation/constraints/transform/limit_rotation.html) > For Transform > > We saw that by default, even though visually constrained, the owner can still have rotations > out of bounds (as shown by the Transform panel). Well, when you enable this button, this is no > more possible – the owner transform properties are also limited by the constraint. Note > however, that the constraint does not directly modifies the rotation values: you have to rotate > one way or the other its owner, for this to take effect… So I would expect first, that there is no bump in between 89 and 91 in the scenario I have given and second that it would do it for the transform in the mode set for the transform (XYZ Euler, ZYX Euler or whatever), which would go hand in hand (I think one can not be achieved without the other being at least partially fixed). If that setting is set to Quaternion or Axis Angle, then the current behaviour is fine, since it just works differently mathematically. I suspect that the limit rotation constraint currently uses the rotation matrix or quaternion to limit the rotation by first converting it to XYZ Euler, then doing the limiting and then converting it back. I didn't look into the code but I think there is two ways to handle this better (fixing the problem) 1. If the rotation mode setting is set to some Euler, make it use the inital Euler values and mode for limiting. 2. Add an option to the limit rotation constraint for the rotation mode used by it ``` (which would give more flexibility, but would not fix this the gimbal lock problem, but instead a euler order can be selected than has he gimbal lock at a different rotation) ``` This will increase stability when using the limit rotation constraints and make it possible to use it for example for hands, as there the best Euler Order seems to be XZY or ZXY when limiting is wanted. (Without limiting, Quaternions would be better for smooth interpolation I guess)

Sybren A. Stüvel commented

2020-03-30 16:02:55 +02:00

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

Sybren A. Stüvel closed this issue

2020-03-30 16:02:55 +02:00

Sybren A. Stüvel self-assigned this 2020-03-30 16:02:55 +02:00

Sybren A. Stüvel commented

2020-03-30 16:02:55 +02:00

I suspect that the limit rotation constraint currently uses the rotation matrix or quaternion to limit the rotation by first converting it to XYZ Euler, then doing the limiting and then converting it back.

This is correct, you can see it in the rotlimit_evaluate() function in constraint.c. The entire constraint system is based on matrices; each constraint receives a matrix, and outputs a matrix. Due to that design, such gimbal lock issues are unavoidable.

So yes, it's annoying, but it's an intrinsic limitation of Blender's current design, and thus not considered a bug.

> I suspect that the limit rotation constraint currently uses the rotation matrix or quaternion to limit the rotation by first converting it to XYZ Euler, then doing the limiting and then converting it back. This is correct, you can see it in the `rotlimit_evaluate()` function in [constraint.c](https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/constraint.c). The entire constraint system is based on matrices; each constraint receives a matrix, and outputs a matrix. Due to that design, such gimbal lock issues are unavoidable. So yes, it's annoying, but it's an intrinsic limitation of Blender's current design, and thus not considered a bug.

Sybren A. Stüvel commented

2020-03-30 16:05:49 +02:00

PS: I added this issue to my personal list of weak areas of the animation system, as I do think this would be interesting to properly tackle at some point.

PS: I added this issue to my personal [list of weak areas of the animation system](https://wiki.blender.org/wiki/User:Sybren/Animation_Weak_Areas#Matrix-based_constraint_system), as I do think this would be interesting to properly tackle at some point.

Vyacheslav Kobozev commented

2020-04-14 00:26:53 +02:00

Added subscriber: @Vyach

Vyacheslav Kobozev commented

2020-04-14 00:26:53 +02:00

@dr.sybren
At least, for a time, there shoul be limits -180 — 180 for input fields in Limit rotation constraint. It will confuse less.

@dr.sybren At least, for a time, there shoul be limits -180 — 180 for input fields in Limit rotation constraint. It will confuse less.

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

Limit rotation for transform constraint (local) bug #75078