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
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 
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.
2 Likes
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:
- 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) - 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:
- 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) - 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
1 Like
Thanks for getting the commit. Let me do some tests…
1 Like
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 
Could you explain please which bug you fixed with absolute scaling? Just to know if we will see something like this 
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
Release is done every Thrusday
1 Like
Thanks