So this are basicly 2 Navmeshes (Woods and M(ountain)Village) that I wanted to connect like stated here.
So I made another Navmesh “Conn_Woods-MVillage”, Conn stands for Connection in my case
This has its baking_aabb set to w: 120, h: 75, d:470, the rest is 0.
And the gizmo was just before the MVillage Navmesh, so that there is no pink line, which would be overlapping. Same for the Woods Navmesh.
The Baking AABB Offset was set to small values like 15 or 25, so that they would just overlap with the Offset and but not by the Baking AABB itself.
But no matter if I set the Baking AABB Offset or not, the Enemy behaves the same all the time like shown in this Video: Watch why | Streamable ( I could not upload a 60MB Video File, so sorry for the link).
So for this Video I set the Conn_Navmesh inside the other two, so that there is an overlap on both sides to every other Navmesh.
Performance wise (on my system) it did not change a thing.
So does anybody got an Idea why the Enemy is behaving like that ?
BTW: The Enemy is looking for the player node and just moves to that point, but as you can see, the enemy moves into the ‘next’ navmesh but not back to the woods navmesh. On the MVillage Navmesh it just works.
In fact I started with a NavLink, but the Link does not provide any movement, only the signal for ‘Link_reached’ and then I need to script what should happen.
I want to really see the NPC navigate the map and not just fade out of existence at one point of one navmesh (like stepping into a portal) and appear out of nowhere (another portal in the other navmesh), as this is what a NavLink AFAIK provide.
Don’t see the baking AABB but that does not look like your baking AABB was setup correctly, else there shouldn’t be any navmesh overlap visible to the left and right of your Conn_Woods-MVillage navmesh.
This does not work from the woods to the conn as the enemy cannot cross this left gap.
right side to the village:
coming in the next post, sorry !
When I place the enemy in the mountainvillage he will get to me near the woods.
Its wrong made by me since there should be no overlapping visible ?
But it only works when there are overlapps, strange…
I have the demo open, but it is not easy to adopt to, because everything is done in Code (I am fiddeling around in the Editor, for my visual reference basicly) and the navmeshes spawn only on runtime.
Rather then this I would like to create and bake and save them as .res-files, as my map is a bit bigger then the demo and I still need to wrap my head around all of this
Without edge connection margin enabled the navigation meshes can only merge when their edges perfectly overlap. This means only polygon combinations that look like this are valid:
You edges in both of those images are just randomly placed with seams or different angle, that can not merge correctly, only by luck.
If you use Godot 4.3 with baking AABB and border size you can bake the chunks with matching edges to the neighbor chunks.
You can do this in the editor without script as well it is just more fiddly because you need to make sure that both NavigationRegion3D and baking AABB + border size end up at a workable position.
It is easier if you try the setup on a small scene first and only if you understand how it works and how the geometry and parameters interact with each other go back to the unwieldy big Terrain3D mesh (that often has a lot of its own issues).
What I mean with Terrain3D mesh issues, look at the very thin and small edges in your images. Those commonly cause rasterization issues and are caused because Terrain3D adds overly detailed source geometry for the baking with polygons spanning over very large distances. The way to work around this is to bake smaller chunks as that makes many of those thin edges disappear.
Okay, I guess I understood it better now
Thank you for your explanation!
The Edge Connection is enabled in the project settings.
I thought the Navserver would handle that for me but then I will go and set up the AABB of the Navmeshes so that they should not enter any other navmesh or other AABB.
With this set up the correct way it would probably eliminate the one way problem.
The edge connection margin will only fix very small seam gaps or cases like #3 in my image where the edges align but do not match in length. It will make those edges connect at a very high performance cost so for very large geometry and worlds it should be disabled anyway.
In general you can not overlap navigation mesh surfaces. That is always a logical error even if it does not always show up as a more intrusive merge error with its own error msg.
but then I will go and set up the AABB of the Navmeshes so that they should not enter any other navmesh or other AABB.