Improve editing of box collision shapes

[KoBeWi]

Closes godotengine/godot-proposals#452

There is still some weird jitter issue I need to fix.

EDIT:
Closes godotengine/godot-proposals#5669

[wapordev]

vvonderful

[KoBeWi]

Jitter is fixed 🥳

godot.windows.editor.dev.x86_64_GRxjqDpOxY.mp4

There's a small issue where the box can't be shrunk past its center position:

godot.windows.editor.dev.x86_64_l0k4ybVF3C.mp4

But this is caused by the fact that the result of get_closest_points_between_segments() never goes below 0. It's probably solvable with some more math tricks, but I don't want to touch this anymore .-.

Another thing is that there are at least 4 different gizmos for box editing and this PR handles only one. I plan to make a follow-up PR and unify this. And maybe do the same treatment for capsule and cyllinder shapes, because they have the same 2-side problem.

[rburing]

When the shape resource is shared this will have the same issue as #73186, since the position is not part of the resource. I wonder how we should handle this, since I do like the otherwise improved editor experience.

[KoBeWi]

See my comment in that issue.

[Calinou]

Tested locally, it mostly works correctly. There are 2 issues I noticed:

• Snapping acts weirdly: your non-snapped movement is still added to the final size if you start holding Ctrl after moving the mouse, which is unexpected. Instead, the size should be snapped to an absolute value.
• When downsizing, you can't resize to below half of the original size unless the mouse moves slowly enough. This occurs regardless of whether snapping is enabled. (This is likely because Godot thinks you're trying to resize it below 0 on one axis.)

Also, once the logic behind this is stabilized, this should probably be moved to reusable functions so that it can be implemented in similar gizmos like CSGBox3D, VoxelGI, ReflectionProbe and GPUParticlesCollisionBox3D. I would suggest rebasing first still as the code structure in master has changed a fair bit already.

[KoBeWi]

When downsizing, you can't resize to below half of the original size unless the mouse moves slowly enough.

As I mentioned before, it's a result of how get_closest_points_between_segments() works. Although I have an idea for workaround, maybe it will work 🤔

Also, once the logic behind this is stabilized, this should probably be moved to reusable functions so that it can be implemented in similar gizmos like CSGBox3D, VoxelGI and ReflectionProbe.

That's what I plan to do, but I wanted this PR to be merged first.

[rburing]

Unless shape resources are going to be duplicated on copy by default, I think the convenience of this PR is not worth the confusion that will be caused by applying this operation to a shared shape resource.

With that big side effect I don't think we can reasonably make this behavior the default. If it is implemented at all it should somehow be made clear that it affects (in a weird way) other resources sharing the same shape.

[KoBeWi]

The problem with shared shapes is that they change size unexpectedly, not that they are displaced. This PR doesn't make it any worse.

[KoBeWi]

Ok rebased.
I fixed snapping and the half-size bug.
I also noticed that for some reason pressing any key would cancel gizmo operation (which most notably made using Alt/Ctrl impossible). I changed it to use only Escape/Backspace.

There is one thing that I think could be improved tho. Right now I'm setting original_size and original_transform in get_handle_value() method and it's hard-coded for box shape only. It's a rather hacky solution, I think some callback like handle_grabbed(), called when the user starts interacting with the gizmo, would make it much cleaner. Is it a good idea?

EDIT:
Done in second commit. I'll squash when it's approved.

[Calinou]

Works great now! The only issue I noticed is that the snap length is halved when not extending relative to the center by holding Alt. (For instance, snap length is 0.5 units when it should be 1 unit.)

[KoBeWi]

Unfortunately I don't know how to fix the half snapping. If I simply multiply by 2, I end up with some weird offset. I tried different combinations, but none made it work correctly :/
It's a minor thing compared to the overall better usability, so IMO this is something that can be fixed later.

[Calinou]

Tested locally (rebased on top of on top of master dfebfd1), it works as expected.

Code looks good to me at a glance. Given how much this improves usability, I think this can be merged now and @KoBeWi can take a look at making this code more generic to work with similar 3D gizmos.

simplescreenrecorder-2023-08-01_17.54.51.mp4

[akien-mga]

Probably worth a rebase before merging as this was last updated in April.

[akien-mga]

Thanks!

[Kluskey]

Thank you!! This is super helpful

[huesonmcgee]

Will this apply to CSG as well? If not that would be exceptionally helpful during the prototyping stage.

[KoBeWi]

There was a follow-up that applied it to every existing box gizmo: #80278

[huesonmcgee]

Awesome, thank you. This is a well appreciated addition.

[TrainzMarcel]

this is awesome!!!! this is something ive wanted for so long