Physics, Intersection and Editor Plugins

[donn-xx]

Advised to open a proposal here by godotengine/godot#87429 (comment)
Hope I did it right.

Related to godotengine/godot-proposals#7811

Overview

Can we have a conversation about support for "intersect_X" in editor plugins?

For example, in my "Dabber" plugin, I need to send rays down to colliders to pick points where I will place a transform to go into a multimesh. I need to know where other things are before I place a new thing. In that thread I was asking about whether Godot has an API for spacial queries (in plugins). I only realized recently that the state.intersect_shape() method is pretty much already that; hence my bewilderment at it not working in the editor.

Examples of use

1. https://github.com/spimort/TerraBrush
2. https://github.com/HungryProton/scatter
3. My own Dabber plugin https://gitlab.com/dbat/godot-scatterator (wip now stalled)
4. Godot Official is even working on a terrain plugin/feature. Implement Terrain godotengine/godot-proposals#6121

What use is terrain if one cannot populate it? The reality is that some physics needs to be accessible from Godot plugins.

Physics is disabled in the editor

(The dev in quote below speaks of "Physics" and I find I'm not sure what that means. I'd like to use the intersects functions in the PhysicsDirectSpaceState3D class. That's what's underneath this discussion.)

Continuing from Quote by @smix8 at godotengine/godot#87429 (comment)

PhysicsServers are disabled by the EditorNode inside the Editor for both performance reasons and to not have shape conflict with the ray picking done by the Editor Plugins for that node and the Editor Viewport.
This means all the more advanced physics stuff that requires an active physics server doing step() updates every physics process do not work in the Editor. As seen by the code comment that the Editor does not run full physics simulation is intentional and by current design.
Most users do not know that when they work with physics nodes inside the editor that there is nearly never physics from those nodes. The "physics" is almost always added by an Editor Plugin for that node and the plugin only adds the bare minimum to keep the object picking functional inside the editor. This means basic stuff like raytesting works because the editor plugin adds a similar "picking" shape as the node has.

Now enabling full physics inside the Editor is not a good idea. There are already many instances of users complaining about editor performance, e.g. all TileMap users at some point. Having full physics run inside the Editor for all objects would make all those users hardware melt and explode. Godot has many users with toaster hardware that need to be considered and supported.

What if a plugin could have a "Go" button which then:

1. Starts the "physics" (like intersect_shape).
2. Runs its loop and does it's job, like scattering meshes.
3. Stops the "physics".

So it need not be on all the time; only while doing a user-initiated job.

This brings use to ... even if Godot would change this, as an addon maker expecting users to run a full physics simulation so that basic addon functionality works is never a good idea. Basic object placement or ray-testing can be done entirely with simple trigonometry checks not requiring physics at all. E.g. Geometry3D functions and some AABBs to improve performance if you have many objects that your addon needs to care about.

Picture this:

1. A terrain made of multiple chunks of meshes (with their colliders).
2. Other meshes overlaid to build levels and such. It's getting complicated. Meshes all over the place.

Now, please explain how with trig and Geometry3D you can distribute points across all of that such that:

1. Only the UP direction is involved.
2. The points don't overlap (below some bounds)
3. Certain areas do not receive those points at all.
4. Surfaces underneath (or within) other meshes are ignored.

And that's just to start. I do not believe that it's as simple as the quoted. And, if it is, why can that not be wrapped in an API and made available to users of Godot?

Also, what is the difference between this "simple" approach and what Godot physics is already doing?

Paths to progress

1. Is there something "simple" within Godot's exisiting "physics" that can be plucked-out and used in plugins via scripting?
2. Is there any way to use C++ in GDExtension for a plugin writer like me (and several others) to get access to what Godot can already do (ito "physics")?
3. Is it perhaps possible for a plugin to play a scene (ie F5) so that it is not in the editor and can then access all the powers required and write some kind of data file out for the plugin to use when back in the editor? This sounds awkward, but might be a solution.

Thanks.