Orient the 3D manipulation gizmo to be easy to use regardless of camera rotation

[mieldepoche]

Describe the project you are working on

prototypes

Describe the problem or limitation you are having in your project

Currently, the manipulator gizmo doesn't change with the view angle, which makes it difficult to use pretty often.

simplescreenrecorder-2023-07-23_16.39.01.webm

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Adjust the manip gizmo according to the camera angle (see below).

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Here's how it's done in spline:

simplescreenrecorder-2023-07-23_16.37.37.webm

(Notice how the arrow ends change to indicate the axe's positive direction)

I think this is an ok solution.

If this enhancement will not be used often, can it be worked around with a few lines of script?

used often

Is there a reason why this should be core and not an add-on in the asset library?

basic editor ux

[ParsleighScumble]

I like the looks of this. I'm interested in implementing this if I get the go-ahead from the community.

[Lielay9]

This would be better for editing the position but I find it harder to make out the facing of the object at a glance. I personally use the gizmo for the purpose of finding the facing of the object more often than I do for moving it, but as an option, I find this a great addition.

Example of admittedly the worst case where the direction of the cap is hard to see (Y-axis is pointing down):

[ParsleighScumble]

I also like the rotation gizmo pretty much as it is. It might be possible to improve the contrast of all the gizmos somewhat.

Basically we want all elements of the gizmo to always be easily clickable, all the time. It seems like most of the time it becomes hard to click if one gizmo is on top of another and the rotation gizmo doesn't suffer from this as it doesn't overlap with its own other axes and gives priority to the other gizmos. It might also be possible to improve the clickability of these other gizmos without making them view dependent. For example this is not the gizmo I'd expect given this mouse position (mouse was on pepper)

[ucmRich]

i understand what the op is saying. i personally prefer the gizmo the way it is BUT he is absolutely right on target about it being very difficult to get to node manipulators when they are narrowed too thinly.... I have been running into this myself today.

perhaps a solution could be to use cubes instead of square-planes as it would help keep the gizmo minimalistic but still let us reach it with the mouse hotspot? i think we would all really love that?

0:-)

[ParsleighScumble]

To me it's more of a question of giving certain parts of the gizmo priority over other parts and making it so that the best one for any particular mouse position is selected. As it is now you already don't have to click exactly on the gizmo to get it to work. Making the gizmo face you helps with that in that you have less overlap between the parts.

Planes are a good representation of moving something within a plane, so they should visually stay as they are, but internally they can have hitboxes with some width that contain the planes.

[Calinou]

You might be interested in this article: https://aras-p.info/blog/2020/04/11/Various-details-about-Handles/

[mieldepoche]

an alternative design could show full arrows regardless of the view, perhaps dimming the halves that are on the "wrong" side of the view. This is what I mean, (blockbench's take on this little toy):

simplescreenrecorder-2023-07-27_16.53.37.webm

(I think it's better to dim them since the back part would overlap with the planar quad of the same color)

This would basically act like the adaptive design while still retaining the benefits of the current one (legible local transform). The quads (for planar translation) would have to move though.

Not sure how well that would work in practice but that's an idea I guess.

A desirable feature mentionned in https://aras-p.info/blog/2020/04/11/Various-details-about-Handles/ is fading (and disabling) axes when they're near-orthogonal to the screen, which would have to be done with planar movement quads too, and rotation circles (but only in the translation+rotation gizmo in which they would otherwise overlap with the axis handles).

[kobligo]

No replies since July? Please, don't let this proposal lose its momentum and die. Over the past week this issue was brought up daily by Unity refugees. The handles obstructing each other is a serious problem. I myself work with 3D scenes a lot, and Godot's move gizmo bugs me tremendously whenever I'm moving objects around.

The arrows can stay as they are, but the plane handles should definitely adjust their position according to the camera angle. Unity shows you exactly how it should be done.

[ParsleighScumble]

I've been swamped prepping for job interviews right now unfortunately.