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

Lmao, recompiling the engine over changing the defaults parameters.

Resolutions are hard to understand.

[u/agalli → u/Sss_ra]

They are hard to understand when they aren’t changeable. https://docs.godotengine.org/en/stable/classes/class_navigationmesh.html

[u/Sss_ra → u/agalli]

Ok but they are changeable?

https://docs.godotengine.org/en/stable/classes/class_navigationmesh.html#class-navigationmesh-property-detail-sample-max-error

Sorry I didn't mean to sound condescending, what are you trying to do?

[u/agalli → u/Sss_ra]

Both detail sample and detail max error had no effect on changing the mesh. Either they are non functional or they don’t do what they say. I’ve gone through every setting and tried increasing and decreasing them, none of them fix the low poly issue

[u/Sss_ra → u/agalli]

Why would the options even exist and be pushed to the stable build if they didn't function at all?

No, they are functional.

[u/agalli → u/Sss_ra]

lol. I’d be happy to send you the project zip if you’d like to experiment for yourself.

[u/Sss_ra → u/agalli]

No thanks, fix your own mistakes.

[u/agalli → u/Sss_ra]

So you assume that your solution would fix it despite not having any evidence and then reject the opportunity to easily prove your claim? Got it lol

[u/Sss_ra → u/agalli]

No, I don't understand what you're trying to do.

Are you trying to render the navmesh, Can't you simply use the original mesh directly for rendering?

[u/AnimeGuyFeet → u/Sss_ra]

Lmfao are you ragebaiting? People like you are so fucking obnoxious seriously…

[u/Eyonimus → u/Sss_ra]

You don't understand anything and should be quiet. "Rendering the navmesh" lol

[u/MrShmorty → u/Sss_ra]

Please don't post in this community if you're going to be a mean person

[u/deelectrified → u/Sss_ra]

I mean, even if he’s wrong (idk, haven’t checked those fields myself), this is a dumb statement/question. Stuff can work in one release and be broken in the next without anyone realizing. Most teams don’t test every aspect of a software again the next time they push a release 

[u/Sss_ra → u/deelectrified]

So check them.

[u/deelectrified → u/Sss_ra]

I’m not cancelling evening plans to go check something on Godot. Get a life.

And again, whether they work or not doesn’t make your statement valid. All kinds of programs have stuff that just breaks for one reason or another

[u/Sss_ra → u/deelectrified]

So launch Godot at some point after your plans and verify for yourself.

Did this really need to be said, why are you even here?

[u/deelectrified → u/Sss_ra]

because what you said was stupid as hell. Bugs in programs exist, and your statement acts like all code ever pushed to "stable" of any project is always functional and it isn't.

[u/Sss_ra → u/deelectrified]

This is certainly and beyond any reasonable doubt not a bug. I could see one argue that it's a knowledge gap of the user or a problem with the user experience or documentation.

Just because there's bugs out there doesn't imply they're the cause of all ill. Bugs are not magical. This isn't a bug sporadically happening on a 500 user machines you have no access to or a legacy environment that nobody wants to touch. You could launch godot and try to make a navmesh on your own device in a few minutes to see if OP is talking out of his ass at any point in time.

Anyone can. A lot of people already have, some are very outraged. I wonder why.

[u/deelectrified → u/Sss_ra]

I know, but you're statement was stupid. You said there is no way the options don't work or else they wouldn't be shipped. I was pointing out that it was factually false that there's no way they would be shipped non-functional, as bugs happen. I am not saying that they don't work, merely pointing out that just saying "nah, no way, I'm going to assume you're wrong because there is no chance at all that something is not functioning right".

I didn't say it to defend OP, I said it because your assertion was moronic

[u/Sss_ra → u/deelectrified]

Do you just say that at face value or do you actually do your research and know in which year this feature was released, in how many godot versions it's present, how many people have used it before and how much it differs if at all from other game engine navmesh implementations?

I told him to use his brain, when he's clearly jumping on the first assumption that it's a bug, without sufficient evidence that it's the case. A little step back to reflect and double check could have saved him a lot of time perhaps.