Serious scaling issues when objects are parented

Description

I encountered a major scaling issue when I was trying to understand transforms in Armory. In the test scene I have four cubes. Two of them have a parent child relationship, and the other two dont. The green cubes are scaled by 0.5 along the X axis. The red cubes are simply rotated along z axis by 45 degrees. The only diffference between the two sets of cubes is parenting. Note that scaling and rotations were not “applied” in Blender.

The image above shows parented cubes on the right and un-parented ones on the left.

When viewed from orthographic projection, here is the comparison between Blender and Armory

From the image, the parented object has wrong scaling. While the unparented one looks correct.

However, when I checked the local transform of the objects in blender and Armory, they were a bit different:

arm/MyTrait.hx:18: Cube.002 :
arm/MyTrait.hx:19: Local Transform =
arm/MyTrait.hx:84: Loc:
arm/MyTrait.hx:85: (0, 0, 3, 1)
arm/MyTrait.hx:86: Rot
arm/MyTrait.hx:87: 0, 0, -0.36288262477061145, 0.9318348569567418
arm/MyTrait.hx:88: Scl
arm/MyTrait.hx:89: (1.5683433228513, 1.5683434814930588, 1, 1)

The differences were that:

1. The local rotation quaternion (object.transform.rot) in Armory was not normalized.
2. The local scale (object.transform.scale) in Armory was different form that of Blender

To Reproduce Use the provided blend file and run the project.

Expected behavior The scaling of objects must be proper, even if object scaling is not applied beforehand.

System Blender: 293 Armory: v2021.5 ($Id: 99497c80048d5b0614144ab4b87fb2303e416be2 $) OS: Windows10

Test File ScaleRotBugTestFile.zip

[QuantumCoderQC]

Okay, so after digging a bit deeper into the problem, I found the actual issue.

When it occurs: This issue occurs only when:

1. Mat4.decompose() is used on a local transform matrix of the object
2. The said object must have a parent with non-uniform scale

It is worth mentioning that decomposing works fine on world matrices.

The problem: When the above two conditions are satisfied, the child object’s local matrix is no longer made of pure Translation, Rotation and Scale. It has an additional component Shear due to the non uniform scaling of parent object. Hence when Mat4.decompose() is called, the returned Translation, Rotation and Scale are improper.

Similar cases: I found a very similar issue with three.js. They finally decided to simply tell users that such cases were “not supported”.

Probable solutions: From what I understand, this could go in 3 different directions:

1. Follow what three.js did and simply tell that such object pairs are not allowed or supported. Maybe add an export warning.
2. Improve the decompose() and compose() methods to somehow include shear. (Not sure if this would work)
3. Change the whole transform logic to use matrices only. No decompose/ compose of local matrices. (Blender probably does this)

[QuantumCoderQC]

I have no issues answering questions, someone in the future might refer to this issue.

Then the rotation could be decomposed from the basis matrix and later be combined with the rotation of matrices higher in the hierarchy (this might be laborious though).

Right, this is how Blender currently handles transforms. The matrix_basis is not and will not be a sheared matrix. Hence it can be decomposed and composed without any issues. This decomposed form of basis matrix is what one sees in the Blender’s Transform tab in the 3D viewport.

The method you mentioned does not include decomposing or composing of the local matrix. Just matrix multiplications to arrive at the local matrix. Hence, this is a probable solution (I already mentioned this in my previous post “Probable solution No. 3”).

Note that following the above solution still results in a sheared local matrix, This is because we multiply ob.matrix_parent_inverse @ ob.matrix_basis and ob.matrix_parent_inverse introduces shear. But we are in the green as long as we don’t decompose or compose this local matrix. And, Armory would render the object just like in Blender.

What I meant above is, why can’t we change the exporter to export a non-sheared matrix?

A sheared matrix in itself is not the main issue here. Just the decomposing and re-composing of such a sheared matrix is. So, even if we export a sheared local matrix, as long as we don’t decompose and compose this matrix, Armory would render the object just like in Blender.

Translation, rotation and scaling matrices can be further multiplied to this sheared local matrix to achieve local transformations without issues.

I will make a more detailed post about how Blender handles these transforms on the Armory Forums later. That way, we could keep this thread a bit clean.