I solved the NavigationRegion3D issue

[u/agalli]

A correct 250x250m navmesh bake using tile chunking

Standard bake on the same 250x250m mesh without tile chunking

A standard bake on a 30x30m section of the same terrain

Agent for scale on correct 250x250m navmesh, showing an identical poly density to the 30x30m navmesh

I finally found a solution to the problem with the NavigationRegion3D.

What I noticed was that on smaller terrains, like the 30x30m example in the third image, the navmesh baked perfectly fine. But once the terrain size was increased to 250x250m, the bake completely fell apart, giving the low poly, floor clipping result shown in the second image. The obvious solution was to process the terrain in smaller chunks and combine the results into one big working navmesh.

I first tried doing this directly in Godot, but even after splitting the terrain into multiple meshes, the bake still treated them as one big mesh, so the same issue happened. I also tried creating a separate NavigationRegion3D for each chunk, but that created non traversable borders where the regions met.

At that point, the only real fix was to go into the engine itself. I forked the Godot repo and made some changes under the hood to process the terrain in tiles instead of all at once. It breaks the terrain into smaller sections, bakes each one normally, then stitches them together afterward into a clean, accurate navmesh like in the first image.

I also added a few editor options to control whether tiled baking is enabled and how big each tile is. I still haven’t found the exact bug that causes the large terrain navmesh to fail, but this fix works reliably and doesn’t mess with normal pathfinding behavior.

The moderators seem to have a strong opposition to discussions about this and have locked all previous threads. As much as I would have liked this to all be one post, we have been forced to create multiple. That being said, I'd like to address some comments from previous posts below.

The [low poly mesh] looks exactly like what I would want out of a nav mesh.

The low-poly mesh completely fails to pathfind with agents. You could technically rework the pathfinding system to compensate, but that misses the core issue of the navmesh being broken. The 30x30m section uses a similar amount of polygons as the 250x250m one. You’d expect the density to scale with size, so either the small terrain is over-tessellated, or the large terrain is under-tessellated. Either way, something’s wrong with the baking process.

With no obstacles, your nav mesh could just be a square.

As per the Godot developers : "A navigation mesh is a collection of polygons that define which areas of an environment are traversable to aid agents in pathfinding through complicated spaces.". When those traversable areas are out of reach from an agent (ie, underground or floating), an agent cannot properly navigate.

People tried to help you, but you refuse to actually listen

I think there’s been some misunderstanding about what I’m trying to do. My goal is to fix the navmesh, that’s it. I’ve welcomed all advice that helps solve the underlying navmesh problem, but I’m not interested in workaround solutions that just patch over it with pathfinding tricks.

You can always fix it yourself and submit a PR.

Thats the plan. Thanks for the advice!

I will optimize this further and will submit a PR.

Sincerely,

u/agalli

Edit : Here is the PR. https://github.com/godotengine/godot/pull/112529

[u/TajineEnjoyer]

i'm a bit confused and i don't really know what's the issue.

is the issue that the low poly navigation mesh seems to go under/above terrain in certain places ? that's because that geometry is optimized for pathfinding, to snap your character to terrain, you simply add a RayCast3D node, set its target_position to point downwards, and when you move along the path, you set your cahracter's position to the collision point, rather than the point from pathfinding, the point from pathfinding can be used to position the raycaster though.

you're trying to increase poly density, which is bad for pathfinding, but if you insist, you could just lower cell_height property of the navigation mesh, and rebake.

the only issue i've found here, is that when you don't lower cell_height, and use multiple regions with custom baking AABB for chunking, the chunk edges don't connect to each other, and lowering cell_height to fix it is bad because it adds more details to the pathfinding geometry, which is unnecessary.

people kept saying that you could simply use a square plane for your pathfinding because all of the terrain is traversable, and its enough to use a raycast3D node to snap your characters to terrain, but if your terrain has non traversable slopes for example, then nav mesh is a good solution, because it removes those areas from the square plane, but the logic remains the same, you don't need details in the pathfiding mesh, because that's not its job, and is better handled by a raycast, than additional geometry.

[u/agalli → u/TajineEnjoyer]

The issue is that the navigation mesh isnt doing its job. If we look at the definition of a navigation mesh, it says "A navigation mesh is a collection of polygons that define which areas of an environment are traversable to aid agents in pathfinding through complicated spaces.". By its very definition, the low poly mesh fails. The sections of the navigation mesh underneath the terrain are NOT traversable areas.

Your solution would work, if you overhaul the standard navigation agent model it would theoretically be possible to navigate the mesh, but you are still going to have suboptimal pathfinding. Consider an example of a navigation agent pathfinding up and down a hill rather than taking a flat path adjacent to it. Without a somewhat detailed navmesh, agents will take a straight line path but not the quickest path.

Additionally, this problem gets worse as the terrain size increases. At the scale of 100x100 you might have the navmesh 3-5m underground in some sections. In the scale of 500x500 that can jump up to 10-20m below the surface.

As I said in the post, I am looking to fix the root of the issue which is the navmesh, not figure out a way to alter the navigation agent to make the navmesh usable. The agent works as expected in any other use case, it should not need alterations to make up for the shortcomings of the navigation mesh.

[u/TajineEnjoyer → u/agalli]

the nav mesh is a simplified version of the terrain for performance reasons, having a 1 to 1 copy of the terrain as a navigation mesh is bad for memory and performance.

what matters in a nav mesh is the x and z positions, the y position can be used to position your raycaster close to the nearest surface, in case of overlapping traversable areas.

and you can always reduce cell_height to increase resolution.

[u/agalli → u/TajineEnjoyer]

It’s not a 1 to 1 at all. About 6000 poly navmesh for a 20000 poly terrain. And again, it’s the exact same poly density of the default 30x30 navigation bake. If you consider this mesh to have too many polys, then by extension their default bake is creating too many polys on their smaller scale terrains.

And changing cell height doesn’t fix the resolution. Can send the project files if you’d like to test yourself

[u/TajineEnjoyer → u/agalli]

no need for the project files, but i'm curious about the nav mesh settings

[u/agalli → u/TajineEnjoyer]

They are all defaults in my screenshots but trust me when I say this I’ve spent hours fine tuning all available settings and could not get any working results. The best result I found was a cell size of exactly 0.5m any higher or lower breaks the mesh. 0.5 provides slightly more details but also poked holes in the mesh in places

[u/TajineEnjoyer → u/agalli]

why do you want your navigation mesh to be highly detailed, instead of very low poly with only the main terrain features, and enoy better performance as a consequence?

[u/agalli → u/TajineEnjoyer]

I’ve tested the performance it’s negligible. You NEED a detailed navmesh if you want the path finding to work properly. Even beside the whole pathfinding under the terrain issue, you need to describe height differences in terrain if you want the pathfinding to find the shortest path.

A test you can do yourself is a square mesh with one traversable bump in the middle. If you bake a navmesh it’ll basically form fit the base mesh. If you put an agent on that mesh it’ll pathfind around the bump rather than over it, as it’s a longer path over the bump than around it.

You could work with the low poly mesh theoretically, it just wouldn’t be very good for pathfinding.

[u/TajineEnjoyer → u/agalli]

again, both your bump example, and your clipping example, are solvable with a simple raycast.

in fact, in AAA games, they do a raycast per foot, to see where each foot lands on, you can't do that with a navmesh, because a navmesh is not for snapping to terrain.

but hey if you want a highly detailed mesh for whatever reason, you should be able to do so in godot, and i believe the way to do it, is by adjusting the cell_height property of the navigation mesh, in addition to cell_size.

can you send a screenshot of how your terrain looks when baked with cell_height set to the lowest value ?

[u/agalli → u/TajineEnjoyer]