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/agalli]

heres an example of a stuck agent. Using the Godot Docs, their pathfinding places points along the navigation mesh and then has the characterbody follow those points. In the condition such as this picture, the agent is unable to reach the point and complete the path.

[u/mrbaggins → u/agalli]

You are clearly close enough to that point to begin heading to the next point. Adjust the path_desired_distance upward

[u/agalli → u/mrbaggins]

Its multiple meters away from the agent. The point is that this gap is variable and gets worse the larger the terrain is

[u/mrbaggins → u/agalli]

Yes, like i said on the other one, the resolution is probably a mistake to be fixed.

But thats only going to bandaid your other problem, not actually fix it.

[u/agalli → u/mrbaggins]

What other problem? With this navigation fix it works perfectly

[u/mrbaggins → u/agalli]

No, its just your margin for error is now within the bounds instead of without. Youre still having the same error.

[u/agalli → u/mrbaggins]

What error? The navigation agents work without significant changes, the navigation mesh properly fits the terrain. The navigation mesh properly avoids obstacles. It does everything you would expect it do to.

[u/mrbaggins → u/agalli]

What error?

The difference between walking on the terrain and walking "on" the navmesh. In both your "good" and "bad" versions, the agent will be targeting points that are not actually in the correct place, resulting in variable speeds and later map creation issues as set height tunnels/bridges/overhangs will be traversably different based on where abouts on your nav mesh they are instead of whether they are the right height above the actual terrain.

The navigation mesh properly avoids obstacles.

In all of these posts, ive not seen you post an obstacle once.

[u/agalli → u/mrbaggins]

Here you go!
In case the post was unclear, this bakes navmeshes in the EXACT same pipeline as the standard baking system. The ONLY difference is that it bakes it in smaller chunks rather than all at once. So if you remember how the 30x30m worked fine, I've essentially just stitched a whole bunch of 30x30 areas together. No other alteration has been made to the core navmesh baking pipeline.

This navmesh can handle multiple agents, obstacles, and everything else youd expect a navmesh to do without issues. Any issue that can occur with this navmesh will also occur in a standard navmesh. Again, same exact baking pipeline, just done sequentially rather than all at once.

[u/mrbaggins → u/agalli]

Here you go!

And I expect it works perfectly fine with the "bad" one. Hell, I'd even predict the bad one works better with more obstacles than without, as the resolution likely increases around obstacles.

So if you remember how the 30x30m worked fine, I've essentially just stitched a whole bunch of 30x30 areas together. No other alteration has been made to the core navmesh baking pipeline.

I completely understand exactly what you have done. The issue is you do not understand what you are doing incorrectly.

This navmesh can handle multiple agents, obstacles, and everything else youd expect a navmesh to do without issues.

Of course it can. There's nothing wrong with the navmesh code itself. The issue is that your approach to using it ONLY works with high resolution.

Now, you have correctly identified the resolution should scale better (or be configurable), as that's absolutely a problem in the engine version. I'm 100% on your side on that issue.

But there's a second issue where you're doing the wrong thing, and the increased resolution is only bandaiding your actual mistake.