Trouble using navigation in 2D with tilemaps

Archive
1
:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By Tar_Get()

My question involves future plans of how the tilemap navigation will be implemented.

I’m pretty far into developing a sandbox colony simulation. GDscript and C# are performing much better than I thought for so much code! Godot’s pretty dope.

Currently, to simulate mining, I remove a wall (as an automapped terrain set) then add a nav tile on a separate tilemap for the NavServer/NavAgent to use. The nav tile has a nav mesh defined to the outer edges of the tile (making the nav mesh smaller makes the system even slower). When I have a group of 100 agents mining tiles, the framerate drops to 1 FPS (probably lower). The map is 200x200, but even with a 50x50 tilemap, it slows down to around 50 FPS. The larger the map, the more tiles the tilemap has to update to rebuild the nav mesh.

It’s definitely the nav tilemap.set_cell function that’s slowing everything down.

I switched to astar with a basic custom nav array and I don’t lose a frame (165hz monitor) with the same procedures. I like astar, but it’s a little too precise (robotic) to simulate human movement without a lot of tweaking. It also lacks built in avoidance.

Does anyone know if the tilemap update will become more localized in the future? It seems like rebuilding the entire nav mesh is incredibly inefficient.

Or maybe I’m just using it wrong?

2
:bust_in_silhouette: Reply From: smix8

You are not using it wrong, it is a limitation of the current navigation mesh system that it can not do more local updates, instead updates everything on changes.

Short term this is difficult to change. There is a lot of technical depth to dig through as the system was not build with incremental or local updates in mind when it was first invented.

There are a few pull requests that might help to mend a lot of the major performance issues already. One major performance offender for tile based games are the edge connection calculations. You dont seem to be using edge connections but they are still calculated. Those edge connections are not a hard requirement for connecting navigation meshes or for using the navigation system and should be made optional so save performance. This is the goal of pr Make navigation mesh edge connections optional by smix8 · Pull Request #75601 · godotengine/godot · GitHub

The performance cost of edge connections is what you are experiencing when you mention that shrinking the navigation meshes smaller makes the system even slower. By doing this shrinking suddenly every single navigation polygon edge can not be merged by vertex which would be cheap. They now all need to go through the expensive edge connection calculation.