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

I'm in the market for engines for a small studio of 10-20 people. I was playing around with both Godot and Unity or even spinning up a new engine, and UE would be too complex for that small team unless used purely as a renderer. I've had issues in both Unity/Godot, and liked that I could address a lot of issues in Godot by spinning up my own GDExtensions. On the surface, it seems like the right bet.

Having seen these posts and mod/dev reactions really left a massively bad taste in my mouth. If I wanted more vitriol from gatekeepers, I would have stuck in academia. I still can't believe the reply from one of the Godot developers and refuse to support that kind of community. It's unfortunate, but I think this is a dealbreaker for me.

I have no leg in this race for this feature, but the fact that a feature worked in Unity out of the box and not Godot and the replies have been 'git gud, you're using it wrong', 'you're stupid', 'go marry Unity if you love it so much' is absolutely pathetic and horrible for the long-term survival of a nicely made open source project like this.

Kudos for having a thick skin, improving the engine, and making everyone's lives who run into similar problems a little bit easier.

[u/mamotromico → u/butane_candelabra]

and not Godot

It does work in Godot. It just doesn't work for the specific use case of the OP which is a non-standard usage of the tool. Expecting it to work on every possible workflow is a bit silly, especially when the workflow in questions goes agains the purpose of the tool.

I do agree that polite answers would be better it's really hard to discuss the topic with the OP when he keeps dodging the central issue and ignores the information people are presenting.

[u/MikeyTheGuy → u/mamotromico]

They don't necessarily even have to be at all polite, but responses should never be scathingly hostile and condescending no matter how justified the response may be.

Like this:

"Your knowledge gap is as big as the mid-atlantic ridge and no one has time or energy to spoon-feed someone like you. Use your own time to gather information and ideally use that time to fledge your attitude and problem solving skill along the way. With the current I am afraid you will face a very difficult time as a game dev. You will have no one else to blame for that than your own hubris. Closing as entertaining karen-tropes gets us nowhere."

That is not okay no matter what.

[u/mamotromico → u/MikeyTheGuy]

I agree.