Fix transform gizmo local space mode when multiple nodes are selected

[ryevdokimov]

The basis of the gizmo did not update correctly when switching to local space mode and multiple nodes are selected. Note in the before video that despite the gizmo still being rotated for global space, the transform was computed in local space. I'm not sure why the limitation to a single selected node existed in the first place, it seems to be deliberately added, but I can't find any issues removing it during testing.

Before:

2025-01-30.09-56-29.mp4

After:

2025-01-30.09-54-40.mp4

[fire]

According to when I asked, this was to match Blender behaviour #68804

So, it is intended, and to avoid behaviour breakage, we can't change it.

I'll ask @TokageItLab

[TokageItLab]

It might okay to handle this in cases where all selected objects are in the same direction, but it makes no sense in other cases.

For example, if object A's local +Z axis points to +Z in the world and object B's local +Z axis points to -Z in the world, a move to +Z with multiple selection in local mode will move each in the opposite direction.

So from a GUI perspective, it may be appropriate not to move Gizmo out of place when moving. At this time, I assume that the movement of translation can be calculated using averaging, but basis cannot be averaged. Therefor the only way at this stage for consistent behavior is to use the world visually.

The best way would be to visually duplicate TransformGizmo for the number of selected objects IMO, but this would require a fair amount of overhaul work.

Another way I can think of is to decide/select (in a way that the user can explicitly handle it) on one leader for multiple selections and use that basis, as in Blender, but this case does not solve the visual problem when each has a different local basis. This will also make it tempting to implement a new mode that ignores each local axis.

[ryevdokimov]

Yes, I see now that although it does select a leader in the gizmo basis, the computation of the transform is still independent which leads to unintuitive behavior. I will see if I can solve the approach of having the computed transform match the leader.