Page MenuHome

Copy Rotation Constraint - adding rotations causes unexpected behaviour
Confirmed, LowPublicKNOWN ISSUE

Description

System Information
Operating system: Windows
Graphics card: GTX 1650 Max-Q`

Blender Version
Broken: v2.81a, v2.81, v2.82

Short description of error
When adding a Copy Rotation constraint to an object, the Add mode seems to not work correctly
(or at least how I would expect it to work). For example, setting the rotation of the object to (x,x,x) and
the target to (-x, -x, -x) does not consistently result in having no net effect. The value for which this *stops*
working is x >= 54.

Exact steps for others to reproduce the error
1 - Add an object, give it a rotation of (80, 80, 80), Euler XYZ (default)
2 - Add an empty, give it a rotation of (-80, -80, -80)
3 - Add a Copy rotation constraint on the object, and set the target to empty

The included bug.blend file contains an animation that goes over the values of x as described in the
above example from 0-100. The problem can be seen around halfway through the animation at the
critical value above.

Result
Object seems to have a weird rotation, which is not the expected outcome. The same happens
when only one of the axes is rotated more, and also when they don't necessarily add up to 0.

This has been tested on multiple Windows machines.

Event Timeline

Mustafa Quraish (mustafaquraish) renamed this task from Copy Rotation Constraint - Adding rotations to Copy Rotation Constraint - adding rotations causes unexpected behaviour.Feb 27 2020, 8:45 PM
Germano Cavalcante (mano-wii) changed the task status from Needs Triage to Confirmed.Feb 28 2020, 12:13 PM
Germano Cavalcante (mano-wii) triaged this task as Low priority.
Germano Cavalcante (mano-wii) changed the subtype of this task from "Report" to "Bug".

Euler rotation is not very reliable to obtain a final position. Partly because you have to follow an order when applying the values.
And here we need to be concerned with 3 orders. The one for the Cube, the one for the Cylinder and the one indicated in the Constraint.

But it is interesting to see in the file that the constraint seems to work as expected before the angle value reaches 55.3.
I think it deserves an investigation.

Germano Cavalcante (mano-wii) changed the subtype of this task from "Bug" to "Known Issue".Feb 28 2020, 1:15 PM

Observing the code I could see that Constraint does not directly use the Euler values of the object, but generates then from the matrix of each object (because they can be modified by other constraints).
However, for the same final position, two Euler values are possible. One is the same set by the user and the other is different. The constraint chooses Euler values that are less different between themselves.

Given the limitations of Euler, I don't see how to indicate to the constraint which of the values should be used. So I don't think we can solve this problem (unless we remove this constraint).

@Germano Cavalcante (mano-wii) "Given the limitations of Euler, I don't see how to indicate to the constraint which of the values should be used. So I don't think we can solve this problem (unless we remove this constraint)."

Is there a way for the User to choose manually?

I.e. Could a manual toggle switch be used as a temporary fix until the code can be overhauled? Or in a drop down menu? See pic.

https://i.imgur.com/LdUz2s1.gif