Euler rotation is wrapped to 180 degrees when Baking Animations #116484

New Issue

Andrej · 2023-12-23T07:32:14+01:00

Andrej commented

2023-12-23 07:32:14 +01:00

Blender Version
Broken: 4.0.2

Short description of error
Baking animation is losing rotation data if rotation is over 360 degrees.
This unrequested change in value can mess up drivers that expect the previous value to evaluate.

Before bake:	After bake:

So there are two possible issues:

Driver seems to be resolved only after all degrees were recalculated, therefore it bakes to incorrect value.
Bone_01 original rotation data is changed too though visually it will look the same here.

Exact steps for others to reproduce the error

Open .blend file TEST_rotation_over_360_deg_bake.blend
Select both bones
Pose -> Animation -> Bake Action and use the settings below:

Bone_01, that was before animated in Y rotation with 450-488 degrees, is now 90-125 degrees;
Bone_02, that was reusing Bone_01 rotation (divided by 10) through driver, before it's rotation was 45-48.5 degrees, now it is 9-12.5 degrees;

So, at least for Bone_02, rotation is now completely different visually.

The original use case was an animated mechanism where one part (kind of a gear) was partially reusing rotation from another part.

**Blender Version** Broken: 4.0.2 **Short description of error** Baking animation is losing rotation data if rotation is over 360 degrees. This unrequested change in value can mess up drivers that expect the previous value to evaluate. |Before bake:|After bake:| |--|--| |![blender_E1g2F1W2Vr.png](/attachments/e6b89259-4e6c-45c0-8b20-1f7f637ac49f)|![blender_cYHmUYCBwA.png](/attachments/7524f3c9-6815-4727-990c-fbe0d1338e8e)| So there are two possible issues: 1) Driver seems to be resolved only after all degrees were recalculated, therefore it bakes to incorrect value. 2) Bone_01 original rotation data is changed too though visually it will look the same here. **Exact steps for others to reproduce the error** - Open .blend file [TEST_rotation_over_360_deg_bake.blend](/attachments/2fe89ed2-60dc-4a84-9e6d-0d8f90dc0243) - Select both bones - Pose -> Animation -> Bake Action and use the settings below: ![blender_aqoMZ11UTE.png](/attachments/232a95b4-0e6b-49b6-951e-1b741c965b64) Bone_01, that was before animated in Y rotation with 450-488 degrees, is now 90-125 degrees; Bone_02, that was reusing Bone_01 rotation (divided by 10) through driver, before it's rotation was 45-48.5 degrees, now it is 9-12.5 degrees; So, at least for Bone_02, rotation is now completely different visually. The original use case was an animated mechanism where one part (kind of a gear) was partially reusing rotation from another part.

blender_E1g2F1W2Vr.png

148 KiB

blender_cYHmUYCBwA.png

158 KiB

TEST_rotation_over_360_deg_bake.blend

856 KiB

blender_aqoMZ11UTE.png

19 KiB

Andrej added the

labels 2023-12-23 07:32:15 +01:00

Germano Cavalcante changed title from ~~Baking animation is losing rotation data if rotation is over 360 degrees / losing drived values after bake~~ to Euler rotation is wrapped to 180 degrees when Baking Animations

2023-12-26 18:28:45 +01:00

Germano Cavalcante commented

2023-12-26 18:29:47 +01:00

I can confirm the issue.
The rotation data seems to be wrapped to 180 degrees when baking animations, which can cause problems with drivers and result in incorrect values.
I will forward this issue to the developers for further investigation.
Thank you for reporting it.

I can confirm the issue. The rotation data seems to be wrapped to 180 degrees when baking animations, which can cause problems with drivers and result in incorrect values. I will forward this issue to the developers for further investigation. Thank you for reporting it.

👍 1

Germano Cavalcante added

and removed

labels 2023-12-26 18:30:10 +01:00

Nathan Vegdahl commented

2024-01-12 10:38:02 +01:00

I believe we can support preserving > 180 degree euler values in some specific cases, but it isn't something we can preserve in the general case.

For example, if a bone has a constraint on it and you bake with visual keying, the baking process basically has to use transform matrices as an intermediary. And thus any aspect of rotation that a matrix can't represent (which includes > 180 rotation) will get lost. Moreover, there's no guarantee that the resulting constrained position even has a reasonable mapping to the >180 rotation in the original channels at all.

But if there are no constraints on a bone, then we can (I think) just directly bake the channel values, which would preserve everything. There also may be some cases where we can make a good guess even when things are constrained, although I'm not sure how reliably.

In any case, I think this essentially amounts to a feature request, rather than a bug. In the general case >180 rotation can't be preserved with the Bake Action operator, and I suspect that's why it's not currently supported. So it's an intentional and known limitation.

I realize, however, that this is counterintuitive for end users, because on the surface it seems like this should be really simple. But rotations are a lot more complex than end users generally realize. Nevertheless, I agree it would be good to support this where we can.

I believe we can support preserving > 180 degree euler values in some specific cases, but it isn't something we can preserve in the general case. For example, if a bone has a constraint on it and you bake with visual keying, the baking process basically has to use transform matrices as an intermediary. And thus any aspect of rotation that a matrix can't represent (which includes > 180 rotation) will get lost. Moreover, there's no guarantee that the resulting constrained position even has a reasonable mapping to the >180 rotation in the original channels at all. But if there are no constraints on a bone, then we can (I think) just directly bake the channel values, which would preserve everything. There also may be some cases where we can make a good guess even when things are constrained, although I'm not sure how reliably. In any case, I think this essentially amounts to a feature request, rather than a bug. In the general case >180 rotation can't be preserved with the Bake Action operator, and I suspect that's why it's not currently supported. So it's an intentional and known limitation. I realize, however, that this is counterintuitive for end users, because on the surface it seems like this should be really simple. But [rotations are a lot more complex](https://www.youtube.com/watch?v=SZE_KOjreAs&list=PLE211C8C41F1AFBAB) than end users generally realize. Nevertheless, I agree it would be good to support this where we can.

Sybren A. Stüvel added

Status

Needs Information from User

and removed

Status

Confirmed

labels 2024-02-05 11:23:49 +01:00

Sybren A. Stüvel commented

2024-02-05 11:36:11 +01:00

I suspect this is due to the "Visual Keying" option that's enabled. This only considers the final orientation of the object or bone, and not the method by which it arrived there. @Andrej730 please try what happens with that option disabled.

Given that this report is already a few months old, I tested it myself. My suspicions were wrong, and the normalisation of the rotation also happens without the "Visual Keying" option.

I'll relabel this as 'known issue'. It's simply a limitation of how the current baking is implemented (all transform computations just take the matrix representation), and not a bug. It is good to keep this in mind for when we design a new animation baking system, though.

~~I suspect this is due to the "Visual Keying" option that's enabled. This only considers the final orientation of the object or bone, and not the method by which it arrived there. @Andrej730 please try what happens with that option disabled.~~ Given that this report is already a few months old, I tested it myself. My suspicions were wrong, and the normalisation of the rotation also happens without the "Visual Keying" option. I'll relabel this as 'known issue'. It's simply a limitation of how the current baking is implemented (all transform computations just take the matrix representation), and not a bug. It is good to keep this in mind for when we design a new animation baking system, though.

Sybren A. Stüvel added

and removed

Needs Information from User

Type

Report

labels 2024-02-05 11:36:59 +01:00

Nathan Vegdahl commented

2024-02-05 11:42:16 +01:00

I tested it with the visual keying option disabled, and it still fails to preserve absolute degrees of rotation. The only difference with visual keying disabled seems to be that it ignores constraints, etc. But it still maps the euler degrees to < 180 degrees.

However, it is smart enough to bake to the euler angle that's closest to the previous baked frame. So although the initial frame gets mapped to < 180 degrees, a continuous rotation will happily continue beyond 180 degrees, rather than suddenly jumping to wrap back around mid-animation.

I tested it with the visual keying option disabled, and it still fails to preserve absolute degrees of rotation. The only difference with visual keying disabled seems to be that it ignores constraints, etc. But it still maps the euler degrees to < 180 degrees. However, it *is* smart enough to bake to the euler angle that's closest to the previous baked frame. So although the initial frame gets mapped to < 180 degrees, a continuous rotation will happily continue beyond 180 degrees, rather than suddenly jumping to wrap back around mid-animation.

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

Euler rotation is wrapped to 180 degrees when Baking Animations #116484