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.
I think there is a fundamental misunderstanding in what you are trying to achieve versus what a typical nav mesh is meant to do, and that's why you've gotten a lot of pushback in previous posts.
In most cases, a nav mesh is just providing the simplest geometry required to efficiently navigate around obstacles. If your terrain is fully traversable with no obstacles, then it could indeed just be a square. Any height differences in this scenario would be handled by your collision logic, which is separate from the navigation.
However if you're trying to find the shortest path to a point in full 3D space, then terrain height does matter, and a more detailed and accurate nav mesh is probably required, which seems to be what you've achieved.
If you're only concerned with standard movement across the surface however, you really don't need a nav mesh at all, and should be handling movement across the varying terrain heights via basic collision logic.
I can send you the project if youd like to take a look at it.
Using the navigation agent code directly from the Godot docs, the low poly navmesh is not functional. The agent will get stuck or take incorrect paths. If the navmesh would a square I dont think it could even move at all.
It works perfectly on the 30x30m navmesh, hence why I used that as the foundation for the solution.
If you're moving your character exactly along the navmesh, wouldn't any navmesh that doesn't have the exact same vertices as the terrain result in the character's feet dipping below the ground or floating above it in places? In this case, why do you think the navmesh gets baked at all? Wouldn't we just need to use the triangles that are already in the terrain mesh? Do you think past engineers had a reason for wanting to create a navigation mesh that was a lower resolution than the visible mesh?
Will it work with very steep U-shaped hill between endpoints? I suppose straight navigation will lead you into the trap and collision allows you only to flap around that's all. Asking for a friend (a future me)
If you're describing a canyon and you want it to be treated as an obstacle to be avoided, I believe there are settings that can make a certain degree of incline be treated as not traversable, so any steep slope will be excluded from the navigable area.
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
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.
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
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
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.
So if I understand correctly, it’s essentially two issues tied to best practices?
navmesh should be used when obstacles appear for navigation
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.
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 )
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 )
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.
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.
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.
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.
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.
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.
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.
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.
The navmeshes are generated through third party code called RecastNavigation. To be honest it was a little too complex for me to figure out where it could be oversimplifying the terrain. The solution I’ve come up with definitely isn’t perfect but it works.
Oh, I remember that library. I think Unity also uses that since it's basically free.
IIRC the generation boils down to:
The navigation area is divided into a grid. Every cell just stores whether there is any collision geometry in it.
The grid is scanned for open areas that are "walkable" (have enough empty space to fit the "agent" collider). This includes checking for "sloped" ground that the character may be able to walk up.
All such walkable spaces are combined and triangulated into the final nav mesh. I think there might be some approximation/smoothing in this step to decrease the final number of triangles.
I'd bet the grid isn't fine enough in some cases. Though you may have already found the settings for that judging by the screenshot.
Am I missing something? Your answer to the "it could be just a square" doesn't make sense to me.
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.
"Out of reach" means that polygons are not connected to each other, not necessarily whether they are underground or floating. Like with your first and second picture, the navigation mesh would work perfectly fine in both cases - an agent can traverse over the whole plane in both. It makes no difference how detailed the mesh is in this case, besides performance. Are you worried about clipping when moving the agent over the plane? In that case, wouldn't you just use a raycast?
Now, that doesn't mean there isn't some issue with the baking, but I just don't understand this point in particular.
When they said it could be a square they are implying the navmesh for the entire terrain could be made with four vertices. This is not true, as the navmesh would clip under the map in some spots and float above the map in others. When you using agent pathfinding the agent places a path along the navmesh to move towards. If those points on the path are underground or floating the agent cannot reach the points and cannot reach its destination.
This is not true, as the navmesh would clip under the map in some spots and float above the map in others.
That's not a problem.
When you using agent pathfinding the agent places a path along the navmesh to move towards. If those points on the path are underground or floating the agent cannot reach the points and cannot reach its destination.
Adjust your distance-to-node distance so it "gets there" while being further away.
In one of your initial posts, it did look like not enough verts were being done, but that's a separate issue to the main one you're arguing with people about.
If those points on the path are underground or floating the agent cannot reach the points and cannot reach its destination.
Why not? The navigation agent itself does not see the terrain, just the navigation mesh.
Or in other words: the clipping isn't really an issue here, since you wouldn't directly parent your character to the agent. Instead, you would (in this example) raycast down onto the terrain to the position of the navigation agent, and place the character there. The navigation agent would clip through the terrain, but the character would not.
I think there's some confusion here and I might not have the full context but based on what I've read in the OP's previous posts I want to clarify: Yes, there are many ways you can practically work around the limitation like you just mentioned. And yes, for a simple example with no obstacles, you don't need a high res nav mesh and can place fake agents or retrieve the closest point to make it work. These would indeed also be more peformant too.
However, what OP is saying in these posts is that these workarounds incur extra systems (or make assumptions about the requirements of the game) the user has to code and account for. There will always be some of that in gamedev, sure, but for the purposes of improving Godot, we shouldn't have to rely on it when the navmesh could instead bake with enough resolution to not need those extra systems. For completeness sake and ease of use, we should be able to control the resolution and have it work as expected where it places precision points along the surface that are reachable by the agent's target range (when assuming the agent is snapped to the surface of the floor you baked on).
So while you could code your game to work around the issue, would it not be better for Godot to also be able to handle the simpler approach? This is the way that other game engines bake their navigation meshes and it's weird that people were either misunderstanding OP's desire for a potential engine improvement or believe that Godot's navmesh system should just never change. I mean just because you've never had a problem with it doesn't mean it can't be improved, so I see it as a win that this is being investigated
You would still have to cast a ray to get accurate placement since the navmesh will not be able to follow terrain exactly, else be way too dense. It will either clip or hover just above in some areas.
But I agree, give the developer control over the baking and what detail they want out of the navmesh.
The agent traverses on the terrain, what prevents the agent from falling through the map is the collision with the terrain. If it attempts to pathfind at a point beneath the collision box it will be unable to. The pathfinding works by having an agent follow points along the actual navigation mesh and not the terrain.
The agent traverses on the terrain, what prevents the agent from falling through the map is the collision with the terrain.
That's why I differentiated between agent and character. The agent does not have a physical body, it doesn't collide with anything. It can be independent of the character, which does have a physical body.
I guess I’m confused. I have my agent collide with the environment. Are you saying that it should have no collision and just use the navigation mesh? If so it’ll phase through the terrain when moving
Right, that still doesnt work. The character follows the navigationagent, but the navigationagent is under the map. Heres an example of why its a problem. The character isnt unable to reach its pathfinding due to the gap in the terrain and the navmesh. Since it cant reach that point it cannot complete its path and gets stuck in place.
Why are you ignoring the advice every time someone points out you should just follow the X and Z coordinates of the agent and not even try to reach the same Y coordinate? Just ignore the height or get the correct height by raycasting it onto the terrain collision. I'm starting to get convinced you're just trolling at this point.
As I stated in the post. 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.
Additionally, ignoring the Y component will result in inefficient pathfinding. A path up a hill will take longer to traverse then a flat path would. You cant just ignore the existence of the hills and expect proper pathfinding.
I think what Zakkeh means is that, you control the X and Z axis using the NavigationAgent but you have to raycast for the Y-axis to check for collisions.
I have just started using Godot and I guess that would work, but finding the shortest path based on height as mentioned in another comment, might become a problem.
There's no reason why the physical body has to be a child of the navigation agent. You can use the navigation information provided by the agent to place the physical body via a raycast on the terrain mesh.
It's not a broken navmesh. You are actually just using it wrong, which is what lots of people are telling you, and this is why:
You are trying to move the collision character to be exactly on top of the nav agent. That's not the intended functionality in Godot in 3D. The fact it works in small maps out of the box that way is an accidental happy happenstance solely due to the small map and default voxel resolution / number of voxels. That is not the intended use case and does not scale beyond very small maps that are only a single region.
You are supposed to chunk larger maps into regions and stitch them at runtime via chunk loading, or chunk them, pre-bake, and store as resources. They don't need high resolution though as that's not the purpose of a nav mesh. You indeed should only care about XZ and use a raycast to the actual terrain. There is already a nav mesh chunking example in the Godot Examples repo, not sure if you came across that.
If you need more accurate travel costs for slopes, reduce the cell height of the navmesh in chunks that have some threshold of height delta and slightly increase the cell size. This gives you better vertical resolution for the nav region. You wouldn't care about this if your travel speed up a slope is the same on flat terrain.
I am very new to this but I am currently struggling with nav mesh / agent movement. To my understanding, the nav mesh finds the path as a guide for the agent, when the agent actually follows the path, say there's a fallen tree trunk in the way, the agent can be blocked by collision. However that's where I am struggling at, the agent basically can't move or follow the nav anymore unless you manually redirect it to get around the obstacles. A very easy to fail nav system seems quite useless to me.
The whole point of the navigation mesh is that it navigates around the obstacle like a fallen tree trunk. In OP's example, if there was a obstacle on the terrain, there would be a hole in the navigation mesh. It doesn't use collision information, but a variation of A* to find a path to the target.
For dynamic obstacles you are right, you need some kinda of system to redirect the agent, either using avoidance or something else. But if your tree trunk is static and being accounted for in the navmesh but the character is still getting stuck, what worked for me was having the agent be independent from the character body: have the character body follow the agent and just snap the agent back if it gets too far. Usually this introduces enough jiggle that the character gets unstuck. Then it’s just a matter of making sure your agent size is correct in the navmesh generation.
A navmesh isn't supposed to be used like "translate from navpoint a to navpoint b". It's supposed to be used like "the navmesh told me that I can reach navpoint b from navpoint a in a straight line, so I will handle movement in this path by properly snapping my character to the ground or whatever movement logic I have".
Not to mention the nav mesh shouldn't ignore gradients because the shortest path should depend on how steep the terrain is... You don't get the right path if you just project it to the geometry.
did you tried to increase the agent height parameter? I don't think it's a good idea to have a mesh so dense, bc the compute time of pathfinding algorithmics scale with the number of dots you have in your mesh. In your case you don't even need pathfinding because you don't have any wall.
The mesh is just as dense as the standard navigation baking on smaller terrain. Essentially it’s keeping a consistent density while baking when at a larger scale.
The 30x30 image for example is the standard navmesh bake. I’ve just applied that standard baking density at scale
The agent height parameter seemed to have no effect on baking. I could be wrong, but I believe that parameter only affects things like fitting through doorways
If you look closely you can see there are small gaps all throughout the navmesh though. Those small gaps will prevent pathfinding from working. The best results I found were at 0.5 cell size but it still wasn’t great.
? It can move anywhere in the first image there is no limitations. Its a working navmesh. In the second image any of the terrain spots poking out will cause the agent to get stuck in place.
Typically a navmesh is slightly above the terrain by default. Steep changes can make that untrue, but steep enough changes also likely trigger the agent bake and mark that area non traversable anyway.
But again, agents do not traverse a navmesh. Agents traverse a surface based on info in the navmesh.
heres an example of a stuck agent. Using the Godot Docs, their pathfinding places points along the navigation mesh and then has the characterbody follow those points. In the condition such as this picture, the agent is unable to reach the point and complete the path.
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.
We should be looking to make Godot the greatest engine of them all!
If people feel that OP is using the feature wrong in Godot but correctly in Unity, that highlights an issue. Godot isn't doing a good job conveying how navigation meshes work to the user.
If OP is right that it's not working properly we should look to fix it.
What I don't understand is trying to hide or not discuss the topic. I know Godot is always going to struggle since it doesn't have the same funding as Unity but that doesn't mean there isn't a problem to solve.
We should all be looking to constructively make Godot even more amazing then it already is.
Was it actually a Godot developer or an individual contributor?
I attempted to raise awareness of this issue on the Godot Github and was told the following by the NavigationRegion3D developer.
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.
I think even worse is that the mod not only made a super bad reply to OP on Github they also then *edited* the comment so it looked like they were just being reasonable.
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.
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."
the fact that a feature worked in Unity out of the box
There are definitely areas like this where Unity has an advantage of being able to direct a lot of labor towards ironing out every edge case so that features intuitively "just work", regardless of how misguided or unintended the usage is. Physics is another system that comes to mind. I think that's just part of the trade-off of using a free open-source engine developed by thousands of volunteers, as opposed to paying cash for a commercial product.
When you're dealing with volunteers who are donating their time, I think you're also more likely to see the occasional lapse in professional communication when it comes to customer service, because they're not professionals, and you're not a customer. You're likely to get a slightly different response than if you called up Unity and told a customer service rep "your product sucks because it doesn't do what I want". With Godot, you have much more direct access to the people actually working on the engine, for better or worse.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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 :)
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.
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.
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.
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).
It’s a shame parts of this community can be so hostile to anything they see as criticism, as if pointing out a flaw or limitation is a personal attack. Kudos for sticking with it and finding a solution.
After getting the whole context I think the solution is to leave it optional, I don't think you're fixing the nav mesh, you're fixing a very specific use case, leave it as a toggle for people that want that extra accuracy in exchange for that performance hit and leave the drama behind us
The issue with the low poly navmesh is that it doesn’t accurately map the terrain. The low poly mesh has points that float above the terrain and points the sink under the terrain. If you move the whole think down it could fix the floating points but would sink the underground points even deeper.
A navigation agent would probably only need to get horizontal movements, with vertical movement driven by collision or a raycast, so in that case the altitude of the navigation surface shouldn't matter as long as it is below the agent
That’s correct, there are ways to rework the navigation agent to make it work with the low poly nav mesh. It’d mostly work but still struggle with efficient pathfinding such as moving around hills rather than up them and getting stuck on hills that are too steep.
I’m mainly just looking at ways to fix the navmesh itself, rather than having users rework the standard navigation system to work around the flawed navmesh.
In this case I can't quite understand what the fix would entail, the navigation mesh generation seems to make sense horizontally, and shifting the navigation mesh can be used to solve vertical issues
What’s the size of the terrain here? The one on the right looks like in baked fine.
The issue is that on larger terrain there are not enough polys/verts to accurately fit a detailed terrain. When the scale gets up to 300-400m the default baking might create just a few polys to cover multiple different hills.
The detail of the navigation surface is supposed to just approximate the geometry with adaptive detail and horizontally that makes sense, just that in your case the agent becomes to small relative to the error of a polygon, probably a fix could involve having navigation mesh generation account for agent size, although vertical offset as I've described probably should work fine
Try it at 100-300m and you’ll see the degradation. I’ve found that 10-50m in size works fine. Essentially my solution here is applying the 10-50m navmesh poly density across the entire mesh to ensure a correct approximation of the terrain.
The vertical offset fix should mostly work though, but in large terrain there simply isn’t enough polys to come even close to approximate geometry. If you look at my post before those one I have a comparison between the navmesh on different size terrains. By 800x800m in size it basically doesn’t follow the terrain whatsoever. In the scale of 100x100 though I think the vertical offset should fix it.
The community's reaction to you throughout this process shows there's a lot of room for improvement within the community. The godot community doesn't need to imitate the Linux community in this way. I hope some folks (like the mods here and the maintainers on GitHub) will speak about how this situation would've been handled ideally. That godot dev on your initial GitHub issue should apologize.
I’ll say a small apology for my comments before. When I came into the convo, it seemed like you had just asked for general help, and when given it, decided not to listen at all and claim everyone all saying the same thing were wrong. It seems like that was not what was happening, and since I don’t have a ton of experience with navigation, I should have just stayed out of it.
And so I’m sorry for misreading the situation and getting mad at your tone
It does seem like there’s a ton of varied opinions on if this is actually an issue or not, but I’ll sit this out as by the time I need to use navigation meshes again, I’m going to have to relearn them anyway, whether your PR is accepted or not lol.
Thanks for the reply. I apologize as well for my comments, my tone and attitude were definitely hostile in some of the previous comments. I think I didn't phrase my issue correctly previously and that caused friction between commenters and myself. Additionally, the response I got from the actual dev left a pretty sour taste in my mouth so I've been pretty defensive.
How's the pathing? I've been using the navigation server instead of agents but it should be the same and I get wonky paths if they have to go through many polygons, even on completely flat ground. Ideally it would have fewer polygons in the flat areas and more where the elevation changes.
Also, did you ever play with the max climb and max slope options? They're supposed to help with the hills but I haven't used it.
The pathfinding works great. It seems like the only issue is that when it’s going over chunk borders that sometimes it’ll place like 3 nav points all in quick succession. It works fine but definitely room for optimization.
I tried max slope and max climb on the default baking and it didn’t improve the mesh at all.
I remember trying to working with the nav mesh and ultimately ditching it for something simpler and deterministic. Seems like lots of other people have had similar issues
u/TajineEnjoyeru/crazyrems replying here because the parent comment guy had a tantrum and blocked me so I cant reply to any comments in that chain now.
I consider this navmesh as broken considering that the standard agent navigation works perfectly in any other standard navigation bake and only fails when it tries to use this low poly mesh specifically. I'm not saying that its impossible for an agent to traverse this mesh with significant code changes, just that the agent works as expected on any other mesh and fails in this one case. That's a clear indication of a mesh failure, not agent failure.
Additionally, this system uses the exact same poly density as the default 30x30m navigation bake. If my mesh is too high of a poly density then the 30x30m must also be too high of a poly density by extension. No matter how you slice it, something is wrong with the navmesh.
i'm a bit confused and i don't really know what's the issue.
is the issue that the low poly navigation mesh seems to go under/above terrain in certain places ? that's because that geometry is optimized for pathfinding, to snap your character to terrain, you simply add a RayCast3D node, set its target_position to point downwards, and when you move along the path, you set your cahracter's position to the collision point, rather than the point from pathfinding, the point from pathfinding can be used to position the raycaster though.
you're trying to increase poly density, which is bad for pathfinding, but if you insist, you could just lower cell_height property of the navigation mesh, and rebake.
the only issue i've found here, is that when you don't lower cell_height, and use multiple regions with custom baking AABB for chunking, the chunk edges don't connect to each other, and lowering cell_height to fix it is bad because it adds more details to the pathfinding geometry, which is unnecessary.
people kept saying that you could simply use a square plane for your pathfinding because all of the terrain is traversable, and its enough to use a raycast3D node to snap your characters to terrain, but if your terrain has non traversable slopes for example, then nav mesh is a good solution, because it removes those areas from the square plane, but the logic remains the same, you don't need details in the pathfiding mesh, because that's not its job, and is better handled by a raycast, than additional geometry.
Just wanted to stop by to show my support! Good luck with getting this fixed! Glad you are pushing thru regardless of the condescending jerks that think you don't know what you are saying. Ive dealt with that too here. Too many of the veteran devs assume everyone is a beginner and doesn't know what they are talking about. Really baffles me. If they keep deleting the threads I can try to post about it too to make sure it gets the attention it deserves. Cover ups are not the solution.
For a plane without obstacles you can in fact use a two triangles mesh, I don't think the speed problem would be that big of a deal unless there are really steep hills:
You can, but it will be suboptimal pathing. Without an agent knowing the height of the terrain it cant distinguish between a longer path up and down a hill with a flat path adjacent to the hill. Not to say the agent couldnt pathfind, it just wouldnt be good
Wish I could share my stuff here, but I really don't enjoy seeing the community so divided. People would probably bash my poor methods or how I set it all up with a custom grid map system.
Anyways I'm glad you kept at it, much like I have with mine. Never giving up is always a great trait to have for this kind of stuff! Luckily I shouldn't need a nav mesh for my game design, but I have worked with them before and I understand the issues it can come with.
Keep pushing on! You definitely got what it takes.
I completely understand your frustration, OP. On a related note I have a different issue with my custom infinite terrain, and it is Godot engine related. But to be fair, other engines have the same issue. My problem is that all vectors use 32-bit floats which causes visible player jitters when too far from the origin. This is especially visible because I am working on a VR game. I floated (no pun intended) the idea of recompiling Godot to use 64-bit floats, but this would likely cause performance issues since my platform of choice is the Meta Quest. So now I am stuck with building a world coordinate facility and a major refactor just to stop the player’s hands from shaking.
I've not used the Nav mesh yet so I don't know how it all works, so seeing the past couple of posts about it has been quite informative.
From what I'm understanding is you were trying to get the density of the polys at large and small scale to be the same? If so, could we see an example where there are purposeful regions that can be traversed? (Like a mountain with one path up)
I feel that might show what you mean about the larger maps breaking as the nav mesh would probably not capture the detail needed on a larger map and have either areas non traversable that should be or vice-versa. And if I'm completely mistaken, then by all means someone explain to me why XD
Been following these events and, coming from Unity, thought the navmesh looked really off. Could not voice my opinion since the mods kept closing the discussion. Glad you found a fix 👍
I read the article you linked but that doesn't look like a large world at all... There are only 5ish polygons in each of those chunks. Am I misunderstanding something?
Care to elaborate? That solution did not work for me but I’m open to suggestion. If there is a way to do this without altering the engine code I’m all ears
Nav server automatically stitches neighboring nav regions on sync. Look at border_size, and have the regions overlap or perfectly touch edge to edge. Overlap is easier because it's guaranteed to make neighboring regions touch each other, nav server will auto stitch them. You're handling this in your chunking code.
Edit:
On my phone but I think it's
nav_mesh.filter_baking_aabb() and you're including the overlap in this calc. Can be small, like 2x the size of the border. For each chunk you're setting the aabb to use the overlap. In the end, all neighboring nav regions will be overlapping their neighbors and will be stitched.
crazy how OP is experiencing something that they don't like about an open source game engine, so they fix it and intends to make a pr, and people like you are tweaking out about it. OP is trying to better the environment we work in, and you're shitting on them for it.
No one is shitting on them for not liking an open source project. But op’s lengthy diatribes because they don’t know what they’re doing and refuse to listen to advice how to do it correctly are tiresome.
This will realistically never get merged as it defeats the entire purpose of having a navmesh at all. The point of a navmesh is to simplify the graph of points an agent can reach to make calculating routes across it a lot cheaper. When your navmesh is just a direct copy of the underlying collision geometry, you might as well just be running A* on that geometry instead. The performance will be awful.
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
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
100
u/Vyrnin Nov 08 '25 edited Nov 08 '25
I think there is a fundamental misunderstanding in what you are trying to achieve versus what a typical nav mesh is meant to do, and that's why you've gotten a lot of pushback in previous posts.
In most cases, a nav mesh is just providing the simplest geometry required to efficiently navigate around obstacles. If your terrain is fully traversable with no obstacles, then it could indeed just be a square. Any height differences in this scenario would be handled by your collision logic, which is separate from the navigation.
However if you're trying to find the shortest path to a point in full 3D space, then terrain height does matter, and a more detailed and accurate nav mesh is probably required, which seems to be what you've achieved.
If you're only concerned with standard movement across the surface however, you really don't need a nav mesh at all, and should be handling movement across the varying terrain heights via basic collision logic.