Scene drag-and-drop in the 3D editor is dependent on physics FPS, making it look sluggish on high refresh rate monitors

[Calinou]

Tested versions

• Reproducible in: 4.3.beta2, 4.3.beta 92c8e87

System information

Godot v4.3.beta (92c8e87) - Fedora Linux 40 (KDE Plasma) - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4090 (nvidia; 550.90.07) - 13th Gen Intel(R) Core(TM) i9-13900K (32 Threads)

Issue description

This means that at the default value of 60 ticks per second, drag-and-drop isn't as smooth as it could be.

drag_and_drop_60tps.mp4

It gets worse if you use a lower value in the project settings though, such as 10:

drag_and_drop_10tps.mp4

Enabling physics interpolation then restarting the editor does not avoid this issue.

While drag-and-drop depends on a physics operation (raycasting to determine where to place the dragged object), it can safely be done every rendered frame as raycasting isn't an operation that needs to be synchronized to the physics tick rate.

Steps to reproduce

• Decrease Physics Ticks Per Second to 10 in the Project Settings and restart the editor.
  • As an aside, we could apply changes to that setting to the editor instance without restarting the editor.
• Drag-and-drop a 3D mesh or scene from the FileSystem dock onto the 3D editor viewport.

Minimal reproduction project (MRP)

N/A

[ryevdokimov]

I commented on this briefly when submitting a PR for fixing a similar issue in 2D.

#87886 (comment)

Since this functionality relies on the physics server, having it query on regular process ticks will cause the editor to crash when physics is set to run on a separate thread. The only idea I have at the moment is to decouple editor specific physics functionality (this one and snapping to floor) somehow.

[Calinou]

having it query on regular process ticks will cause the editor to crash when physics is set to run on a separate thread.

We could do this when Run on Separate Thread is disabled at least (it's the default).

[ryevdokimov]

Yeah, true. Although, I think the relevant code is already pretty hacky, and doing that would kind of make it more confusing, but it would certainty solve this problem quickly with minimal risk.