[Gizmo] - Wrong rotation after usage of position gizmo

Hi all, there is an issue with rotation when you use gizmo after 6.21.2,
probably that happens because of changes in math.vector

Screenshot 2023-11-28 at 10.32.37

Is the issue that the values aren’t the same, even through they’re equivalent?

Before any move

After move on z axis for example

As you can see, rotation/scaling were changed :frowning:

Rotation: (0, 0, 90) → (0, 180, 90)
Scaling: (1, 1, -1) → (1, -1, 1)

cc @Cedric if he can think of smthg

Matrix is decomposed and recomposed so this kind of change is expected. More specifically when using non uniform negative scales.

1 Like

Is there a way to avoid this change?

You can add a parent transform and use the gizmo with it. But de-parenting the mesh will also change rotation/scale.

Does it really make sense to recompose matrix in such way? I mean before it worked fine, without changing anything except position.

Maybe you can suggest something for our use case. We have an editor and store object values at backend. There are a lot of change possibilites, but what is broken with gizmo right now.

Before:

  1. We want to change position
    Position: (0, 0, 0) → (0, 1, 0)
    // Rotation: (0, 0, 90) → (0, 0, 90)
    // Scaling: (1, 1, -1) → (1, 1, -1)
  2. We want to change rotation
    // Position: (0, 1, 0) → (0, 1, 0)
    Rotation: (0, 0, 90) → (0, 180, 90)
    // Scaling: (1, 1, -1) → (1, 1, -1)
    RESULT on BE:
    Position: (0, 1, 0)
    Rotation: (0, 180, 90)
    Scaling: (1, 1, -1)

And now:

  1. We want to change position
    Position: (0, 0, 0) → (0, 1, 0)
    // Rotation: (0, 0, 90) → (0, 180, 90)
    // Scaling: (1, 1, -1) → (1, -1, 1)
  2. We want to change rotation
    // Position: (0, 1, 0) → (0, 1, 0)
    Rotation: (0, 180, 90) → (0, 0, 90)
    // Scaling: (1, -1, 1) → (1, -1, 1)
    RESULT on BE:
    Position: (0, 1, 0)
    Rotation: (0, 0, 90)
    Scaling: (1, 1, -1)

This change on matrix decomposition is quite old. when you say ‘before’ what babylon.js version are you refering to?

We updated from 6.10 to 6.29.1, but I checked and the error didn’t occur on 6.21.1 and occur after 6.21.2

This MR, math.vector change Gizmos fixes and small improvements by CedricGuillemet · Pull Request #14365 · BabylonJS/Babylon.js · GitHub

Thanks for getting the commit. Let me do some tests…

I have a fix

The PR I did containing math.vector change was a bug fix, so, for your case, I have added a new flag

check line 18

3 Likes

Wow, thanks for you help :slight_smile:

Could you explain please which bug you fixed with absolute scaling? Just to know if we will see something like this :smiley:

Sure! It’s related to this thread : Gizmo use tmpParent but do not preserve scaling sign - #51 by Cedric
to make it short: a gizmo using a mesh in a hierarchy but the non uniform scaling is present in different nodes in the hierarchy. You can end up with a mesh having a scaling of 1,1,1 but a parent has -1.
This may happen to you with imported gltf in left hand coordinates and/or with more levels in the hierarchy.
non uniform negative scaling is hard to fix for all the use cases. keep me posted if you find more edge cases.

@Cedric Do you know when it will be released? I saw that it was merged to master :slight_smile:

Release is done every Thrusday

1 Like

Thanks