Align to Transform Orientation precision issue #71438

New Issue

Stanislav Blinov · 2019-11-09T07:55:07+01:00

Stanislav Blinov commented

2019-11-09 07:55:07 +01:00

Blender Version
Broken: 2.8x

Short description of error
Align to Transform Orientation introduces a small error in orientation.

Exact steps for others to reproduce the error

Load the default scene.
Rotate the cube.
Make sure current transform orientation is set to Global.
With the cube selected, go Object -> Transform -> Align to Transform Orientation

In my case, the new orientation of the cube, while close to (0, 0, 0), is actually (0.000001, -0.000002, 0). This, in turn, results in accumulation of small "errors" in coordinates when translating the object along its axes. Running the operator a second time seems to make the orientation (0, 0, 0) though.

**Blender Version** Broken: 2.8x **Short description of error** Align to Transform Orientation introduces a small error in orientation. **Exact steps for others to reproduce the error** 1. Load the default scene. 2. Rotate the cube. 3. Make sure current transform orientation is set to Global. 4. With the cube selected, go Object -> Transform -> Align to Transform Orientation In my case, the new orientation of the cube, while close to (0, 0, 0), is actually (0.000001, -0.000002, 0). This, in turn, results in accumulation of small "errors" in coordinates when translating the object along its axes. Running the operator a second time seems to make the orientation (0, 0, 0) though.

Stanislav Blinov commented

2019-11-09 07:55:07 +01:00

Added subscriber: @Stan_Pancakes

Habib Gahbiche commented

2019-11-10 11:30:13 +01:00

Added subscriber: @zazizizou

Habib Gahbiche commented

2019-11-10 11:30:13 +01:00

This inaccuracy is expected, see https://devtalk.blender.org/t/inaccuracy-of-values-in-transform/2655/4

Stanislav Blinov commented

2019-11-10 13:39:23 +01:00

No. That thread talks about inaccuracies that accumulate while editing. These are indeed to be expected. Aligning to orientation is not a temporal operation. It should, if at all possible, match the object's orientation with the desired one, otherwise it's at best a "Try to align". Right now it's just calculated with floats, which contributes to the discrepancy listed in the task description.

Habib Gahbiche commented

2019-11-10 13:59:26 +01:00

If I move the cube around and do slightly different rotations then I get different values than the ones you wrote above. We are talking about the 7th digit in -0.000002, which is around the limit of floating point arithmetics. Note that these are indeed incorrect values but the behavior is expected in the sense that Blender cannot have any higher precision than that because it uses floats to represent real numbers.

Whether we should round such numbers for display is a different issue I think.

If I move the cube around and do slightly different rotations then I get different values than the ones you wrote above. We are talking about the 7th digit in -0.000002, which is around the limit of floating point arithmetics. Note that these are indeed incorrect values but the behavior is expected in the sense that Blender cannot have any higher precision than that because it uses floats to represent real numbers. Whether we should round such numbers for display is a different issue I think.

Stanislav Blinov commented

2019-11-10 16:14:12 +01:00

What are you talking about? Final orientation is already known and is represented to the precision available. Aligning an object should match that orientation to the same precision, not approximate it. It's not about rounding of final result, at all.

What are you talking about? Final orientation is already known and is represented to the precision available. Aligning an object should **match** that orientation to the same precision, not approximate it. It's not about rounding of final result, at all.

Cirno commented

2019-12-20 19:21:47 +01:00

Added subscriber: @Lambdadelta

Cirno commented

2019-12-20 19:21:47 +01:00

Interestingly, that bpy.ops.transform.transform() operator has "Accurate" parameter (use_accurate), that is set by default to False.
But toggling in on have no effect on align precision. Does anyone know why it there?

Interestingly, that `bpy.ops.transform.transform()` operator has "Accurate" parameter (use_accurate), that is set by default to False. But toggling in on have no effect on align precision. Does anyone know why it there?

Jacques Lucke commented

2020-01-08 17:33:10 +01:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2020-01-08 17:33:10 +01:00

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

Jacques Lucke closed this issue

2020-01-08 17:33:10 +01:00

Jacques Lucke self-assigned this 2020-01-08 17:33:10 +01:00

Jacques Lucke commented

2020-01-08 17:33:10 +01:00

While in this special case, the exact target orientation is known, the code that computes this has to deal with more complex situations. E.g. when the object is parented to some other rotated object. Then when aligning it to world coordinates is more difficult than just copying the values over.
Blender could have a special case for the case you describe, but I think it is fine if it does not have it. Therefore, do not consider this to be a bug. It is working as expected with an error smaller than the machine precision.

While in this special case, the exact target orientation is known, the code that computes this has to deal with more complex situations. E.g. when the object is parented to some other rotated object. Then when aligning it to world coordinates is more difficult than just copying the values over. Blender could have a special case for the case you describe, but I think it is fine if it does not have it. Therefore, do not consider this to be a bug. It is working as expected with an error smaller than the machine precision.

Stanislav Blinov commented

2020-01-08 18:59:50 +01:00

"Special" case would be the parented one. Trivial case should be indistinguishable from copy-pasting the orientation.

Germano Cavalcante referenced this issue

2023-12-22 21:29:55 +01:00

Rotation issues with MMB constraints On #116448

Sign in to join this conversation.