Why does setPivotMatrix not give the right results regarding world translation?

Questions
1

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?

image

Here’s the PG https://playground.babylonjs.com/#G91AFC#5

Any help on this would be appreciated! @sebavan @Cedric @carolhmj

2

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 :slight_smile:

1 Like
3

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?

4

Is adding a transform in the hierarchy that inverts pivot can be a possibility in your use case?

5

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?

6

wondering if the scaling thing is a bug in the implementation of the pivot matrix?

7

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?

8

“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? :smile:

9

maybe @Evgeni_Popov

1 Like
10

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).

11

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

12

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

13

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.

1 Like