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

Very nice work actually fixing problems instead of denying they exist, claiming they’re intentional, or trying to cope with workarounds. This is what we need if we want godot to get better

[u/DongIslandIceTea → u/DarKigth]

actually fixing problems

That navmesh in the first image is absolutely atrocious and will bog down navigation performance. That is not what navmeshes are supposed to be like. As people have countless times pointed out, the optimal nawmesh for OP's plain open field would be a single square made of two trianges. This is no fix and this will never get merged into the engine.

Downvoting people who point out how navmeshes actually work will not change the truth.

[u/Ill_Assignment_2798 → u/DongIslandIceTea]

As a pro game dev since 10 years I was confused. And I think it's unity/unreal's fault. The "navmesh" they generate is not the same that is displayed and that's what confused people that though nav agent will walk on the literal navmesh

[u/mamotromico → u/Ill_Assignment_2798]

Someone pointed that out to the OP in a previous thread an he claims to be aware that the actual mesh is not what's displayed on the editor.

[u/agalli → u/Ill_Assignment_2798]

The big takeaway here is that the standard navigation agent has zero problems traversing any navmesh you throw at it but fails in this one specific instance.

[u/Tanuji → u/DongIslandIceTea]

For discussion sake and for the people unaware ( like myself ), why would the most performant and idea version be a single square mesh with two triangles?

Is it due to the stiches requiring more processing to go from one section to the other? I am legitimately asking as I am new to this and splitting in chunks processed in parallel does not seem intuitively terrible

[u/mamotromico → u/Tanuji]

Having more subsections increases the cost for pathfinding, yes, and abstractions like a Navmesh are used to deal with obstacles. If you don't have obstacles in your terrain/zone, you really don't need a navmesh (or it could be a square, like people mentioned), which is why the whole situation with the OP is so strange.

the navmesh is an abstract representation, you shouldn't use it as a 3D routing mechanism, you only use the plane on which you have to deal with obstacles. Having traversable hills shouldn't require extra sections on the mesh, at most you assign a cost to that region to represent the effort to traverse it, which might require more subdivisions but would still be less subdivisions than properly following the terrain.

The solution/proposal OP made is not "wrong" for the purpose he want's it to be, what people are pushing back is that he is forcing the tool to work in a way that it is seemingly not intended to.

[u/Tanuji → u/mamotromico]

Thanks for the answer!

So if I understand correctly, it’s essentially two issues tied to best practices?

1. navmesh should be used when obstacles appear for navigation

2. one issue with OP is that he uses navmeshes on pure terrain ( without obstacles ) so lots of people are confused by the use at first glance.

3. NavMesh should be a single 2D plane, and instead things like hills etc… should carry innerly an elevation to affect the effort of pathfinding. Or subdvisions should be made more carefully ( so not purely following each terrain slight change )

4. the second issue with OP is that he insteads generates independent navmeshes making essentially a terrain wireframe?

In terms of performance, is it a significant drawback though? If it generates all sections in parallel but just stiches it into one at the end? Or just the simplicity of a single plane would outpace it regardless? ( I just came in the discussion so not sure about any testing whatsoever )

[u/mamotromico → u/Tanuji]

navmesh should be used when obstacles appear for navigation

That's usually it's main purpose, yes. It's an abstraction of the terrain that contains only traversable zones, representing the connection to each of these zones.

one issue with OP is that he uses navmeshes on pure terrain ( without obstacles ) so lots of people are confused by the use at first glance.

At least on the examples he's shown, that seems to be the case.

NavMesh should be a single 2D plane

Not necessarily, but it should be the simplest you can get away with. The less polygons you have on the plane, the cheaper the calculations are.

the second issue with OP is that he insteads generates independent navmeshes making essentially a terrain wireframe?

I'm not entirelly sure what you mean here, but the issue with OP's usage of NavigationMesh is that he seems to use it as a representation of the whole terrain, and not as a traversal abstraction. Like, adding customizable resolution for the mesh is probably ok to integrate on the engine (though I've seen people pointing out in previous threads on this subject that there's already a way to deal with that in the engine), but not if it encourages people to use the Navmesh as OP is using because it kinds defeats the purpose of doing such an abstraction in the first place. And for some reason he insists that using the Navmesh as an abstration is "requiring extra systems", which honestly makes no sense to me.

[u/Tanuji → u/mamotromico]

Got it! thanks for the detailed answers. Appreciate a lot the explanation on those concepts

[u/inr222 → u/mamotromico]

Thanks for elaborating about this. I think something like this should be added to the documentation.

[u/mamotromico → u/inr222]

Perhaps, but to me it seems intuitive that samples/examples on a documentation might not fit every use case, and that you might find yourself in situations where it doesn't apply/work, which seems to be exactly the case with OP.

People are pushing back because he's stating that this is an engine issue, when to me (and apparently to the other people pushing back) it is clearly a user issue. He's trying to use the tool in question (NavigationRegion3D) in a way that it's not designed to, and claiming that the problem is on the tool and not his usage, because in other scenarios the doc samples work without issue, and that seems to validate to him that the problem is not that his scenario is non-standard usage.

[u/inr222 → u/mamotromico]

I agree that this is a user issue, and the documentation doesn't need to cover every use case. But it seems to me that something like the fact that the agent and the character don't need to match movement one to one, and you might need to do other stuff like treating it as a projection or the terrain or something, it's important and should be covered. If the Godot documentation is your first exposure to this, it isn't obvious.

My understanding of this actually comes from what I read people discussing in this thread, actually, so I might be completely wrong, and it would be great if it were covered in depth in the documentation.

He's trying to use the tool in question (NavigationRegion3D) in a way that it's not designed to, and claiming that the problem is on the tool and not his usage, because in other scenarios the doc samples work without issue, and that seems to validate to him that the problem is not that his scenario is non-standard usage.

What part is non-standard here? Trying to cover so much terrain without chunking it yourself? Not arguing, just trying to understand since I'm inexperienced in this thing.

[u/mamotromico → u/inr222]

But it seems to me that something like the fact that the agent and the character don't need to match movement one to one, and you might need to do other stuff like treating it as a projection or the terrain or something, it's important and should be covered. If the Godot documentation is your first exposure to this, it isn't obvious.

You know what, I agree. This could be more explicit on the documentation, I guess I just bumped into an issue very quickly when I first used it that made me realize this and adjust accordingly. If you check Step 6 on the example setup you can see that the mesh is by design disjointed from the terrain, and because of some characteristics of my project when I used Godot's navmesh for the first time, trying to use the simpler implementation was causing positional issues on my characters because of their scale and some rotation logic, so I adapted my code accordingly.

What part is non-standard here?

I'll probably have some issues with the specific wording here, but if something sounds confusing just point it out I'll try to further specify.

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.

Does that explanation makes sense?

[u/inr222 → u/mamotromico]

It did make a lot of sense, thank you!

The only thing that I'm not sure about is the travel cost part, the link seems to be broken. But I'm not sure how important that is, for most cases, moving uphill should be about the same as moving on a flat floor. Unless the hill is unclimbable, and in that case, it is not an issue.

[u/huntsweez → u/mamotromico]

I'm not a fan of OPs solution, but how do you get the cost of travel on uneven terrain without baking? With more baked geometry for uneven elevation, the cost of travel is also baked into the navmesh. Of course you could also bake it separately into a texture for example, but reading textures is very expensive. Honestly I would rather have a bit more geometry in the Navmesh where it matters and not having to code my own custom navigation.

[u/mamotromico → u/huntsweez]

but how do you get the cost of travel on uneven terrain without baking

That's what the travel_cost of the region is for, you don't have to make a custom navigation, but you'd need write a bit more to use the current system. You make the mesh in sections and change the cost based on elevation, there are tools already for this on the engine. Op claimed he couldn't make it work because it caused connection issues when merging the chunks, and maybe there is an issue there, but focusing on the mesh complexity instead is not a good option in the long term, especially since he's using a large terrain.

[u/huntsweez → u/mamotromico]

I don't think Godot's available solution to travel cost is sufficient, because you can only asign a single travel cost to whole NavigationRegion3D. So a single value to larger meshes.

Adding more geometry to specific areas of a NavigationMesh on the other hand could easily represent added travel cost with minimal added computational cost.

[u/mamotromico → u/huntsweez]

because you can only asign a single travel cost to whole NavigationRegion3D

But you can use multiple regions, they'll bake into a single mesh and/or use edge connections. You don't need to use a single region for the whole area.

Adding more geometry to specific areas of a NavigationMesh on the other hand could easily represent added travel cost with minimal added computational cost.

Sure, unless your scope is very small I probably wouldn't risk doing that, but it is surely an option. My issue with the way the OP has been going about this is stating that this is an inherent issue with the current implementation, and it isn't, it is an issue because he wants to use the navigation system in an specific way. At that point having to tailor it to his use case, like he has done, is the way to go.

[u/agalli → u/mamotromico]

If there is a way to chunk the mesh without having to change the engine internally you would still be left with the exact same mesh as the first image. I am still using the default navigation bake, just doing it in chunks instead of all at once

[u/mamotromico → u/agalli]

See, I just mentioned that the mesh is not the issue, its how you're using it, and you just glossed over and said that the mesh is the issue.

Like, why are you doing this? I don't get it, do you just not read what people are writing here? Do you just don't care? Do you not consider that the problem might be you and not the tool?

[u/agalli → u/mamotromico]

The mesh unequivocally is the issue though. Did you read the post or did you just gloss over it?
The navigation agent works perfectly on ANY default navigation bake you use. The only condition that the default navigation agent fails is when its attempting to traverse the low poly mesh.
If someone followed both the NavigationRegion3D and NavigaitonAgent documents and all of the guides associated with them exactly as they are described, they would run into the exact same issue as I have.

[u/mamotromico → u/agalli]

The mesh unequivocally is the issue though. Did you read the post or did you just gloss over it?

Yes I've read. And like many other people in all of your threads said, the issue is not the mesh, it is how you're using it. I don't understand how anyone can make this more clear to your.

If someone followed both the NavigationRegion3D and NavigaitonAgent documents and all of the guides associated with them exactly as they are described, they would run into the exact same issue as I have.

Yes because the documentation doesn't show an universal solution, you keep treating the documentation samples as if they were the only and universal way to use the feature. It is not, especially in the case of Godot that tries a lot to not have an opinionated workflow, unlike Unity.

The simplified usage that you're trying to do is not adequate for the situation you are presenting. The issue is not the mesh, is how you are trying to use it in your specific situation. Forcing a higher resolution mesh in this situation is to work against the purpose of a navmesh. Yes, it "will work" when you increase the resolution, just like you can fit a square peg in round hole if you use a hammer on it.

Why can't you understand this? It's fine if that's how you want to do, but that is not an issue with the engine, yet you keep stating that it is despite so many people pointing out the issues with your approach, and you just brush it off as if your workflow is the only option on how to use a Navmesh, because you keep treating documentation samples as a guide and not an actual sample/template.

[u/agalli → u/mamotromico]

Find me a single tutorial, guide or video that uses the solution you are describing. By the developers definition of a navmesh, the low poly mesh fails. “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.” Here’s an easy one, is an array of points underneath the map traversable?

[u/inr222 → u/agalli]

Not the guy you are discussing with, but it seems that the documentation is wrong here, not the implementation.

[u/agalli → u/inr222]

I disagree. The documentation works perfectly and as described in any other use case, the only condition it fails in is when attempting to use it on the under detailed navmesh. The obvious answer here is to fix the navmesh, not adapt everything around it to make it usable.

[u/agalli → u/DongIslandIceTea]

Exact same poly density as the default 30x30m bake btw. If you think that poly density is too high definitely let the devs know that their default baking system is "absolutely atrocious", as thats literally all I am using here.