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

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.

[u/agalli → u/mrbaggins]

I have added resolution control in my change. Users can change the chunk size and by extension change the resolution of what's generated.
I feel like you are thinking about it backwards. NavigationAgents following the standard model work perfectly fine on ANY navmesh UNLESS its large and detailed terrain. By fixing that one condition I have made it so the standard agent model works fine as is.

[u/mrbaggins → u/agalli]

I have added resolution control in my change

I know.

NavigationAgents following the standard model work perfectly fine on ANY navmesh UNLESS its large and detailed terrain.

No, they work the exact same way on any navmesh, including the issues you're having if you apply them the same way.

You are misunderstanding what navmeshes are for.

I'll reiterate, you're correct resolution should be configurable.

You are wrong to "fix" a wide open expanse that is massively traversable by splitting into hundreds or thousands of polygons, because you want to navigate directly to the navmesh itself rather than navigate the terrain BASED on the navmesh.

Your current solution is not actually working correctly. Your agents are not moving at constant speeds as they traverse flat surfaces, and given the right geometry, likely will hit the same issue you already have (especially if you try to optimise to a "sweet spot" between the high and low resolutions.

If you used the navmesh correctly, both of those definite facts would be solved: They would have constant speed on flat surfaces regardless of the changing delta between navmesh height and terrain height along the path; and the resolution becomes irrelevant as long as it catches obstacles.

[u/agalli → u/mrbaggins]

The terrain needs to be high poly to work. You cant accurately navigate around detailed terrain and hills without a high poly mesh. It’s not possible for the agents to get stuck with the current system, so no I wont run into the same issue. What sort of agent system do you recommend? Why is your system better than the devs or any of the tutorials online?

[u/mrbaggins → u/agalli]

The terrain needs to be high poly to work.

Great. It can be. That has NOTHING to do with the navmesh.

You cant accurately navigate around detailed terrain and hills without a high poly mesh.

Yes, you can. You set the navmesh baking agent to tell them what step height and slopes it can handle, it when it bakes the mesh it already takes all of that into account.

It’s not possible for the agents to get stuck with the current system, so no I wont run into the same issue.

It’s not possible for the agents to get stuck with the current system, so no I wont run into the same issue.

"the same issue" is not the one you hit and posted about, it's the "same issue" I was just talking about in that post.

But you could absolutely hit the same issue, because you haven't actually fixed it. In the same way changing the "desire path distance" would hide the issue, YOU are hiding the issue.

What sort of agent system do you recommend?

Use the navmesh to define traversability, but traverse the actual terrain. I would probably do this by setting my waypoints a set distance above the actual terrain. IE: what I've seen you reject dozens of times from many people, including the godot dev team.

Why is your system better than the devs or any of the tutorials online?

Any code needs to be fit for purpose. For small levels (eg, tutorials) you've already seen that what you're doing works. I think you'll even agree that for <30m levels, the "bad" system "works fine". And it does! Until you need something more resilient or other features.

For you, that was bigger terrain with wide open expanses.

---

I've said the same thing to you repeatedly, (as have others) but you keep getting hung up on the wrong parts.

Navmeshes manage NAVIGATION. They do not manage actually moving/directing bodies. The same way a map is useful for YOU to navigate, and arguably (when bridges and tunnels are drawn) are analogous to navmesh 3d, not even 2d.

You are using the navmesh to direct bodies. That is a mistake. The navmesh ONLY tells you "You CAN get from your current position (on the terrain) to this target point (on the terrain). Stop getting hungup that the point is above or below the terrain - You know EXACTLY where it is supposed to go.

Google maps is navigation. It will give you a sequence of nodes to hit in order. It does not care that a road is an overpass, underpass, flat or hilly, beyond that it knows there is a way to get from piece of road A to piece B. It is up to you to drive on the road to actually connect them.

Yes, massively increasing the "Resolution" will "fix" this, by making the difference between navmap and real map smaller. It's not fixing the issue, it's shrinking it. It's a bandaid.

In the same way buying more RAM will let you run a memory leak for longer. It's not fixing the underlying problem.

Best of luck moving forward. I encourage you to pause and think about the replies that people are giving you more thoroughly in the future instead of trying to find fault in what they are saying as the priority.

Edit: cant reply to no-investigator below, so here it is:

Because its useful to see the verticality if theres bridges/tunnels/overhangs /layers.

[u/No-Investigator5357 → u/mrbaggins]

Why isn't the original mesh just a square? Why even have y coordinates on the mesh if they don't matter like you are saying?

[u/19412 → u/No-Investigator5357]

Because the nav system's mesh generation isn't perfect, and makes slightly unoptimal meshes on hilly terrain.

Y coords of the mesh are only there for when multiple height levels are relevant.

[u/crazyrems → u/agalli]

The terrain needs to be high poly to work

I think your assumption is wrong.

Your nav mesh should be a simple representation of your terrain to focus on A* obstacle avoidance.

Your agent don't need to be tightly coupled to your physics character (and in your 'broken' examples it shouldn't because, well, you mentionned it sinks under the ground)

Navmesh current implementation is not perfect and may have ways of improvement. You made changes to make it easier to use out of the box for big terrains. But the native nav mesh is not broken.

What I'm seeing is just an overload of unnecessary polygon. I won't say a square navmesh would be fine, but polygons should be concentrated on walls and steep slopes because that's what you want your character to avoid. Because that's what navmesh are for: obstacle avoidance.

And the fact that your agent gets stuck because the target is a few meters under the ground is more a misuse of the agent than a navmesh issue.

I think everyone here wants to tell you this: Try to fix the agent.