Child object rotates after parenting with 'Keep Transform Without Inverse' #109790

New Issue

Ingo Clemens · 2023-07-06T17:38:31+02:00

Ingo Clemens commented

2023-07-06 17:38:31 +02:00

System Information
Operating system: macOS-13.4.1-arm64-arm-64bit 64 Bits
Graphics card: Apple M1 Max Apple 4.1 Metal - 83.1

Blender Version
Broken: version: 3.6.0, branch: blender-v3.6-release, commit date: 2023-06-27 08:08, hash: c7fc78b81ecb
Worked: introduced with 'Keep Transform Without Inverse' in 3.2

Short description of error
After parenting with 'Keep Transform Without Inverse' the child object is slightly rotated and even the location can be off in relation to the parent object.
Please see the attached video and the blend file.

Note, that the scene units in the blend file are set to centimetres. Working with smaller units pronounces the effect of the location values. But for the rotation the scene units have no effect.

The problem seems to be related to rounding errors in the transform matrix multiplication code.

Other observations:

There is no rotation when the object gets parented with 'Keep Transform' (but this way the transformation values don't represent the relative values to the parent object)
When the object is parented with 'Keep Transform' and then 'Clear Parent Inverse' is executed the unwanted rotation will appear.
The larger the Euler rotation of the parent object is the more dramatic the location values appear distorted (as in the sample blend file).
Using Quaternion rotation doesn't yield as extreme results since the individual quaternion values cannot be set as high as when using Euler angles.
The same effect can be observed when parenting the object to a bone.
When trying to replicate the issue in other 3D Applications the parenting does not produce unwanted rotations or faulty relative positional values in relation to the parent object.

The problem is not directly noticable, other than fractional values are introduced to the rotation as well as the location. But when the object is large the far-away edges will get shifted in a more visible way.

Exact steps for others to reproduce the error
Parent an object to another which has rotation values. The resulting offset is small and therefore is only pronounced when zooming in at a larger distance from the origin.

**System Information** Operating system: macOS-13.4.1-arm64-arm-64bit 64 Bits Graphics card: Apple M1 Max Apple 4.1 Metal - 83.1 **Blender Version** Broken: version: 3.6.0, branch: blender-v3.6-release, commit date: 2023-06-27 08:08, hash: `c7fc78b81ecb` Worked: introduced with 'Keep Transform Without Inverse' in 3.2 **Short description of error** After parenting with 'Keep Transform Without Inverse' the child object is slightly rotated and even the location can be off in relation to the parent object. Please see the attached video and the blend file. Note, that the scene units in the blend file are set to centimetres. Working with smaller units pronounces the effect of the location values. But for the rotation the scene units have no effect. The problem seems to be related to rounding errors in the transform matrix multiplication code. Other observations: - There is no rotation when the object gets parented with 'Keep Transform' (but this way the transformation values don't represent the relative values to the parent object) - When the object is parented with 'Keep Transform' and then 'Clear Parent Inverse' is executed the unwanted rotation will appear. - The larger the Euler rotation of the parent object is the more dramatic the location values appear distorted (as in the sample blend file). - Using Quaternion rotation doesn't yield as extreme results since the individual quaternion values cannot be set as high as when using Euler angles. - The same effect can be observed when parenting the object to a bone. - When trying to replicate the issue in other 3D Applications the parenting does not produce unwanted rotations or faulty relative positional values in relation to the parent object. The problem is not directly noticable, other than fractional values are introduced to the rotation as well as the location. But when the object is large the far-away edges will get shifted in a more visible way. **Exact steps for others to reproduce the error** Parent an object to another which has rotation values. The resulting offset is small and therefore is only pronounced when zooming in at a larger distance from the origin.

precision_test.blend

841 KiB

parentingPrecisionError.mp4

5.2 MiB

👍 1

Ingo Clemens added the

labels 2023-07-06 17:38:32 +02:00

Nathan Vegdahl self-assigned this 2023-07-06 17:57:03 +02:00

Nathan Vegdahl added

and removed

labels 2023-07-06 17:57:29 +02:00

Nathan Vegdahl commented

2023-07-10 13:10:36 +02:00

This indeed appears to be due to floating point rounding error in Blender's transform matrix math routines. Specifically, when I change both of the following functions in math_matrix.c to use double precision internally for their computations, the error is significantly reduced:

mul_m4_m4m4()
invert_m4_m4()

Single precision matrix math	Double precision matrix math

So in short, this isn't a bug per se, but rather is a limitation of floating point math. Nevertheless, there are some potential ways to address this:

Use double precision math in the places that most need it. This could involve, for example, adding functions like invert_m4_m4_high_precision() to be used at the call sites that have the most impact on user-visible precision issues.
Use more numerically stable algorithms in general. For example, along the lines of https://pharr.org/matt/blog/2019/11/03/difference-of-floats (Perhaps also in separate "high precision" functions.)

Both of these would have negative performance implications, however. And regardless would need to be discussed with the wider Blender project, since it impacts more than just the animation/rigging module.

This indeed appears to be due to floating point rounding error in Blender's transform matrix math routines. Specifically, when I change both of the following functions in `math_matrix.c` to use double precision internally for their computations, the error is significantly reduced: - `mul_m4_m4m4()` - `invert_m4_m4()` | Single precision matrix math | Double precision matrix math | |---|---| | ![single_precision_compute.png](/attachments/73ff98d9-1b04-46cb-8c3b-e4209e7fe178) | ![double_precision_compute.png](/attachments/7f0bcb5c-6530-428e-a894-d985b558efe9) | So in short, this isn't a bug per se, but rather is a limitation of floating point math. Nevertheless, there are some potential ways to address this: - Use double precision math in the places that most need it. This could involve, for example, adding functions like `invert_m4_m4_high_precision()` to be used at the call sites that have the most impact on user-visible precision issues. - Use more numerically stable algorithms in general. For example, along the lines of https://pharr.org/matt/blog/2019/11/03/difference-of-floats (Perhaps also in separate "high precision" functions.) Both of these would have negative performance implications, however. And regardless would need to be discussed with the wider Blender project, since it impacts more than just the animation/rigging module.

single_precision_compute.png

263 KiB

double_precision_compute.png

258 KiB

Nathan Vegdahl commented

2023-07-10 15:39:51 +02:00

Some further investigation:

In my testing, quaternion rotations seem pretty much as susceptible to this as euler. And although I haven't found cases that produce it as strongly for axis angle, I suspect it's just a matter of finding the right values for it as well.
It doesn't specifically seem to be related to the magnitude of the rotation (or at least, that's not the only factor). For example, in the provided test file, editing the X or Z rotation fields of the to-be-parent object (including making them much larger) often significantly reduces the issue.

I think this means that the real issue is that very specific rotations result in matrices that have catastrophic cancellation in one or more subsequent operations. Which is also why moving those operations to double precision more-or-less resolves the issue.

Some further investigation: - In my testing, quaternion rotations seem pretty much as susceptible to this as euler. And although I haven't found cases that produce it as strongly for axis angle, I suspect it's just a matter of finding the right values for it as well. - It doesn't specifically seem to be related to the magnitude of the rotation (or at least, that's not the only factor). For example, in the provided test file, editing the X or Z rotation fields of the to-be-parent object (including making them much larger) often significantly *reduces* the issue. I *think* this means that the real issue is that very specific rotations result in matrices that have catastrophic cancellation in one or more subsequent operations. Which is also why moving those operations to double precision more-or-less resolves the issue.

Jesse Yurkovich added the

Module

Modeling

label 2023-07-16 07:02:26 +02:00

Nathan Vegdahl commented

2023-08-07 15:34:08 +02:00

I opened a discussion on devtalk about moving transforms generally to double precision. That would certainly address this issue (along with many others). However, that looks to be a more long-term thing, and will be a significant effort.

Since switching just mul_m4_m4m4() and invert_m4_m4() to double precision seems to resolve (or at least significantly mitigate) this particular issue, I think that would be a good way forward for the time being.

@brecht Do you have any opinions on this?

I opened a [discussion on devtalk](https://devtalk.blender.org/t/moving-transforms-and-matrices-to-double-precision/30329) about moving transforms generally to double precision. That would certainly address this issue (along with many others). However, that looks to be a more long-term thing, and will be a significant effort. Since switching just `mul_m4_m4m4()` and `invert_m4_m4()` to double precision seems to resolve (or at least significantly mitigate) this particular issue, I think that would be a good way forward for the time being. @brecht Do you have any opinions on this?

Brecht Van Lommel commented

2023-08-07 15:45:19 +02:00

If we switch something specific for parent to use doubles that seems reasonable. Changing all matrix multiplication and inversion in Blender and continuously converting between floats and doubles I do not think is acceptable.

👍 1

Nathan Vegdahl commented

2023-08-07 16:13:47 +02:00

Sounds good. I'll investigate making changes to narrowly affect just the parenting-related code.

Bart van der Braak added

and removed

labels 2024-08-14 13:11:08 +02:00

Sign in to join this conversation.