Suppose I have a world matrix I want my node to be at.
I want to match this world matrix by only updating the pivot matrix i.e. not touching the local matrix.

I compute the pivotMatrix, then use setPivotMatrix(pivotMatrix, false).
The world matrix is identical if the node hierarchy has uniform scale (1,1,1), however the world matrix translation becomes different when any node in the hierarchy gets scaled differently. I’m wondering why this is?

Target world matrix doesn’t use NodeB scaling. But it’s used in engine computation so result is different after computeWorldMatrix. So, this is expected if computation in setWorldMatrix_PivotMatrixOnly is different from engine’s. It’s monday morning, maybe I’m missing something

Yea, I was wondering if there’s a way that I can update the pivot matrix only, and get a result that is the exact same as the engine’s computeWorldMatrix?

Yep, open to hearing if you have suggestions on the implementation! I was still hoping the pivot matrix could handle it because isn’t that what it’s originally designed for? To factor in parent/hierarchy scaling?

I don’t know if there is a ‘standard’ for that. To me, it’s just another intermediate matrix to change the origin of the transform. So, scaling should be taken into account.
Did you check with other 3d engine?

“scaling should be taken into account.” - exactly as I would have imagined!
Have not checked with other 3D engines but it seems that the fundamental matrices (and therefore scaling) should not be ignored… is there someone in the team that I should ping here regarding this implementation?

I wonder if the problem is related to the fact that the local translation is simply set into the final matrix after the pivot matrix has been transformed by the local scale / rotation in TransformNode.computeWorldMatrix:

See line 1124 => the translation is not transformed to a matrix and multiplied to the _localMatrix, it simply overwrites the translation values. I think you will have to take that into account when computing your pivot matrix (I don’t know exactly how, though).

Yep, I’m wondering if that’s by design, or it’s a bug in the implementation.
It would make sense if the translation values shouldn’t be overwritten like that

In other words, shouldn’t line 1124 be above line 1119?

I believe the logical thing would be for the translation to be set to the localmatrix before it is multiplied by the pivot matrix, not the other way round

I don’t know (I suppose you could say that the current way of working is by design), but in any case we can’t make this change as it would be a breaking change.