Hi, I’m working on a NavigationRegion for my NPCs. I’m using a large GridMap, 56000 tiles for my map. If I try to bake the Mesh it won’t work properly. It doesn’t create a Mesh above my map, insted it creates a plane Mesh with the form of my map, but no height at y = -1900.
If I set my cell height to 0.5 ist bakes the MEsh correct, but it doesn’t work for my npcs anymore.
The standard cell size is set to 0.25, but this leads to serious performance issues. If I set it to 0.5, my npcs can’t navigate through my dense forest. If I exclude my forest and other decorations from the NavigationRegion, they can navigate through it, but get stuck occasionally. I guess this get be resolved by adding NavigationObstacles to the MeshLibrary, but I think it would decrease my performance even more?
Thanks
An unbounded A* search on a full detail map of that size could get very expensive; it’s basically a directed flood fill, so if there’s no simple path between two locations you could wind up visiting most or all of the nodes while hammering out the path. The actual path would probably be good, but the process of generating it could be unacceptably long.
I’d suggest having (at least) two level navigation; have a coarse top-level navigation grid, and then detailed grids in each region. Use the top level grid to get you a path made of fine grid cells, then use the detail grids to navigate across each.
It’s still just as much data (and in fact, slightly more), but by chopping it into sections you restrict the complexity of path generation.
Thanks for the help!
To do do that I’ll probably have to cut the gridmap into pieces, right? Or is there a feature in the navigationregion that lets me limit where it should bake the navigation? I haven’t found one but maybe I missed something?
NavigationRegion3D in the NavigationMehs properties if you scroll down there are properties to set a baking AABB. The navmesh will only be baked inside this AABB. This allows to use multiple NavigationRegion3D to create smaller chunk navmeshes. Each region will update on its own. The problem is that it will still parse all the nodes even when outside this AABB so if you have a lot of objects it will be still very slow.
You can also store these region navmesh chunks and load some of them around your player at runtime for performance.
Having that entire level fully loaded as one big navmesh piece will be close to performance impossible, way too large, way too much detail. Such large worlds need to be chunked. Godot does not auto do this for you behind the scene like some engines, you need to do that yourself.
As user hexgrid already said, use a coarse top-level navigation first that creates a path from chunk to chunk over the entire world to the target. When you know which chunks you need to go you query a detailed navmesh path into that direction for only the current or next chunk, and not across your entire world.
Querying a navmesh path over an entire world is usually a big performance waste. Chances are very high that something happens that requires a path update while the agent moves along that path. So only query paths for distances that are needed for next few seconds max. If the agent reaches the path end you query the next path segment until the agent reaches the final position on the world. Having a coarse top-level navigation makes sure that the agent is going in the correct direction while not having that navmesh fully loaded.
Using chunks is also good to “force” yourself as a dev to develop with that in mind from the start. When you only have chunks around your player loaded you can never even attempt to query a wasteful across-the-entire-world path because the navmesh is not loaded in. Having chunks will come in handy for other systems as well.
