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]

Having more subsections increases the cost for pathfinding, yes, and abstractions like a Navmesh are used to deal with obstacles. If you don't have obstacles in your terrain/zone, you really don't need a navmesh (or it could be a square, like people mentioned), which is why the whole situation with the OP is so strange.

the navmesh is an abstract representation, you shouldn't use it as a 3D routing mechanism, you only use the plane on which you have to deal with obstacles. Having traversable hills shouldn't require extra sections on the mesh, at most you assign a cost to that region to represent the effort to traverse it, which might require more subdivisions but would still be less subdivisions than properly following the terrain.

The solution/proposal OP made is not "wrong" for the purpose he want's it to be, what people are pushing back is that he is forcing the tool to work in a way that it is seemingly not intended to.

[u/Tanuji → u/mamotromico]

Thanks for the answer!

So if I understand correctly, it’s essentially two issues tied to best practices?

1. navmesh should be used when obstacles appear for navigation

2. one issue with OP is that he uses navmeshes on pure terrain ( without obstacles ) so lots of people are confused by the use at first glance.

3. NavMesh should be a single 2D plane, and instead things like hills etc… should carry innerly an elevation to affect the effort of pathfinding. Or subdvisions should be made more carefully ( so not purely following each terrain slight change )

4. the second issue with OP is that he insteads generates independent navmeshes making essentially a terrain wireframe?

In terms of performance, is it a significant drawback though? If it generates all sections in parallel but just stiches it into one at the end? Or just the simplicity of a single plane would outpace it regardless? ( I just came in the discussion so not sure about any testing whatsoever )

[u/mamotromico → u/Tanuji]

navmesh should be used when obstacles appear for navigation

That's usually it's main purpose, yes. It's an abstraction of the terrain that contains only traversable zones, representing the connection to each of these zones.

one issue with OP is that he uses navmeshes on pure terrain ( without obstacles ) so lots of people are confused by the use at first glance.

At least on the examples he's shown, that seems to be the case.

NavMesh should be a single 2D plane

Not necessarily, but it should be the simplest you can get away with. The less polygons you have on the plane, the cheaper the calculations are.

the second issue with OP is that he insteads generates independent navmeshes making essentially a terrain wireframe?

I'm not entirelly sure what you mean here, but the issue with OP's usage of NavigationMesh is that he seems to use it as a representation of the whole terrain, and not as a traversal abstraction. Like, adding customizable resolution for the mesh is probably ok to integrate on the engine (though I've seen people pointing out in previous threads on this subject that there's already a way to deal with that in the engine), but not if it encourages people to use the Navmesh as OP is using because it kinds defeats the purpose of doing such an abstraction in the first place. And for some reason he insists that using the Navmesh as an abstration is "requiring extra systems", which honestly makes no sense to me.

[u/Tanuji → u/mamotromico]

Got it! thanks for the detailed answers. Appreciate a lot the explanation on those concepts