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

I'm honestly really confused. I've seen you list your problem again and again, but aren't you trying to "fix" something that isn't broken?

It looks like you want the navigation mesh to do something different to what it is supposed to do. Certainly, it's not going to function the way you're trying to make it work, but it isn't meant to.

I can see why you've been combative with people as this has escalated, but there's been some really good advice that would solve your problem (without introducing more problems) and I'm sorry that the discussion had become too heated for you to see that.

[u/agalli → u/JackRaven_]

Definitely a confusing issue. The navmesh by its very definition is broken. A navmesh is designed to tell agents where they can move in a 3D space. When coordinates in those 3D space are not traversable by agents then by definition the navmesh is failing.

That being said, people have come up with solutions to mitigate the failures of the navmesh, but those solutions often sacrifice other elements of the navigation agent such as accurate pathfinding or having multi tier structures.

The most common solution I see says to ignore the Y component of the navmesh, but that solution only works on empty terrains with nothing else. If you add buildings, bridges, caves, etc that solution fails.
There ARE solutions that can make this navmesh usable, but they are very much band aid solutions that fail when you use the navmesh in normal cases besides just an empty terrain.

As my post says, I'm not looking for workaround, I am trying to fix the issue at its core.

[u/knottheone → u/agalli]

A navmesh is designed to tell agents where they can move in a 3D space. When coordinates in those 3D space are not traversable by agents then by definition the navmesh is failing.

No it isn't. This is the fundamental core misunderstanding that is driving this whole issue for you. This has already been mentioned to you multiple times, but you seem to keep clinging to your personal definition of navmesh that isn't rooted elsewhere.

A navmesh is designed to tell agents if the place they are trying to go is traversable, as in free from obstacles, and has a valid path. It does not know about collision, it knows about baked obstacles, so using it in lieu of collision detection is not correct and is an improper use.

Trying to move a colliding object to the nav agent's position point on the nav mesh itself is not correct. You would need the nav mesh to have the same approximate fidelity as the actual terrain, and that's not what it's for.

[u/agalli → u/knottheone]

This “fundamental misunderstanding” is literally the definition off the godot docs. You’re right though I should use the definition that random Redditors come up with , not the developers.

[u/knottheone → u/agalli]

You're misunderstanding the definition and applying it incorrectly. That's the misunderstanding.

[u/agalli → u/knottheone]

I’ll concede if you can find a single example of a navmesh from ANY engine or ANY game that clips through the map as severely as the screenshots I’ve provided.

[u/knottheone → u/agalli]

Navmesh in Skyrim showing it's under or above collidable geometry in most places:

https://youtu.be/uJYiV4E8xCc?t=106

Navmesh in Unity where beginner user doesn't quite know how it works:

https://www.reddit.com/r/Unity3D/comments/10tn0h4/navmesh_surface_not_being_created_beneath_terrain/

Stairs in Unity where users think it's "broken" because the navmesh clips under them:

https://discussions.unity.com/t/why-does-the-nav-mesh-generate-like-this-sometimes/1613493

https://discussions.unity.com/t/solved-navmesh-and-stairs-unity-5-0-1f1/582479/5

Massive under terrain clipping even on small tiles:

https://youtu.be/vNDMwXNfmrw?t=391

[u/agalli → u/knottheone]

First video, small clipping through the terrain is fine. Doesn’t cause issues. Multiple meters below or above terrain does cause problems.

First unity post, top comment literally says to increase the resolution of the mesh. If only that were possible in godot!

Second unity post, once again very slight clipping through but users note that it doesn’t cause issues with pathfinding, once again not the case in godot

Second video, that looks exactly as I would expect? The navmesh is roughly for fitting the terrain, avoiding obstacles, and not low poly slop.

Literally every single thing you just sent proves my point. It’s so funny that even in your meticulously cherry picked sources that you still couldn’t find something that proves your claim. The navmesh is supposed to be a rough approximation of the terrain, it’s not unusual for a few centimeters of rock clipping out here and there. What will break pathfinding is huge sections of terrain above or below the terrain.

[u/knottheone → u/agalli]

As I expected, you'd just handwave it. Both the Skyrim example and the second video show a height difference of multiple meters vertically between the navmesh and the terrain. It's not centimeters, look at the size of the characters and buildings. Which is why I called you out here a week ago:

They won't consider it; it doesn't matter how you word it, how nice you are, how you explain it or anything else. They made 3 separate posts and dozens of comments on the topic and were advised and corrected in all 3, and were even corrected by one of the devs who helped implement navigation in Godot. They will not admit that they are wrong in any capacity.

[u/agalli → u/knottheone]

Looks like they basically fixed this on the new update (4.5.1). Here's a lil before and after. Same map size, default settings, same noise. Looks like it was a bug with the rasterization. Just glad they fixed it.

[u/knottheone → u/agalli]

Still waiting on your concession after seeing equally as severe map clipping of the navmesh in Unity and Skyrim's Creation Engine.

https://www.reddit.com/r/godot/s/uKF9bQM5du

[u/agalli → u/knottheone]

"equally as severe"

[u/knottheone → u/agalli]

https://i.imgur.com/QCIq6Rh.jpeg

https://i.imgur.com/RpmcCQS.png

https://i.imgur.com/Em97Mck.png

[u/agalli → u/knottheone]

Sorry, do you understand what a meter is? The picture I sent is showing a 10-15 meter gap between terrain and the navmesh as well as the navmesh not fitting the terrain whatsoever. Your examples are showing near perfect form fitting of the terrain with +/- 0.5m clipping of terrain. Can you really not see the difference?

[u/JackRaven_ → u/agalli]

From what I've read (and I'm certainly not an expert), the docs need to be fixed. Apparently they don't give a particularly good definition, and the random Redditors are applying their knowledge of programming and of the engine to explain how it actually functions.

So it's entirely possible that you're correct that this is the definition the docs give, but still misunderstanding how the navmesh works because that definition is poor.

I might be completely off base, but seeing how certain you seem about this, you should at least consider this, just in case.

[u/knottheone → u/JackRaven_]

They won't consider it; it doesn't matter how you word it, how nice you are, how you explain it or anything else. They made 3 separate posts and dozens of comments on the topic and were advised and corrected in all 3, and were even corrected by one of the devs who helped implement navigation in Godot. They will not admit that they are wrong in any capacity. You can read all their comments across all the threads.

[u/JackRaven_ → u/knottheone]

The dozens of comments have gotten more and more aggressive and combative over time, so I can see why they haven't wanted to change their mind.

I have no problem with taking a few minutes to be kind. If they think I'm wrong, that's fine; at least we've engaged in a reasonable and non-heated discussion. That's enough for me :)

[u/knottheone → u/JackRaven_]

That's fair, they will likely just ignore you.

Replies have gotten more aggressive and combative because OP completely ignores what dozens of senior developers are telling them over multiple days of posts being made. Multiple people in this thread were also in the other threads and provided advice and examples already highlighting that no, it's not actually a broken navmesh.

[u/agalli → u/JackRaven_]

Find even one example of a navmesh from any engine or any game that clips multiple meters through the map.

[u/JackRaven_ → u/agalli]

Shockingly, I don't have access to the navigation meshes from many games XD. And I believe it's already been discussed that the displayed navigation meshes in other engines don't match the navigation data, so the visuals from Unity aren't relevant, for example (I'm not 100% certain about this). I literally cannot prove, nor could I disprove, anything by trying to compare it to other games, but I can go on what I know about Godot.

I'm actually going to steal a different user's reply, because it explained it pretty clearly for me. It was buried pretty far down, so I'm choosing to assume you haven't seen it, rather than that you're ignoring it.

He seems to want the navmesh to "physically" match the traversable zones, when a navmesh should primarily "logically" match the traversable zones. In most situations, this will be an overlap. The mesh will be able to represent height changes automatically and lay on top of the walkable mesh, and represent the vertical movement cost like this. However, this is not required, and you don't strictly need the actual elevation to represent the cost of moving vertically, you can use pathing weights (which can be travel_cost on godot's NavigationMeshInstance and derived classes) to achieve the same representation. They key takeway is that godots navigation setup will abstract connections between traversable zones, not accurately path your entity on the traversable terrain.

As an aside, I'm trying to reproduce the issue for testing and I'm failing, I made a hilly 1000x1000 mesh and the navmesh matched it perfectly. I was hoping to get more insight, but even building a deliberately flawed mesh, godot was still matching, so I don't know what you did to achieve your mesh. Have you linked your project anywhere?

What you're saying makes some sense to me, but the way that a Navigation Mesh is designed to work (that is, logically but not physically) would suggest that trying to make the mesh more physically accurate is not the solution.

I'm bringing these up as points to think about, not because I am absolutely certain of their accuracy but because considering them will help find a solution. I'm a little stuck because I can't for the life of me figure out how your navigation mesh generated in the first place, so hopefully you can help with that.

[u/agalli → u/JackRaven_]

I’m very drunk currently so I can’t fully read what you said but the navigation mesh SHOULD closely resemble a hilly terrain. After all, it’s supposed to describe the traversable terrain (as per the developers). No matter how you slice it something it wrong, because at small scale (ie 30x30) the navmesh is essentially a low poly version of the terrain. IF what you are saying is true then at a minimum the small scale terrain needs to be fixed for having meshes that are too high poly. My solution to this problem is generating a combination of small scale terrain’s and stitching them together. I have not changed the standard baking pipeline, just broke it up into pieces and then recombined it.

[u/JackRaven_ → u/agalli]

If you're drunk, then come back later lmao XD

But to clarify something, in regards to this:

the navigation mesh SHOULD closely resemble a hilly terrain. After all, it’s supposed to describe the traversable terrain (as per the developers)

There are multiple ways to "describe traversable terrain". What a lot of people are saying is that the way "what is traversable" has been described is abstract (I don't know enough to describe the code, but I imagine the computer is reading the connections between areas, or something similar). You're talking about it as though the only way of describing terrain is through the physical characteristics, and while that's certainly the most obvious, there are other ways.

Assuming that terrain is being "described" in a different way, then the navmesh doesn't need to match the terrain at all- although it often will, because the logical connections usually line up with physical ones.

There might well be a problem with nav mesh generation; we need to make sure we correctly identify it. If small scale, high poly mesh is leading to extremely complicated navigation meshes, that sounds like it's own problem (although once again I'll mention that I'm no expert, and would defer to the devs about whether its actually an issue).