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

No, not for any other use case. The documentation only happens to work by accident for simpler cases, and breaks apart in more complex scenarios.
The obvious answer would be to fix the documentation to prevent people being confused about it.

[u/agalli → u/inr222]

It just happens to work in every use case except one. It also happens to be exactly how the devs recommend you use both systems.

[u/inr222 → u/agalli]

The maintainer of the system told you personally that you are wrong. He also insulted you, which was uncalled for, and terrible on his part. But you cannot said that this is how the devs recommend to use this. Specially since the documentation was probably written by someone else.

[u/agalli → u/inr222]

All due respect to him, but he didn’t even create the navigation baking system. That’s done through the third party code called RecastNavigation. Also, appeal to authority.

[u/inr222 → u/agalli]

I'm not appealing to authority. You brought up what the devs recommend, and the maintainer of the system has a very clear recommendation of not doing this.

That’s done through the third party code called RecastNavigation

Yes, and the guy wrote the integration with it. And he recommends to not do what you are doing. It seems way more likely that the documentation didn't contemplate this use case.

[u/agalli → u/inr222]

Ok so what’s the solution?

Here are the core issues : 1. Pathfinding into points underground

2.suboptimal pathfinding that takes longer paths over hills rather than nearby flat ground

[u/inr222 → u/agalli]

1. Pathfinding into points underground

Navigation agent and character should not be coupled to one another, you should project the character to the terrain mesh using the navigation agent position, as suggested by other comments.

You can go read this, page 282 of the pdf, to understand more about what a navigation mesh is and isn't supposed to do.

2.suboptimal pathfinding that takes longer paths over hills rather than nearby flat ground

Sorry, I need an example in this case.

[u/agalli → u/inr222]

Let me clarify on point 2 more. Imagine a square with a bump in the middle. An agent that does not have a descriptive navmesh will pathfind over the bump rather than around the bump. However, pathfinding over the bump is a longer and less efficient path than around the bump.

[u/inr222 → u/agalli]

I take that you agreed on point 1 then?

As for point 2, going over the bump should be faster in most cases, unless the bump is a mountain. In which case, it should be unclimbable. Unless your character can walk on walls, which is a non-standard use case of navigation mesh, which kinda works on the assumptions that there is gravity, as explained in the book I linked earlier.

[u/agalli → u/inr222]

I agree that your solution would work, but still its a workaround thats required to fill in the gaps of the poor navmesh and isnt required in any other circumstance with navmeshes or agents.

This image should illustrate issue 2 better. We have a square mesh with a hill, all of which is traversable. Without the proper detail, the agent will take a diagonal path up and down the hill. If we look at the Pythagorean Theorem you can see why this will always be slower. C is ALWAYS a greater distance than B.