Open Calinou opened 4 months ago
I commented on this briefly when submitting a PR for fixing a similar issue in 2D.
https://github.com/godotengine/godot/pull/87886#issuecomment-1925030050
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.
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).
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.
Tested versions
System information
Godot v4.3.beta (92c8e87cd) - 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.
https://github.com/godotengine/godot/assets/180032/de51535f-5561-43ad-bd70-6916fd72c425
It gets worse if you use a lower value in the project settings though, such as 10:
https://github.com/godotengine/godot/assets/180032/826bf8a9-9db7-4318-a11e-c87b021032d3
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
Minimal reproduction project (MRP)
N/A