Updated gizmos for translate/rotate/scale

[kpal81xd]

Requires

• Gizmo updates engine#7887
• Gizmo API changes engine#7910
• Gizmo fixes and updates engine#7946
• Gizmo fixes engine#7954
• Gizmo fixes engine#7956
• Gizmo fixes engine#7957

Checklist

• I confirm I have read the contributing guidelines

[Maksims]

This is a significant one.
Happy to test it before release, to ensure we don't get degradations in UX.

[willeastcott]

I literally cannot believe how simple this PR is. Engine Gizmo system FTW! 🚀

[Maksims]

Please do not merge.

After a lot of testing, and running this through couple of other users (artists and developers), we have a few concerns:

Functional:

1. Gizmo arrows directions are changing - this is an issue, as direction intentionally did not change before, to indicate the direction of the main vectors: right, up, forward of an entity. With flipping them around, now it is confusing to know which way the object is facing, is it forward in front or to the back? Is it upside down or is it Y arrow of a gizmo flipped? "Sticky" arrow direction - was intentional, and serves functional purpose. The double-plane is not as large or obtrusive, allowing ease of access to arrows without flips.
2. Translation middle gizmo for moving relative to the camera - is a great addition. But it should work against a plane, and not based on distance to the camera, as moving around on the plane leads it to get closer and further based on proximity to the edges of a screen.
3. Rotation gizmo has a significant reduction in understanding its functionality by implementing unintuitive switch between two modes. After testing, I realized that when looking more perpendicular to the plane of rotation - it follows current behavior by rotating at the pointer on the plane of rotation. While engaging with gizmo when it is more of at the angle, it switches to other mode, where rotation is simply screen-space dependent. This is hidden behavior and double logic on one element. Extremely bad UX, as people will expect one or the other in different situations, and until you drag around to realize at which mode it is, it will lead to confusion. Don't implement "multi-behaviors" like that please. If you want one or the other, implement a user setting, that switches to one, or the other mode, and let users to make preference. Please favor the existing behavior as a default one, as forcing the change on users - is intrusive.
4. Rotation large circle - is a good addition.
5. Rotation gizmo when looking parallel to the plane - is actually the only case where it is useful to engage with in some cases, with screen-space relative pointer rotation.
6. Scale gizmo double-axis - is not as useful as it might seem. If it would be of a consistent scaling - that would be more useful, but having double-axis and scaling them independently, makes it somewhat finnicky to get desirable scale. Consider making them relatively locked.
7. Guides - this is a massive reduction in their functionality, and more clutter visually. The purpose of guides - is to allow users to align things relatively. For example when moving object on the XZ plane, you need to know what it is above/below for alignment! New Gizmos only show the guides on dragged axes - which are actually most useless guides when moving an object, as it is stationary, and only provides "distance" and not "alignment" feature. Please bring back the all 3 axes.
8. Guides occlusion - new gizmos fully lost that feature. Now the guides don't have occluded lines which are behind something. They are useful in many busy places, and still useful for alignments.
9. New gizmos are too obstructive when interacting with them - currently we hide gizmos and show faint lines to allow clarity of view for the user when interacting with gizmos. New gizmos don't even hide themself. Which can be visually on the way of what we trying to see - actual object we are manipulating.
10. Rotation gizmos when engaged are hiding other axes - making it harder to understand where other planes are rotated to. The common behavior - rotate entity by Yaw, and by seeing Pitch plane you can easier understand where object is facing now. New gizmos fully hide other planes making it harder to see that.
11. In orthographic view with axis-aligned camera, the rotation surrounding circle - is redundant.
12. Scale gizmo flipping axes - is the same issue as with translation, with additional problem - it is not clear where the positive direction is, so when engaging with flipped scale gizmo axis, it will scale down instead of up when moving into gizmos pointing direction - making it more confusing. Don't flip axes please.

Visual:

1. RGB color - is dull and not apparent. When user has gizmos - this is most interacted element on the viewport. In high-contrast scenes they simply get lost in a noise. Please use common RGB, and not transparent colors.
2. Hovering color consistency - it is not clear on what you hover in high-contrast scenes, as gizmo colors are in dull color, and then have insignificant highlight. Please use a single high-contrast color for hovering, to communicate clearly on what is hovered.
3. Rotation big circle uses different color for hover - this is unnecessary and inconsistent.
4. Guides - their color is somewhat irrelevant.

Bugs/issues:

1. Multiple times the gizmo became sticky while mouse button was released. In some cases this is true for current gizmos also, worth fixing.
2. Hover mouse entity name popup is not disabled when gizmos are engaged.

Overall:

1. We believe new gizmos is a significant downgrade in functionality and visual clarity.
2. It is unclear why this is changed, what benefit and what it tries to solve?
3. If the reason for changing the Editor gizmos is because other places (supersplat) now have their own - then please don't do this. It has no positive benefit for Editor users. If you want consistency, please go the other way - make sure other gizmo is consistent with battle-tested Editor's gizmos functionally and visually.
4. I have not seen or heard a complains about Editor's gizmos - they've been reliable, easy and clear to use gizmos through years. The massive amount of work spent on changing them - is simply not needed and do have reduction in experience.

Comparison (before/after):

Clarity of translate gizmo:

Translate gizmo dragging by Z axis. Notice missing X guide, and gizmos are not hiding.

Translate gizmo when dragging on two axes (mouse is actually on the right of the gizmo):

Rotation Gizmo (notice that Yaw gizmo is not fully rendered):

Rotation gizmo engaged Yaw axis (notice that it is not clear where Z axis is pointing with new gizmos):

Scale gizmo:

[kpal81xd]

@Maksims thanks for your in-depth here are my thoughts on your comments:

Colors

These were designed with customization in mind (including the hover colors) so can be adjusted accordingly to match (if so required). This idea was to allow the user to customize their gizmos in the editor however they would like

Axis/plane flipping

This was a recent addition for better accessibility when using the gizmos from obscure angles. Again like the colors this was planned to be added as a user customization feature in the future

Translating in facing plane

This is a regression and will be fixed

Consistent scaling

This is a feature I had missing I will add this (it is present in superspl.at)

Guides

Actually yes I agree with this - the hover should show the plane but actually movement its better to have all 3. As for the occlusion I had missed this actually and will add

Hiding

This was disabled but I will add a setting to reduce opacity when moving for a clearer view

Bugs

For the sticky mouse issue is this when the mouse leaves the viewport? Which scenarios does this occur in? as for the entity name on hover I will fix this

[Maksims]

To reduce the issue of imposed changes on users. It will be the best to match the behavior and look as much as possible by default. As it will reduce the mechanical-memory confusions by users in case of different behavior / perception. And then add settings to customize.

These were designed with customization in mind (including the hover colors) so can be adjusted accordingly to match (if so required). This idea was to allow the user to customize their gizmos in the editor however they would like

Is it possible to match existing colors by default, and then provide customization by users that need it?

This was a recent addition for better accessibility when using the gizmos from obscure angles. Again like the colors this was planned to be added as a user customization feature in the future

Can this be disabled by default (not flipping axes by default), and provide a setting in the future for users if they want it?

This was disabled but I will add a setting to reduce opacity when moving for a clearer view

Can this be enabled by default (gizmos hiding), and then provide a setting later to configure if someone needs it?

For the sticky mouse issue is this when the mouse leaves the viewport? Which scenarios does this occur in? as for the entity name on hover I will fix this

This actually same for existing gizmos - if you alt+tab to other window and release mouse over other window. Or on Windows do a screenshot with a snippet which has overlay over your screen - it will lead to sticky one.
If it is possible to detect loss of focus on window/tab in these cases - this can help to release gizmos.
Also it is good to check when pointer down while dragging, you can check if there was any other pointers, if no - then it means this is a "sticky situation" :D and can release gizmo before processing new pointerdown.

[SaadHaider7]

I checked it and think that the old visuals and behavior were better and the new one should match it and add the extra options as configurable in the settings like Max said.
Users should not be made to re learn the things they are used to using especially the gizmo as its used a lot and they might get frustrated seeing the new one.

[willeastcott]

@SaadHaider7 OK, but do you have anything specific you would like to add to @kpal81xd's list above?

[SaadHaider7]

The Rotation gizmo, if that can be improved and is less flickery,

bandicam.2025-08-07.20-26-12-910.mp4

[kpal81xd]

2. I cannot seem to replicate this - dragging by the plane in translate mode the object still follows depsite moving the mouse outside the windows bounds. What OS and browser are you testing this on?

It is about dragging stuff within the viewport, but if you visualize the planes that we are dragging around, then there are cases, where on high angles, it is possible to have that plane not to cover whole screen. In such cases we end up dragging gizmos to "outside" of the plane. It is not clear what needs to be done in such case, but I would assume we would want to detect that and not apply transformations in such case, or reset transformation to initial state. If not updating when detecting outside feels ok, and not jumpy - then that option is better. I will record a vid tomorrow to show it better.

I figured out what you meant by moving the gizmo to infinity from a sharp angle. I just keep the gizmo position fixed once the intersection test (close to infinity) and seems to work nicely

[Maksims]

The Rotation gizmo, if that can be improved and is less flickery,

bandicam.2025-08-07.20-26-12-910.mp4

This is still an issue with the latest updates.
Orthographical camera - does not show fully the perpendicular axes rotation circle gizmo.

I believe in this view, yellow circle should be disabled, and green circle should be visible fully.
Parallel axes should either be not interactable, or in this very specific case relative mouse mode used (but only here, when it is orthographic camera with exact axis aligned view).

[Maksims]

The other issue, is with use of more complex hierarchy, non uniform scales and parent rotations.
Current gizmo correctly shows the orientation, and gizmos are draggable as expected, while gizmos in this PR, behave funky and when dragged are doing math wrong.
Video below shows current and new gizmos:

2025-09-03.18-47-18.mp4

With rotation gizmos, their axes are especially missaligned:

2025-09-03.18-52-24.mp4

[Maksims]

Critical!!

If parent has rotation, then selecting any descendant, local gizmo will be not properly transformed.
And interacting with such gizmo does math wrong. Translate, rotate and scale.

2025-09-03.18-57-07.mp4

[Maksims]

Is it possible to make a new gizmo look somewhat closer to existing ones (esp. the rectangle bit on translate)? So they don't look that "flat"?

[kpal81xd]

Critical!!

If parent has rotation, then selecting any descendant, local gizmo will be not properly transformed. And interacting with such gizmo does math wrong. Translate, rotate and scale.

2025-09-03.18-57-07.mp4

So here is what I have fixed

• Fixed descendant rotation (regression bug fix)
• The orthographic view I have followed blender and made the arc into a ring

Is it possible to make a new gizmo look somewhat closer to existing ones (esp. the rectangle bit on translate)? So they don't look that "flat"?

Regarding the flatness I had made the gizmo opacity less so you can see the planes clearer however it was noted that the gizmos look less "vibrant". I can add further customisation to the gizmo theme in the future for separating all shapes however this is adequate for now.