NavigationRegion3D generation with slopes and cliffs

Godot Version

Version 4.2.1-stable


I’m trying to generate a navigation region for a 3D map for the RTS game I’m trying to create. I’m struggling to find a way to generate a “clean” navigation region while having polygons for slopes. I’m using a single region for the whole map.
The map is generated from a heightmap using Zylann’s Heighmap Terrain addon, and the walkable slope is generated by code (the heightmap is lowered along a Path3D).

  1. With “max_climb” set to 0, the navigation region is clean (it remains flat on the flat ground, does not overlap the cliffs (at the bottom or at the top) and works flawlessly (no unreachable polygons at the bottom or at the top, and no clipping of the mesh by polygons). The only issue is that bottom polygons are not linked to top polygons, as there is no polygons generated for the walkable slope.

  2. In order to generate polygons for the walkable slope, I increased “max_climb” (for example to 0.5). Some polygons are generated for the slopes but not everywhere. There are 3 problems :
    a. Some polygons that were previously reachable cannot be reached anymore, whereas they are next to some where the character can go.
    b. The navigation region is not clean anymore (there is some clipping of the nav mesh by nav polygons (blue circles), polygons at the bottom and top of the cliff aren’t flat anymore and overlaps the cliff (red circles)),.
    c. Despite increasing the “max_climb” value, there are large areas where no polygons are generated for the walkable slope (yellow circles). I could not find a way to generate polygon for these yellow areas, I don’t understand why, the width of the slope is 12m while the cell size is 1m.

Do any of you know why I have these issues ?

Here are the Navigation Mesh parameter I’m using. (then I increased “max_climb”)

The 3D navigation mesh baking builds a voxel grid around your geometry and with such a low cell height (at least compared to the widht/depth) all slopes and heights will be your natural enemy. That the navmesh sinks into ground with such a low cell height is normal and caused by having too many height layers and the simplification process, e.g. the simplification max error and sample max error.

Ok thank you. I tried using a higher cell height, such as 1m, which stops the sinking of the navmesh into the ground in the middle of the flat surface, but all other problems remains (a: clipping at the top and bottom of cliffs, b, c). Also, when I do that there is a new problem, d: the distance between the navigation polygons and the ground is not constant anymore over flat surface, hence my character “floats” over the ground during navigation. I will find some other way.

Those are for the most part problems primarly caused by the source geometry. There is only so much you can tweak with the bake settings like cell sizes and the error margins when the source geometry causes bad span occupation and layering with the voxel cells.

The common terrain addons all create source geometry that is sub-optimal because they create overdetailed “grid” meshes from their heightmaps. If there are no other objects, e.g. static collision bodies from props, that break up those terrain meshes the navigation meshes almost always ends up very ugly on the more sloped parts because the voxels convert to very ugly spans and layers. I would expect that placing a few larger “rock” props with collision would fix half the issues immediately because it breaks the bad terrain mesh edges in those areas.

Yes you are right, I changed the map geometry and could get a cleaner nav mesh.

I changed the heightmap so that cliffs are verticals (I will add static bodies later) which fix issues b and c. Now my character can walk on most slopes and doesn’t get stuck. Now only issue a) is left : some location can’t be reached, no path seems to be found. In the above picture, my character can’t go to the other side of the yellow circle, as if polygons were not linked. This problem seem to happen where there are multiple thin triangles near each other (shown in the yellow circle).

Do you know why ?

I increased the “Edges max error” parameter value from 0.2 to 1, which reduce the number of triangles at that position and fix the problem. I still wish to understand but its not blocking anymore.

The navigation map has its own rasterization cell size, by default 0.25. Can be changed in the ProjectSettings navigation tab or with the NavigationServer API.

If more then 2 edgekeys try to occupy the same two cells on the navigation map that results in a merge error. The two edges are already merged, there can not be logically a third edge on the same place. Now sure there can be as we see in the image but not from the perspective of the rasterization grid.

Due to how ReCast works with the navmesh baking and the terrain addons have their source geometry it is sometimes possible that too many edges end up over the same cells that trigger those errors. See "Navigation map synchronization error" caused internally (by recast?) · Issue #85548 · godotengine/godot · GitHub for this issue.

1 Like

Understood, thank you.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.