Page MenuHome

Incorrect rotation using driver or constraint
Confirmed, NormalPublicKNOWN ISSUE

Description

System Information
Operating system: Windows-7-6.1.7601-SP1 64 Bits
Graphics card: GeForce GTX 750 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 388.13

Blender Version
2.79, 2.80, 2.81, 2.82, 2.83

Short description of error

Bone "target" is animated on y-axis.
"Target" turned close to gimbal lock gives the wrong result for Transformation constraint, Copy Rotation constraint, Driver.
Using the driver, you can see how the radian (degrees) value jumps and does not match the value of the target object.
Only using the driver via copy data path creates the correct result.

Event Timeline

Roman (roman13) renamed this task from Wrong rotation Driver and Constraints to Incorrect rotation using driver or constraint.Jul 21 2020, 10:57 AM
Richard Antalik (ISS) changed the task status from Needs Triage to Confirmed.Jul 22 2020, 6:49 AM

@Roman (roman13) In the future, please don't use GIF for videos. What is called a "gif" on modern websites is usually video file. H.264 in an MP4 container works fine for browsers, and is of higher image quality & smaller file size than GIF. It's nice to have a demo video that shows the issue, but modern video codecs are way better at that ;-)

This comment was removed by Roman (roman13).

I did some digging, and it seems to be caused by limitations of Euler angles.

Try this in Blender's Python Console:

>>> e26 = Euler((0.783653, 2.10281, 4.45932), 'YZX')
>>> e26.to_matrix().to_euler('YZX')
Euler((0.7836530208587646, 2.1028099060058594, -1.8238651752471924), 'YZX')

>>> e27 = Euler((0.783653, 2.18692, 4.45932), 'YZX')
>>> e27.to_matrix().to_euler('YZX')
Euler((-2.3579397201538086, -0.954672634601593, -1.3177274465560913), 'YZX')

Here e26 and e27 are the Euler angles of the target bone on frames 26 (before the jump in orientation) and 27 (after the jump in orientation) in radians. Converting them to a matrix and then back to Euler angles shows the issue: a small change in Y-angle results in a big change in the result. The same happens when converting from Eulers to quaternions and back.

The difference between the various approaches is that the "Copy Data Path" approach literally takes the Y euler rotation as-is. All the others first convert the rotation to a matrix, convert that matrix to whatever space is desired, convert it to Euler angles again, and and then take the value from that.

It could be argued that there could be some shortcuts in this process, to avoid unnecessary conversions. However, this would only apply to very specific cases (only local space, and no change in the order of angle evaluation), and could thus cause confusion in other areas. It could also break existing files, unless yet more options are added.

I found a discrepancy. I know the Y axis rotates in local coordinates, but I animated the X axis and for some reason the bone rotates with a constant in world space coordinate.


At a certain angle of rotation, Flip rotation also appears

Sybren A. Stüvel (sybren) triaged this task as Low priority.Aug 13 2020, 10:19 AM
Sybren A. Stüvel (sybren) changed the subtype of this task from "Report" to "Known Issue".

That just looks like another gimbal lock to me.

I'm marking this as known issue as it seems to be a side-effect of how Blender handles space transformations, and not a bug in the implementation. As I said before, it might be possible to implement some shortcuts in the space conversion functions so that the conversion to matrix and back is avoided, but this requires very careful planning in order to not break existing files.

Sybren A. Stüvel (sybren) raised the priority of this task from Low to Normal.Aug 13 2020, 10:20 AM
Sybren A. Stüvel (sybren) moved this task from Backlog to Long-Term on the Animation & Rigging board.