Fix desynced duplicate GLTFNode transform properties

[aaronfranke]

Draft because this PR requires #83229 to be merged first in order for exporting to function properly.

Before this PR, GLTFNode was storing multiple fields for the transformation matrix and the position/rotation/scale values. This is wrong, there should only be one data structure storing the transformation. I'm also adding the "needs testing" label because this PR may change behavior and should be tested before merging.

This PR fixes #82825, a bug where skeleton bone transforms were not set correctly.

Behavior in master (left is TRS, right is matrix):

Behavior in this PR:

Why is the model looking down? That's just how the model is, it's the same if I open it in Blender.

[fire]

What's your opinion of instead of deleting TRS we delete transform? I'm curious why that would be worse.

[aaronfranke]

@fire Transform has more degrees of freedom than TRS, so it's information loss. Also, Godot works with Transform3D more often than it works with TRS (it's pretty much just the skeleton code that needs TRS, and the glTF format generally prefers TRS but you can use matrix too).

[fire]

Note that non orthogonal matrices are out of spec for gltf, but we can still accept them.

When matrix is defined, it MUST be decomposable to TRS properties.

https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#transformations

[aaronfranke]

@fire Correct, and technically you can still perform decomposition on arbitrary matrices but it will just be lossy. The code in this PR ensures that we export data very close to what users have in Godot, so any data loss is not on Godot's end.

[reduz]

I am not sure this is necessarily a good idea, there are scenes (and common in skeletons) where you can have a non uniform scale and this is needed for proper importing, even if orthogonal.

[reduz]

These may not import correctly if you convert to TRS (or they may, I am not sure). Either case, I would test this well.

[reduz]

Oh if this is just for exporting it may not matter so much.

[aaronfranke]

The is_orthgonal check is to ensure there is no skew/shear. Non-uniform scale is still allowed.

[fire]

A non uniform scale is de composable into TRS as mentioned above, polar decomposition and such for nested non uniform scale is probably not needed for sheer and skew, but I am not sure what happens when we export it in this failure case.

[aaronfranke]

It will export the data Godot has in the best possible format. This code will prefer TRS if TRS can store all the data, otherwise it will use matrix.

[fire]

3d Pipeline Meeting:

1. We discussed how gltf spec requires that matrix is decomposible into and TRS
2. What do we do if we can't decompose into TRS?
3. Lyuma: recommends we use Matrix
4. Arronfranke: Information loss for non compliant Matrix / TRS

Reasoning:

Godot uses basis so we wanted to match. Use one source of truth.

[lyuma]

My original hesitation was that in the specific case of skeleton bones, we might be losing a tiny bit of precision in the conversion from quaternion -> basis -> quaternion. But to be honest, this factor is so miniscule it's not really worth worrying about.

Meanwhile, the advantage of this change is clear: the code is easier to verify when everything goes through a common code path of storing a Basis

[akien-mga]

Thanks!