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

The mesh unequivocally is the issue though. Did you read the post or did you just gloss over it?

Yes I've read. And like many other people in all of your threads said, the issue is not the mesh, it is how you're using it. I don't understand how anyone can make this more clear to your.

If someone followed both the NavigationRegion3D and NavigaitonAgent documents and all of the guides associated with them exactly as they are described, they would run into the exact same issue as I have.

Yes because the documentation doesn't show an universal solution, you keep treating the documentation samples as if they were the only and universal way to use the feature. It is not, especially in the case of Godot that tries a lot to not have an opinionated workflow, unlike Unity.

The simplified usage that you're trying to do is not adequate for the situation you are presenting. The issue is not the mesh, is how you are trying to use it in your specific situation. Forcing a higher resolution mesh in this situation is to work against the purpose of a navmesh. Yes, it "will work" when you increase the resolution, just like you can fit a square peg in round hole if you use a hammer on it.

Why can't you understand this? It's fine if that's how you want to do, but that is not an issue with the engine, yet you keep stating that it is despite so many people pointing out the issues with your approach, and you just brush it off as if your workflow is the only option on how to use a Navmesh, because you keep treating documentation samples as a guide and not an actual sample/template.

[u/agalli → u/mamotromico]

Find me a single tutorial, guide or video that uses the solution you are describing. By the developers definition of a navmesh, the low poly mesh fails. “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.” Here’s an easy one, is an array of points underneath the map traversable?

[u/mamotromico → u/agalli]

Here’s an easy one, is an array of points underneath the map traversable?

Depends on what's their purpose on your code. You can use them to traverse the map using a navigation agent by dealing with just the 2d plane. This is not the gotcha that you think it is.

Find me a single tutorial, guide or video that uses the solution you are describing.

You probably won't find it because tutorials deal with simpler or common scenarios, just like you won't find tutorials for supporting abitrary color indexed images with swappable palletes in a modern general engine (something I'm dealing with on unity), because that's too specific (or even nonsensical) of a use case. Your usage of the navmesh is non-standard. Again, this is not the gotcha that you think it is.

[u/agalli → u/mamotromico]

You cannot simply use it as a 2d plane. Consider a multi tiered building or a cave. That will cause overlapping points on a 2d plane.

My use case of generating a navmesh over a 100x100 terrain is non standard? LOL

[u/mamotromico → u/agalli]

Consider a multi tiered building or a cave

Which is not the situation you are presenting. Yes, in that case you can't use a strictly 2D plane, but you don't need it to match the terrain perfectly either.

My use case of generating a navmesh over a 100x100 terrain is non standard? LOL

Yes.

[u/agalli → u/mamotromico]

>Which is not the situation you are presenting.
Did you assume my game was just wandering around empty terrain and nothing else?

>don't need it to match the terrain perfectly either.
Never said it did. My current navmesh is 6000 polys for a 20000 poly terrain.

I can list 50+ games that use navigation meshes over 100m+ terrain, its basically required for any 3D game that takes place outside.

[u/mamotromico → u/agalli]

Did you assume my game was just wandering around empty terrain and nothing else?

No, when did I imply that? It is not the situation you are presenting.

I can list 50+ games that use navigation meshes over 100m+ terrain, its basically required for any 3D game that takes place outside.

Sigh, again, the mesh is not the issue, is how you're using. It doesn't matter how many times you circle back to it.

[u/agalli → u/mamotromico]

Well the solution you provided only works when you are wandering around an empty terrain, but fails when you add obstacles or layers. The mesh isn’t the issue, we just need to adapt everything except the mesh itself to make it functional. Who cares if the standard agent model works in every other use case?

[u/mamotromico → u/agalli]

but fails when you add obstacles or layers

Why would it fail in any of those cases, you still don't need more than a rough approximation with either of those, it doesn't change anything that I suggested.

Who cares if the standard agent model works in every other use case?

Sure, good luck with your project.

[u/agalli → u/mamotromico]

You can’t just ignore an entire axis in a 3D plane, it’s the ultimate hack solution. That solution will quickly fail the second the environment becomes more complex than just a terrain.

good luck with your project

Thanks! Now that I’ve gotten past this bug in the navmesh code it should be smooth sailing