[3.5] Backport default World navigation maps

[smix8]

Backports from Godot 4.0 the default navigation maps created with each World resource.

Some first-time setup fails with certain navigation related nodes if no map is set which makes procedual navigation in Godot 3.5 problematic. This allows the same placement flexiblity as in Godot 4.0 and also makes navigation tutorials more compatible.

Godot 3.5 still uses the old Navigation/Navigation2D nodes for compatibility but having a certain node structure as hard requirement to place navigation related nodes makes is very restricting and limits navigation gameplay.

If this gets merged NavigationRegions, NavigationAgents and NavigationObstacles will be adjusted in followup PRs.

The idea is that nodes that use a navigation map, e.g. regions, agents and obstacles, should use the Navigation/Navigation2D node parent if found and if not should use the default world navigation map as a fallback.

[akien-mga]

If this gets merged NavigationRegions, NavigationAgents and NavigationObstacles will be adjusted in followup PRs.

What kind of other changes will be needed for those?

Timeline wise, we're pretty close to the 3.5-stable release already as we're at RC 3. I'll probably build RC 4 in a few days (waiting for and working on a few important fixes before that), which should hopefully be the last RC before stable. So we don't have a lot of time to change the API further - but I agree that the more we can do to make the 3.5 navigation consistent with 4.0, the better.

IIUC this is a partial backport of #46786 ? That's a pretty big change and I'm not sure how well we can implement this in 3.5 without refactoring everything so close to the stable release. CC @groud @AndreaCatania @Scony

[smix8]

The changes for this to regions, agents and obstacles are internal and do not change the API. The 3.5 navigation nodes crawl up the scenetree to find the parent navigation. The only required addition here is that they need to join the default navmap when no parent node is found instead of silently failing their setup.

Looking at the larger navigation picture there are two main feature that touch the API and should be backported to 3.5 because they fix important issues or lift very annoying navigation restrictions already fixed in Godot 4.0. Everything else would be internal changes that users would not notice if done later, e.g. smaller pathfinding fixes.

One is the navigation layers from the just linked pr #46786 as navigation gameplay with multiple maps and access areas are crippled in Godot 3.5 without the layers to work with. A majority of the more complicated navigation gameplay issues that users reported are not solvable without them.

The second is the pr #47024 that fixes the edge merging between navmesh regions. In current Godot 3.5 is is nearly impossible to get meshes merged that are not perfect. Especially 2D navigation merging is nearly unusable in Godot 3.5 rightnow. Since half the issues from users are merging issues this will be a real "issue" struggle if this goes live.

If you give me a greenlight you have your backport by next week.

[akien-mga]

Well I trust your judgement, if you think this are must have in 3.5, and they can be backported without too much risk of introducing regressions, that's fine with me. The timing is not the best as aside from a few remaining bugs, 3.5 is basically ready to go - so we should go quickly with navigation changes so it doesn't block the release of all other finalized 3.5 features.

[smix8]

I can work on a tight deadline. Give me 2-3 days over the weekend and you can add it to RC4.

[akien-mga]

BTW, remember that there are also those three merged PRs that could still be worth backporting manually if they're needed for 3.5: https://github.com/godotengine/godot/pulls?q=is%3Apr+label%3Acherrypick%3A3.x+is%3Aclosed+author%3Asmix8

I tried cherry-picking them but it's not trivial and I don't have much experience/time to actually make sure that they're working as intended.

[akien-mga]

Thanks!