Make nodes handle their respective navigation source geometry

[smix8]

Makes nodes handle their respective navigation source geometry.
Also fixes init chain bugs with registering geometry parsers.

This PR moves the node specific geometry parse code for navmesh baking from the NavigationServer internals to the respective nodes. The PR also does a lot of cleanup and shuffles the init order to make the registering of navmesh geometry parsers possible the moment the NavigationServer is created. This fixes bugs that e.g. module users had when they wanted to create and register the parser in the module init together with their custom nodes.

Review note

While this PR looks large the bulk of the change is just a copy of the parser code moved from the navmesh generator to the nodes. Everything inside the node navmesh_parse_source_geometry() functions is 1:1 copy&pasta old code that can be more or less ignored in terms of review effort.

Reasoning

The PR #90876 enabled server externals like nodes and addons to hook into the geometry parse process of the navmesh baking. So there is no longer a reason for the legacy way of having only a selection of core node classes hardcoded clogging up the server internals.

One strong incentive for that parser PR was to remove all the node dependencies and specifics from the Navigationserver internals, just never got around to do the full change timely.

In general a server should not be responsible for nodes. As far as a server is concerned a node or a SceneTree does not even exist. So a server has no responsibility for supporting any node specifics or stay updated with all their quirks and changes.

Maintenance and contributor responsiblities also turned more and more into a mess.

With the node related code buried inside the server all kinds of contributors regularly missed supporting or maintaining node specific geometry parse code when they did node changes. This turned into a frustrating watch duty and maintenance burden for the navigation team. Having the parser code directly inside the related node files make this less of a problem because it is in everyone's face when doing prs and reviews for those nodes.

Another awkward occurrence was that node contributors started to add hacks inside the server internals to solve node specific hacks and node compatibility issues while the navigation team wasn't looking close enough. There is more headache with this on the horizon with multiple PRs open that want to add even more new geometry nodes or change existing nodes. So to sum up there is also an externality problem in the server economics with the current node related geometry parse code that this PR also tries to fix. Without changing the current way this is handled the problems will only get worse.

Changes

Cleanup of main.cpp

Removes all the navigation related code from main.cpp except for the NavigationServerManager::initialize_server() and NavigationServerManager::finalize_server() call on engine shutdown. Moved everything to the NavigationServer and NavigationServerManager classes and files that are always present in any build (at least as dummy).

Changed init order

The NavigationServer is now fully available after module creation after the MODULE_INITIALIZATION_LEVEL_SERVERS call. Previously the setup was split and so delayed that it only worked for scripts. Everything else had problems registering the parser in the engine init. Now everything that adds geometry parsers in the MODULE_INITIALIZATION_LEVEL_SCENE should be fine. This makes it possible to register node geometry parsers the moment the node classes are created and registered with GDREGISTER_CLASS. No need to spawn dummy nodes to create your runtime parsers to avoid those registering bugs.

Changes to nodes

All nodes that already had navmesh baking support had their geometry parse code moved from the navmesh generator to the node file.

For registering and managing the node parse geometry callback two new static functions and their related variables to store the parser RID and callback Callable are added on each node.

• The navmesh_parse_init() that gets called after the node had its GDREGISTER_CLASS to created and register the geometry parser RID and callback Callable on the server.
• The navmesh_parse_source_geometry() that gets called on every navmesh parse process for every processed node with the 3 parameters for the navigation mesh, parse data and the parsed node.

While the parser RID can be freed with the server api there is no need for it for engine classes that can not be toggled on and off at will. All parsers are deleted by the server on shutdown to have one less function that needs to be managed by every registered class.

[AThousandShips]

Will do a closer review when the pending reviews are resolved and CI passes!

[AThousandShips]

My bad push messup (git really is bad at indicating what the upstream is)

[AThousandShips]

To solve crashing and errors

[AThousandShips]

Correction to the above, the following works correctly, but needs some additional testing for the navigation function, needs to test for the validity of the navigation server when running in 3D disabled cases:

diff --git a/main/main.cpp b/main/main.cpp
index 9c12771df8..8263c8e16f 100644
--- a/main/main.cpp
+++ b/main/main.cpp
@@ -730,6 +730,9 @@ Error Main::test_setup() {
        // Default theme will be initialized later, after modules and ScriptServer are ready.
        initialize_theme_db();

+       NavigationServer3DManager::initialize_server(); // 3D server first because 2D depends on it.
+       NavigationServer2DManager::initialize_server();
+
        register_scene_types();
        register_driver_types();

@@ -3348,6 +3351,11 @@ Error Main::setup2(bool p_show_boot_logo) {
        // Default theme will be initialized later, after modules and ScriptServer are ready.
        initialize_theme_db();

+       MAIN_PRINT("Main: Load Navigation");
+
+       NavigationServer3DManager::initialize_server(); // 3D server first because 2D depends on it.
+       NavigationServer2DManager::initialize_server();
+
        register_scene_types();
        register_driver_types();

@@ -3418,8 +3426,6 @@ Error Main::setup2(bool p_show_boot_logo) {

        initialize_physics();

-       MAIN_PRINT("Main: Load Navigation");
-
        register_server_singletons();

        // This loads global classes, so it must happen before custom loaders and savers are registered
diff --git a/modules/navigation/register_types.cpp b/modules/navigation/register_types.cpp
index 8646039705..dbc9e53035 100644
--- a/modules/navigation/register_types.cpp
+++ b/modules/navigation/register_types.cpp
@@ -66,9 +66,6 @@ void initialize_navigation_module(ModuleInitializationLevel p_level) {
                NavigationServer3DManager::set_default_server(new_navigation_server_3d);
                NavigationServer2DManager::set_default_server(new_navigation_server_2d);

-               NavigationServer3DManager::initialize_server(); // 3D server first because 2D depends on it.
-               NavigationServer2DManager::initialize_server();
-
 #ifndef DISABLE_DEPRECATED
 #ifndef _3D_DISABLED
                _nav_mesh_generator = memnew(NavigationMeshGenerator);

Alternatively the navigation relevant code in register_scene_types should be moved elsewhere after server initialization

[AThousandShips]

Looks good and functions now, just pending my earlier review, one thing to consider would be optionally disabling the warning message on initializing the default server, or making it a verbose print, as it's a bit noisy

[smix8]

Changed the WARN_PRINT() to WARN_VERBOSE() as suggested.

[Repiteo]

Thanks!