Remove the Navigation2D and Navigation3D nodes

[AndreaCatania]

Describe the problem or limitation you are having in your project:
The Navigation System to work needs that the nodes NavigationRegion, NavigationAgent and the NavigationObstacle are wrapped by the Navigation node.

Most of the time the Navigation Node, for the reason above, is the root of anything; this is not really ergonomic, since you are forced to think in terms of Navigation System during game code design. Also, it force a pattern that is not in line with the other Godot features.

The Physics engine is really similar to the Navigation System. Indeed, as the Physics Engine with the Space, the Navigation System with the NavigationMap needs an object that contains all the objects, so to know the relationship between those.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
To improve ergonomic, I propose to get rid of the Navigation node, and threat it as the Space object for the physics.

This would mean that we would have the possibility to organize the NavigationRegions, NavigationAgents, and NavigationObstacles without constraints; similarly as we do with the RigidBodys.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
The idea is to add the NavigationMap RID in the World_*.h file, all together with the Space and the Scenario RIDs.
https://github.com/godotengine/godot/blob/master/scene/resources/world_3d.h#L48

Then, the nodes like NavigationRegion, NavigationAgent and NavigationObstacle, will use that NavigationMap RID similarly as the RigidBody and the other Physics objects do.

Regarding the various features that the Navigation node has, like the get_closest_point, these can be accessed via NavigationServer singleton (as for the Physics). Indeed, these functions, in the Navigation node, are just code sugar for NavigationServer calls: https://github.com/godotengine/godot/blob/master/scene/3d/navigation_3d.cpp#L35-L54

Regarding the Navigation settings, these will be moved in the Project Setting.

[Duroxxigar]

While I like the sound of this, how does this change usability? Would the navmesh generation just search the tree for all meshes or something? Or would it be more free flowing? Kind of like how in UE4, you can create a specific area that has a navmesh.

[AndreaCatania]

The navigation is global, so any added NavigationRegion is welded together if enough near.

If you need parts of the map that should not be navigable, you simply need to not add a NavigationRegion.

You can think it like the physics server, where the entire scene is in the same world.

[smix8]

All for removing restrictions how to organize nodes in a scene tree but one thing has me concerned with this change.

@AndreaCatania
How would it be possible to have multiple, independent navigations/groups at ones if they are all welded together behind the scene into one single map in a single NavigationServer?

Would this mean that with this change we would get "navigation bit" layers/masks similar to the physics space for NavigationServer maps, NavigationRegion, NavigationAgent and NavigationObstacle?

In Godot 3.x it is very easy to have different Navigation nodes for different purposes that don't interfere with each other.
e.g. one for walking actors, one for flying actors, one for swimming actors, one for "through-wall" moving ghost actors.

[AndreaCatania]

Probably we should have a layer / mask feature, or something similar. Consider that - if not close enough, the regions are not welded, but I agree that is useful be able to decide to not weld the two regions.

[groud]

I was about to open a new proposal, but I believe I can instead write things here. As I am reworking the TileMap node, I found quite annoying the need it would have to a Navigation2D/3D node as a direct parent too. So we discussed with @AndreaCatania about the different possibilities that were available to us. We kind of set up on the following solution.

First, we remove the Navigation2D/3D nodes. As those were handling the map RID for its children, this map has to be moved somewhere else. So the idea would be to move those maps directly into the servers themselves, in a similar manner to how it's done for physics layers. The maps could eventually be named.

Then, within the navigation agents, we would simply expose a bit field to choose the maps an agent is available to navigate on. And for regions/obstacles, we would have another bit field to choose the maps they participate to.

Unlike the current solution, this would allow an agent to navigate on two different maps at the same time. An example use case for this would be, for example, enemies of different elements. A fire enemy would not be allowed to go into water, a water enemy would be allowed only in water, and the player would be allowed in both normal ground and water. This would require two maps, one for the ground, one for the water, and the possibility to navigate between both for the player.

The only drawbacks for this method is the limited amount of maps it allows (16 I guess, like physics layers)?. However, I don't see a lot of use cases where this would not be enough.

[Zireael07]

The only drawbacks for this method is the limited amount of maps it allows (16 I guess, like physics layers)?. However, I don't see a lot of use cases where this would not be enough.

I can't imagine anyone needing more than 16 navigation maps tbh.

[akien-mga]

Fixed by godotengine/godot#46786.

[Vivraan]

Can a guide be created for migrating legacy Navigation[23]D code to code which uses Navigation Servers? In version 3.5.2 in my case, Navigation2D.get_simple_path() is not working as expected -- it doesn't generate a valid array.