NavigationRegion3D Bake NavMesh gives undesirable results

[NickSw1ft]

Godot version

4.0.3.stable

System information

Windows 10

Issue description

NavigationRegion3D Bake NavMesh creates starge shaped polygon when with both default values and after trying to tweak something. Tried with both CSG and Meshes. Also tried by using CSGCombiner. Nothing works properly.

Steps to reproduce

• Create a 3D Scene
• Add NavigationRegion3D node
• Add two CSGBox (or MeshInstance3D with Box Meshes) nodes as children of NavigationRegion3D. One for floor and one as an obsticle. Make floor bigger and line obsticle so that it is on top of the floor.
• Bake NavMesh

Minimal reproduction project

mrp.zip

[AThousandShips]

What is the issue here? The mesh looks fine to me, what are you expecting/wanting? Is it that the mesh doesn't fit perfectly around the obstacle?

[NickSw1ft]

What is the issue here? The mesh looks fine to me, what are you expecting/wanting? Is it that the mesh doesn't fit perfectly around the obstacle?

Yes. In tutorials it fits almost perfectly with mush more complex scenes e.g. this: https://www.youtube.com/watch?v=-juhGgA076E&t=267s And I have just a single cube as an obsticle and navmesh is all over the place

[AThousandShips]

I can't see any clear view in that video that shows what you say, can you give a timestamp to show that (your timestamp shows code editing)

[NickSw1ft]

Here https://youtu.be/-juhGgA076E?t=101 It shows that he didnt have to lower the cell size for navmesh to behave good

[AThousandShips]

First, you need to format your links correctly, you're linking to just "URL"

Second, have you changed that setting? Because you aren't necessarily using the same size objects

[NickSw1ft]

Yes, it produces expected results when cell size is set to 0.01, which is the smallest possible value. But only when set to this minimum.

[AThousandShips]

What are you basing this expectation on? How do you expect it to look?

Does the current mesh create problems for navigation for you? It doesn't have to look "neat", is the distance from the mesh to the obstacle greater than the agent radius?

[NickSw1ft]

As this obsticle is on integer coordinates and is interger sized with no rotation, I would expect that with 0.25 cell size navmesh borders would look something like this (drawn in red): I found a workaround by setting cell size to minimum possible value, but afraid that it may cause futere problems with pathfinding, performance and baking navmeshes for larger scenes

[AThousandShips]

I suspect that making the navmesh that exact isn't useful nor would I expect it to be "neat", there is a very slight deviation from the radius I'd say but it's very slight, only a small area would be inaccessible where it technically should be included

My question again is, is this a source of problems for you? Does it prevent proper navigation?

[NickSw1ft]

I guess no, it doesn't. Just expected it to be looking nicer. Issue should be closed then, thank you for your time

[AThousandShips]

I mean there might be things to investigate here, if it does affect the usability of the navmesh

[smix8]

This is somehow expect as a result of the rasterization and the edge contour post-processing of the navigation mesh baking process.

Large planes with an obstacle in the middle create the worst case scenario for the default properties of the NavigationMesh.

If you lower the edge_max_error property value on the NavigationMesh you can see more clearly the grid cells affected by your source geometry. You will see that there are grid cells on the edges affected around your box that ideally shouldn't but this is sometimes not really avoidable due to precision errors with floats. This is basically the layout that the edge contour step in the navigation mesh baking process gets to work with which creates this "randomly" formed looking edges around your box.

[NickSw1ft]

I think you are right, but adding more objects and/or moving obsticle from center of the plane doesnt resolve theese isues. So the only way to get a clean looking navmesh is by cranking down the cell size

[smix8]

This is primarily a precision problem. By lowering the cell size you are increasing the precision due to creating more voxel cells for the rasterization.

The reason why such a lower value is not the default value on the NavigationMesh is because more voxel cells cost more performance to process and it is entirely level layout and scale depending if the default values are not sufficient.

[NickSw1ft]

Is it one time cost while baking navmesh or it will also cost when calculating paths in runtime?

[smix8]

The lower cell size only affects the navigation mesh baking performance directly.

Pathfinding performance is only affected by the amount of polygons and edges that you see in the debug visuals. So the lower cell size would only affect performance of pathfinding should the navigation mesh result be more detailed in general with more polygons.

[NickSw1ft]

Thank you for your answer! So I can just crank it down and bake once everything is set

[NickSw1ft]

It appears that setting cell size of NavigationMesh is not enough to fix everytging. I'm getting an error when running project. E 0:00:01:0698 sync: Attempted to merge a navigation mesh triangle edge with another already-merged edge. This happens when the current cell_size is different from the one used to generate the navigation mesh. This will cause navigation problems. <C++ Source> modules/navigation/nav_map.cpp:692 @ sync() But where else I could change cell_size is unclear

[smix8]

You will need to adjust the NavigationServer navigation map cell size as well.

You can change the default navigation map cell size in the ProjectSettings in the "Navigation" tab visible with advanced settings enabled. Or you can use the NavigationServer API to change a navigation map cell size at runtime with NavigationServer3D.map_set_cell_size(get_world_3d().navigation_map, new_cell_size_float)

The navigation map merges navigation meshes by also placing the vertices into a grid. The default cell size is 0.25 same as the NavigationMesh so if you went for a lower cell size on the NavigationMesh you also need to match it with the navigation map.

If the NavigationMesh cell size and the navigation map cell size are different sometimes the two vertices of an edge will land into the same grid cell (your error msg) which will make the navigation map fail the navigation mesh merge.

[smix8]

Closing as there have been new error msg added with the 4.1 release for this mismatch cases of navigation mesh cell sizes and navigation map cell sizes that tell users what they need to do to fix this error.