Page MenuHome

Limit rotation for transform constraint (local) bug
Closed, InvalidPublicKNOWN ISSUE

Description

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.

Event Timeline

Henrik Dick (weasel) renamed this task from Limit rotation for transform constraint bug to Limit rotation for transform constraint (local) bug.Wed, Mar 25, 6:39 PM
Henrik Dick (weasel) updated the task description. (Show Details)
Sybren A. Stüvel (sybren) changed the task status from Needs Triage to Needs Information from User.Thu, Mar 26, 8:56 AM

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 Dick (weasel) changed the task status from Needs Information from User to Needs Triage.Fri, Mar 27, 8:32 PM
Henrik Dick (weasel) updated the task description. (Show Details)

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

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 (sybren) claimed this task.

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.

Sybren A. Stüvel (sybren) changed the subtype of this task from "Report" to "Known Issue".Mon, Mar 30, 4:03 PM

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.