So I have been working with Unity for a while and have long been unable to figure out a solution to this problem. We have are trying to use the Unity Navigation system but even when an solid object is set to not be walkable it will only cut the nav at the shell of the mesh, resulting in islands hidden inside the objects. This is true even using the basic 3d objects built into Unity. Is there any way to avoid this? I would like to avoid having to switch to a new navigation system just because of this one issue but it is a major deal-breaker.
yep a plague of recast. UT’s fixing it and with a bit of luck and nagging it’ll be in 5.6.
it’s not a deal breaker though, when you spawn, test that it reaches valid points on the navmesh.
The problem is the height of the Non-walkable Object can not be higher than the Agent Height.
If your agent height is 2, then your Object height cannot larger than 2, otherwise unity wont consider the volume of the object.
I have tested this with a box, first scale the box a bit larger to get a reasonable volume, then scale it on height(y), and you will see the problem occurs when the height go over the Agent Height.
I consider this a bug of unity because there is no reason to make a much taller non-walkable object walkalbe inside but the shorter one remains solid… How Ridiculous!
Perhaps adding NavmeshModifierVolume or NavmeshModifier to your obstacles and set it to unwalkable would be useful. Doesn’t suffer from navMeshes being built when too far within the obstacle’s collider edges. It would be nice if these could be based of a mesh though, currently just box and cylinder…
This is nagging a lot of users - we have plans to add a seed-point what will optionally cull polygons not connected to the seed point. Not coming any time soon - until then i second the modifier volume approach (if the shape fits).
This is sooooo annoying, sorry! My god it just seems like a really basic feature? Why can the nav mesh obstacles only be boxes or capsules? I have a bunch of rocks that are irregularly shaped and I’m getting nav mesh generating on the underlying terrain inside the rocks. Just infuriating.
It’s been a while already, over a year already. What’s the hold up?
Same issue here. Any news on this? The NavmeshModifierVolume workaround is tedious and time consuming. Thanks.
Temporary solution: bake mesh using colliders
Unity, been A full year pretty much, a response would be appreciated on this as it is still happening.
The solution is to switch industries to post production - then if you have bugs they’ll be falling over their feet to fix it for you
Would love this, any chance of it happening? Or maybe suggestion for us, as we are trying to make the process as automatic as possible due to small team size.
Still a major issue…
We have this issue also, we’d love to have this fixed!
I understand this issue correctly now, it’s just the navmesh doesn’t really have a volume to it so there will always be the same island inside further down. These areas can be easily checked: assuming your colliders are all convex (they really should be or your game is wasting performance), you can do a sphere overlap check at the destination navmesh. If it collides then you know that destination is inside geometry. This works with convex or primitive colliders because those colliders have volume so the sphere check will register true if inside
Hope that helps, this is no longer an issue for anyone and just poke me with @ if you need more advice, any readers.
The reason this happens is because navmeshes are technically 2D, so it’s “by design”. You need to make your code deal with it, but in reality, an agent will fail to path there and you would have no reason to tell them to go there, right?
The problem is that my AI have the functions of a free walk. It is implemented using the NavMesh.SamplePosition function, which defines these zones as accessible for walking. I found a solution to the problem, but I have to do a lot of manual work, closing these empty spaces.
Yep, don’t forget you can raycast the location beforehand (navmesh raycast is 2D and Physics raycast is 3D). Or simply path there and check if it only has a partial path (look at API for this), and can then easily reject it.
I have already done everything manually