Rebased since #108576 was merged.

Should be fixed now.

Looks like there is some shearing when multiple nodes are selected now, so I will need to look into that.

When multiple selections are made, it should be correct behavior for each selection to be sheared individually.

Oops I didn't pay attention to the scales across parents close enough in my testing.

I think things are fine, let me know if I missed anything.

As I mentioned above, in local mode, the XYZ rotation gizmo references each node's local axes.

When multiple nodes are selected, the gizmo displayed is based on the last selected node.

Considering this, the 4th gizmo should extract the local axes relative to the last selected node from that plane and apply them to the other nodes during multiple selection. In other words, in the case shown in the following video, the Y rotation and the rotation applied by the 4th gizmo should be equal.

sh_3d.zip

In other words, the current local mode with 4th gizmo is inconsistent as the origin is local while rotation is global.

Wouldn't that require #104233 as a prerequisite and its function enabled to make sense? Right now, local mode just means transform each node relative to its own local coordinates, and the 4th gizmo is always facing the camera, so it effectively behaves as a global transform.

@ryevdokimov If #104233 is implemented and that option is enabled, the current 4th gizmo behavior is correct. Conversely, after implementing #104233 and that option is enabled, the y rotation in the above video should follow the current 4th gizmo's behavior.

However, since #104233 is currently disabled in this PR, so the y rotation is correct and the 4th gizmo's movement is incorrect now. This PR must be fixed assuming that option #104233 is disabled.

So if we implement #104233, you should reintroduce the current 4th gizmo behavior as the optional behavior when that option is enabled.

Right now, local mode just means transform each node relative to its own local coordinates, and the 4th gizmo is always facing the camera, so it effectively behaves as a global transform.

In other words, we must select the ring's normal as the rotation axis in the Local coordinate.

In the above case, the rotation axis for the 4th gizmo and the y rotation gizmo are differed.

However, in the above case, the rotation axis for the 4th gizmo and the y rotation gizmo must be the same.

As long as option #104233 is disabled, that axis must be treated as a local rotation axis for each node. The current behavior always treats the 4th gizmo as the global rotation axis, so it is wrong for the behavior when #104233 is disabled.

If #104233 is implemented and that option is enabled, the current 4th gizmo behavior is correct.

Ah yes, that makes sense actually, so the converse of that is what clarifies it.

It's just a little confusing because I interpreted the correct behavior as how each node should behave as if it were selected individually in local mode, but when put in that context and if the other PR gets merged what you're saying is the correct way to differentiate the behavior between the two modes, and without that PR the default should be as if it were off.

Thanks for the explanation.

Alright, try it now.

Feedback addressed (comments, unnecessary changes, organization and naming/clarity).

Thanks!