We’re trying to build a feature where a user may select and move multiple meshes at the same time.
Given that the gizmoManager can only be attached to one node, the strategy is basically to:
Attach the list of selected meshes to an intermediate parent node
Move/Rotate/Scale the intermediate parentNode
Reattach the selected meshes to their respective previous parent
One caveat being, there seems to be scaling issues when reparenting children after releasing a gizmo. Ways to reproduce the bug
Move the sphere
Scale the ground in a non-uniform way (Not on all 3 axis, but only over 1 axis)
Rotate the ground
Get back to the sphere and move it/scale in a non uniform way
Notice the bug
Can’t seem to understand why re-parenting is not conserving the transforms (as we’re using .setParent instead of .parent = )
Otherwise, should we leverage a different approach rather than relying on the intermediate-node-thingie?
Thank you for the quick answer @labris!
The thing that I couldn’t understand is the tilting/change of scale when manipulating the childMesh whenever moving it, rotating it or scaling it.
As you’re scaling it, it follows along the gizmo, but once released, because it becomes under another parent, it shifts randomly again. (I’ve attached a .gif to explain the scenario I’ve been struggling with)
It looks like maybe you’re running up against the issue that parent nodes with non uniform scaling aren’t supported. The results can get pretty bonkers…
There’s a paragraph about it at the end of the first section of this doc, but it should probably say WARNING in big bold letters or something to stand out more…
The PreserveScaling unfortunately didn’t solve the issue, and as you’ve said, it’s still a lil’ bit bonkers ahahahahahahah.
I think the alternative would be to manually implement the multiple-manipulation without parenting at all, prolly’ by using the PointerDragBehaviour and computing the way the children need to move/rotate/scale accordingly
First, Gizmo.PreserveScaling is used for intermediate operations within the gizmo, not the parenting you might do outside of gizmo, so all the calls to setparent must have the 2nd parameter set true to preserve scaling when parenting.
I did the change here:
This will not fix your problem because it’s related to the parenting to gizmoAttacherNode.
Line 66, when setting gizmoAttacherNode, rotation is not set. When rotating it, the scaling is not applied in local space for the pickedMesh. A mesh cannot have scaling on world space.
Otherwise, its matrix will be skewed and that’s not possible in the engine as the matrix is computed from T/R/S.
Scaling will be an issue in your case as it’s not possible to compute a scaling individualy. Scaling a set of meshes that have different rotation will make no sense without a parent transform that will hold that scaling.