Copy Rotation Constraint unexpectedly have numerical instability #102679

New Issue

Carlo Andreacchio · 2022-11-22T04:46:10+01:00

Carlo Andreacchio commented

2022-11-22 04:46:10 +01:00

Simplified Report

Add a reference object with rotation (X: 91, Y: 0, Z: 180).
Add an object with a Copy Rotation Constraint with the reference object as a target, constraint to the Z component.
Rotate the reference object very slightly along the Z axis.
Notice how it is unstable and inverts itself.
The copying happens from the global space to the global space, so such numerical instability in unexpected.

incorrectCopyRotationConstraint.blend

Original Report

System Information
Operating system: Windows 10, x64
Graphics card: GTX 1080

Blender Version
Broken: e05e1e3691, cac3e16cfb, 0759f671ce

Short description of error
Copy rotation from camera is inconsistant

Exact steps for others to reproduce the error

Open attached blend file
Press play
Notice how the arrow, flips 180 degrees
change teh target from asdfasd to Text.001
notice how the arrow now is normal

Text.001 and asdfasd have linked animation, so they should essentially be the same.
constraintBug_v001.blend

## Simplified Report - Add a reference object with rotation (X: 91, Y: 0, Z: 180). - Add an object with a Copy Rotation Constraint with the reference object as a target, constraint to the Z component. - Rotate the reference object very slightly along the Z axis. - Notice how it is unstable and inverts itself. - The copying happens from the global space to the global space, so such numerical instability in unexpected. [incorrectCopyRotationConstraint.blend](https://archive.blender.org/developer/F13960400/incorrectCopyRotationConstraint.blend) ## Original Report **System Information** Operating system: Windows 10, x64 Graphics card: GTX 1080 **Blender Version** Broken: e05e1e3691, cac3e16cfb, 0759f671ce **Short description of error** Copy rotation from camera is inconsistant **Exact steps for others to reproduce the error** 1. Open attached blend file 2. Press play 3. Notice how the arrow, flips 180 degrees 4. change teh target from asdfasd to Text.001 5. notice how the arrow now is normal Text.001 and asdfasd have linked animation, so they should essentially be the same. [constraintBug_v001.blend](https://archive.blender.org/developer/F13958508/constraintBug_v001.blend)

Carlo Andreacchio commented

2022-11-22 04:46:10 +01:00

Added subscriber: @candreacchio

Carlo Andreacchio changed title from ~~Blender 3.2.1 - Copy Rotation from Camera inconsistant~~ to Blender 3.2.1 - Copy Rotation Constraint from Camera inconsistant

2022-11-22 04:46:34 +01:00

Omar Emara changed title from ~~Blender 3.2.1 - Copy Rotation Constraint from Camera inconsistant~~ to Copy Rotation Constraint unexpectedly have numerical instability

2022-11-22 13:42:23 +01:00

Omar Emara commented

2022-11-22 13:42:23 +01:00

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

Carlo Andreacchio commented

2022-11-22 21:44:24 +01:00

Thanks for the extra reference of this happening.

Whats even crazier, is with your extra file, if you select suzanne (that has the constraint). and then set the rotation to 4 degrees on the z axis... then it will invert.

Thanks for the extra reference of this happening. Whats even crazier, is with your extra file, if you select suzanne (that has the constraint). and then set the rotation to 4 degrees on the z axis... then it will invert.

Christoph Lendenfeld commented

2022-11-23 10:06:29 +01:00

Added subscriber: @ChrisLend

Christoph Lendenfeld commented

2022-11-23 10:06:29 +01:00

Can confirm, there seems to be an edge case.
I'd assume it is euler locking but none of the rotation order options seem to do anything

Edit: On the other hand, this might be working as intended
it is a bit clearer when you switch the cube with a suzanne like in this file
incorrectCopyRotationConstraint.blend

Can confirm, there seems to be an edge case. I'd assume it is euler locking but none of the rotation order options seem to do anything Edit: On the other hand, this might be working as intended it is a bit clearer when you switch the cube with a suzanne like in this file [incorrectCopyRotationConstraint.blend](https://archive.blender.org/developer/F13962776/incorrectCopyRotationConstraint.blend)

Christoph Lendenfeld commented

2022-11-23 14:50:51 +01:00

potential duplicate: https://developer.blender.org/T79118
not closing because I am not 100% sure

potential duplicate: https://developer.blender.org/T79118 not closing because I am not 100% sure

Carlo Andreacchio commented

2022-11-24 00:47:10 +01:00

My original report is not the same, if you follow my instructions, it works correctly if it copies off a mesh, but not correctly if its copied off a camera (same animation)

Christoph Lendenfeld commented

2022-11-24 09:19:38 +01:00

sorry it makes no difference if the constraint points at the camera or not
the difference is that the rotation values between the two are different
camera: (91.1, -0.00..., z-animated)
text: (0,0, z-animated)

if you set the text to the same values you get the same result

sorry it makes no difference if the constraint points at the camera or not the difference is that the rotation values between the two are different camera: (91.1, -0.00..., z-animated) text: (0,0, z-animated) if you set the text to the same values you get the same result

Carlo Andreacchio commented

2022-11-25 00:01:33 +01:00

I understand that yes your example doesnt matter if its on the camera or not. but my original report does not, which is the bug I am reporting.

I have copied pasted my example below for convience.

Exact steps for others to reproduce the error

Open attached blend file
Press play
Notice how the arrow, flips 180 degrees
change teh target from asdfasd to Text.001
notice how the arrow now is normal

Text.001 and asdfasd have linked animation, so they should essentially be the same.
constraintBug_v001.blend

If the target is a mesh, it works fine. If the target is a camera, it does not. This is not the same as your report as your report doesn't matter if its a camera or not.

I understand that yes your example doesnt matter if its on the camera or not. but my original report does not, which is the bug I am reporting. I have copied pasted my example below for convience. **Exact steps for others to reproduce the error** 1. Open attached blend file 2. Press play 3. Notice how the arrow, flips 180 degrees 4. change teh target from asdfasd to Text.001 5. notice how the arrow now is normal Text.001 and asdfasd have linked animation, so they should essentially be the same. [constraintBug_v001.blend](https://archive.blender.org/developer/F13958508/constraintBug_v001.blend) If the target is a mesh, it works fine. If the target is a camera, it does not. This is not the same as your report as your report doesn't matter if its a camera or not.

Sybren A. Stüvel commented

2022-11-29 12:15:26 +01:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2022-11-29 12:15:26 +01:00

In #102679#1451051, @candreacchio wrote:
I understand that yes your example doesnt matter if its on the camera or not. but my original report does not, which is the bug I am reporting.
[...]
If the target is a mesh, it works fine. If the target is a camera, it does not. This is not the same as your report as your report doesn't matter if its a camera or not.

@ChrisLend is right, though. The mesh object in your example file has a different rotation than the camera object, and thus the conclusion that the observed diffference must be caused by the object type (camera vs. mesh) unfounded. The difference in rotation is what matters here. Having a rotation such that one axis is (almost) mapped onto another (such as having X-rotation of 91°) is known to cause problems: Gimbal Lock.

I see this as a duplicate of #79118 indeed, in the sense that it is also caused by gimbal lock, and thus expected mathematical instability.

> In #102679#1451051, @candreacchio wrote: > I understand that yes your example doesnt matter if its on the camera or not. but my original report does not, which is the bug I am reporting. > [...] > If the target is a mesh, it works fine. If the target is a camera, it does not. This is not the same as your report as your report doesn't matter if its a camera or not. @ChrisLend is right, though. The mesh object in your example file has a different rotation than the camera object, and thus the conclusion that the observed diffference must be caused by the object type (camera vs. mesh) unfounded. The difference in rotation is what matters here. Having a rotation such that one axis is (almost) mapped onto another (such as having X-rotation of 91°) is known to cause problems: [Gimbal Lock](https://en.wikipedia.org/wiki/Gimbal_lock). I see this as a duplicate of #79118 indeed, in the sense that it is also caused by gimbal lock, and thus expected mathematical instability.

Sybren A. Stüvel commented

2022-11-29 12:15:34 +01:00

Closed as duplicate of #79118

Sybren A. Stüvel closed this issue

2022-11-29 12:15:34 +01:00

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

Copy Rotation Constraint unexpectedly have numerical instability #102679

Simplified Report

Original Report