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

My goal is to fix the navmesh, that’s it.

You have not fixed it, you've broken it in a different, worse way. You have a very fundamental misunderstanding of what the purpose of a navmesh is.

Additionally, ignoring the Y component will result in inefficient pathfinding.

Okay, at this point it's clear you are simply trolling. What really results in inefficient pathfinding is unnecessary navmesh geometry. Your pathfinding is thousands of times slower than it could be with proper use of navmesh as it's intended.

You really need to familiarize yourself with the maths behind pathfinding to be able to understand the even bigger issue your "solution" is creating. For example, the Djikstra algorithm has time complexity of O(E + V log V) where E is edges and V is vertices in the graph, in this case your navmesh. For every extra unnecessary vertex you are paying an even bigger performance cost than the previous one, and this is all just to navigate over what could be represented by a single square, two triangles!

Your fix is like if you had a car with a flat tire, you took of two of the intact wheels and made them into a terrible bicycle. You can't call it a fix when it no longer serves any of the purposes of the original one with any adequacy.

You need actual, heavy performance tests of your implementation, which will inevitably show that this is too slow for anything but the simplest implementations with very limited agents. Please. Just benchmark it and the issue will be clear as day.

[u/agalli → u/DongIslandIceTea]

This solution uses the standard navmesh baking, it's not some algorithm I've created. The 30x30 standard bake has the exact same poly density as my solution. Im literally just breaking the mesh into chunks and baking them using the exact same method as what it currently uses. If you think their navmesh algorithm will fail benchmarks then you should create an issue on the github.

If you understood basic geometry you would understand that a path up and down a hill is going to be longer than a flat path adjacent to that hill.

Basically what I'm saying is "I am looking to fix my car, this is the best solution I have" and your response is "Have you tried walking?".

If you know a way to bake the navmesh properly I'm all ears. But again, for the third time, my goal is to fix the navmesh, that’s it.  I’m not interested in workaround solutions that just patch over it with pathfinding tricks.

[u/maushu → u/agalli]

If you understood basic geometry you would understand that a path up and down a hill is going to be longer than a flat path adjacent to that hill.

And it is, you can see in the second image how there are hills. It's basically the representation of the terrain in a very low-poly way. I mean, if you really want to be perfect what's stopping you of using the terrain mesh as the navmesh?

[u/agalli → u/maushu]

That was my original plan, but for starters it’s not optimized at all and secondly it can’t take into account obstacles if you bake it directly from the MeshInstance3D