Implement blender-style 3D transform tools.

[rcorre]

Fixes godotengine/godot-proposals#1215.

This adds shortcuts for blender-inspired transforms, where you can press
the key and immediately be transforming an object without holding the
mouse. Clicking commits the transformation, ESC aborts it.

This is inspired by Blender's G(rab)/R(otate)/S(cale) shortcuts, but I
decided not to add default bindings as S is already bound to the
regular scale tool, and it might be confusing to only bind some of them.

While actively using a transform tool, you can press X/Y/Z to lock the
transform to an axis or (shift)+X/Y/Z to constrain the transform to a
plane. These keys are only processed if you have a transform tool
(translate/rotate/scale) active and the mouse button is held.

Pressing XX/YY/ZZ will lock the transform to a local (rather than
global) axis.

This is achieved by temporarily toggling the local transform button. I
did this (vs handling it in the transform functions) for 3 reasons:

• Transform logic for translate/rotate (but not scale) appears to be
  tightly coupled to the gizmo
• This ensures the gizmo changes to indicate we're transforming
  locally/globally
• Toggling the button state in the UI also gives the user feedback about
  the nature of the transform.

The original state of the button is reset when the transform completes.

Pressing the spatial_editor/cancel_transform shortcut key during a
transform operation will cancel the transform and reset the objects back
to their original transforms.

This functionality was already accessible by pressing RMB during a
transform, however:

• ESC is more familiar to blender users, and a more common "cancel" key
  in general.
• Given you must hold LMB during a transform, pressing RMB as well is
  clumsy if not impossible (on a laptop trackpad).

godot.mp4

[rcorre]

There seems to be a bug with a "dead zone", but it happens on master with the regular transform tools, even without this patch.

bug.mp4

[Calinou]

There seems to be a bug with a "dead zone", but it happens on master with the regular transform tools, even without this patch.

Maybe this is caused by #49310? Try reducing the hardcoded drag distance threshold to 0 pixels and see if it still happens.

[rcorre]

Setting the drag distance to 0 did not help. I filed #56582

[JFonS]

I did some testing and I really like how these new shortcuts work, but I have a couple of notes/nitpicks:

• Switching the locked axis doesn't give consistent feedback. Depending on whether you switch from no lock to global lock or from global lock to local lock, the node you are editing updates differently. In some cases it doesn't update at all, in others only the rotation is updated, and the full transform is not updated until you move the mouse.
  Ideally the object would completely update on screen as soon as you press the axis shortcut, giving the user a better idea of what is going to happen if they move the mouse.

• Axis lines stay visible after a transformation/edit. It may just be missing a call to surface->update(); somewhere.

• Are there any good shortcuts available that we could set as defaults for these transform modes? I think these new immediate modes can be very useful, so I would consider having them enabled by default.

[rcorre]

Are there any good shortcuts available that we could set as defaults for these transform modes

I figured using anything other than the blender defaults of Grab Rotate Scale would be unintuitive, but S already conflicts with the normal scale tool (and maybe R does too? IIRC QWER are all bound by default)

Thanks for giving it a try! I'll look into the other two bullets.

[JFonS]

I did some more testing after the changes, here are some more small things I found:

• If you select the scale tool (R shortcut) and then do a view transform (click and drag anywhere) the object translates instead of scaling.

• You can do Shift+Axis while rotating, but rotating an object over two axes is not really defined, so things just lock-up. I'm not sure what's the best way to handle this, probably just ignoring Shit+Axis shortcuts while rotating.

• The displayed axis when doing Shift+Axis transforms are wrong for Shift+Y (only shows X axis) and Shift+Z (shows all axes).

Some other things I noticed that can be improved in future PRs, not necessarily in this one:

• Axis highlighting on the gizmo handles is still active when doing instant transformations, which can be confusing. We could disable highlighting altogether, or even better, highlight the currently locked axes.

• Given the way we compute transformations (intersecting rays and planes) sometimes the current mouse position doesn't intersect the transform plane and moving the mouse does nothing. This means the user can be moving things around and, after changing the locked axis, they get no movement and no feedback as to why nothing is happening. Improve rotation in the 3D transform gizmo #56946 should help alleviate this in rotations, but the other transforms can also fall into deadzones, so it would be interesting to look into those as well.

Again, great work on this PR. Once the three smaller items are fixed this should be good to merge :)

[rcorre]

Thanks again for the review @JFonS! I think I addressed the first 3 points.

[JFonS]

Looks great, I did some more testing and everything works as expected :)

This should be good to merge, but we may want to merge #48307 first. I think rebasing this PR on top of the other will be more straightforward than the other way around. Approving nonetheless.

[akien-mga]

As discussed on chat, @aaronfranke should have no trouble rebasing #48307 so let's merge this one as it's ready.

[akien-mga]

Thanks!

[aaronfranke]

@akien-mga @rcorre Serious regression: As of this PR, I'm not able to move around the 3D editor camera. Middle click and right click do nothing. Zooming and focusing still work though. Everything works on 2a39a1c

[JFonS]

looks like EditData::instant is wrongly initialized to true, so navigation doesn't work until you use the transform gizmo. Setting it to false on initialization fixes the issue.

[geowarin]

This is really awesome! Switching from blender to godot used to be a bit akward 😄
Thanks @rcorre!

Any chance this gets merged in 3.X.X?

[rcorre]

I'd be willing to backport if the maintainers approve.

[JFonS]

@rcorre Sure, any improvements that are on master can be backported to 3.x

[geowarin]

Sorry for the late feedback. First, it's totally awesome.

Second, I noticed that, on my French azerty keyboard, without keypad, I'm unable to use numbers to affect the transform, even with the "emulate numpad" setting in Editor>3D.

To be honest, I'm not sure if it's in the scope of this PR, "emulate numpad" never worked for me when I'm in azerty.
However, when I switch to qwerty, the number keys switch the camera positions, even while I'm in the middle of a transform.
So maybe something can be added in the future to change that.

Edit: never mind I realized that imputing numbers to affect transforms was not implemented by this PR (maybe later ? 😄 )
I'll open a separate issue for the "emulate numpad" setting not working on international keyboard.

[Calinou]

Using physical key inputs for KEY_1 to KEY_0 would allow supporting any keyboard layout when entering numbers using the top row.

[rcorre]

I'm taking a look at adding number support now. Thanks for the suggestion @geowarin!

[akien-mga]

I'm taking a look at adding number support now. Thanks for the suggestion @geowarin!

See #58024

[FeelingFun]

Hello! Your work is really great! This feature is my favorite.
I installed Alpha 2 build and gave it a try. In my test I begin to translate the node, constrain movement to specific axis (by pressing X shortcut), and when I switch to another axis (for example, pressing Y shortcut) the node suddenly changes position.

test.mp4

Can you please help to fix it?

[Calinou]

I installed Alpha 2 build and gave it a try. In my test I begin to translate the node, constrain movement to specific axis (by pressing X shortcut), and when I switch to another axis (for example, pressing Y shortcut) the node suddenly changes position.

The same behavior occurs in Blender 2.93, so I believe this is done by design:

simplescreenrecorder-2022-02-19_18.26.57.mp4

[FeelingFun]

I installed Alpha 2 build and gave it a try. In my test I begin to translate the node, constrain movement to specific axis (by pressing X shortcut), and when I switch to another axis (for example, pressing Y shortcut) the node suddenly changes position.

The same behavior occurs in Blender 2.93, so I believe this is done by design:

simplescreenrecorder-2022-02-19_18.26.57.mp4

But it's not the same in Maya (and probably 3DS Max). Maybe we should consider an option in Editor Settings to allow alternative behavior?

[Calinou]

But it's not the same in Maya (and probably 3DS Max). Maybe we should consider an option in Editor Settings to allow alternative behavior?

This pull request only intended to provide Blender-style controls, not Maya/3DS Max-style controls. Feel free to open a proposal discussion for this, but it needs significant community support to be considered.

[ywmaa]

I tried this feature, it is awesome, but I miss assiginig specific number, example :
Press R (begin Rotation)
Lock Axis (Y axis as an example)
write a number, 90, it will rotate the object by 90 degrees.

[Zireael07]

@ywmaa: I think this is either already requested or already implemented in 4.x

[rcorre]

Using numbers to control transforms is implemented in an open PR here: #58389

[matthewperiut]

I'm not sure if anyone will see this comment, but in Godot 4.0 release, I'm pressing G S and R and there is no transformations occurring? Is there something I'm missing to use blender-style transform keybinds?

[rcorre]

@matthewperiut updating to godot4 may have wiped your editor keybindings. Ensure that you've bound G, S, R to "Begin {Translate, Rotate, Scale} Transformation". They aren't bound by default as some conflict with builtin keybindings. These appear to work for me on 4.0-stable.

[matthewperiut]

@rcorre Thanks! Works like a charm!!