I’m currently working on a game with isometric perspective. Gameplay takes part on a “plateau-style” Unity standard terrain. Here is a screenshot so you get the idea:
Screenshot
NPCs use navmeshes to navigate the terrain and can usually navigate up and down these plateaus on designated ramps without issues. But sometimes they walk right into a cliff / wall and get stuck there. Here for example the character is supposed to walk up to the target on a ramp a bit further away, but will instead walk right in the wall in front of them:
Upon investigating this, I found that the navigation path seems to “skip across” the cliff in the navmesh. You can see in the navigation debug info that the path includes some strange orange gizmo with a dashed line until the target. (Second screenshot was taken from under the terrain so you can see the orange dashed line gizmo better.)
It almost seems like the pathfinding process goes like “let’s just skip that part and go right to the target”.
When I deliberately block this area by placing an obstacle, the navmeshagent will take a different path, but I can’t tell where these “shortcuts” will occur until they do, so I can’t just edit my terrain in one place and be good, since this behaviour might show up on 100s of other places I don’t know about yet.
Does anyone know a) what that orange dashed line gizmo means in the navigation debug information and b) how I can prevent this from happening?
Unity version is 5.6.0p4 and I’m using the Navmesh Component workflow for baking the navmesh. I’m thankful for any input on this!
Without looking closer my guess is that it could be a navmesh link. Your setup could be that it thinks the player can jump that high. I believe there is an option to auto generate these.
Thanks for the reply! I also suspected off mesh links at first, but as far as I know the navmesh component workflow does not generate those automatically anymore and only supports manually placed links. At least that is what is written in the FAQ section for the navmesh component on Github.
I tried to place a manual link up the cliff. The NavMeshAgent recognized it for pathfinding, but did not display the orange dashed line Gizmo in the debug info (wireframe view for better readability):
However, I noticed something interesting while testing this. The new path with the manual link generated one of the problematic skips a bit further on across a regular obstacle:
When the NavmeshAgent came close to the obstacle, the orange dashed line gizmo disappeared and the path was recalculated. The NavmeshAgent then arrived at the final target as intended. So it seems to me that the orange dashed line could be something else entirely then, maybe some kind of optimization where only a part of the path is calculated? I think I need more testing to circle this in further.
After a painfully long investigation I came to the conclusion that the orange dashed line gizmo is not created by a bug or some sort of OffMeshLink, but it is indeed a regular mechanism when the NavMeshAgent has to deal with complex navigational tasks.
I created a new project for reproduction of the issue, took the same terrain height map and created a “minimal” capsule game object controlled by a NavMeshAgent to make sure my code / my actual project does not create the problem. It turns out that as soon as the navigational task becomes “too complicated” / “too long” the path will only be calculated partially, and as soon as the NavMeshAgent comes closer to the end of the partial path, it is calculated further. The “orange dashed line gizmo” can be understood as “I have not figured out that part of the path yet”.
With my test case from which I took my screenshots off for the original post, there is the additional problem that the agent apparently can’t find the path anymore after it hits the wall because the solution is beyond his maximal range for path querying:
I painted the correct path in the screenshot above in purple, apparently the correct solution is just outside the path querying range so the agent never finds it. So this problem seems to be “by design” due to the partial pathfinding rather than being a bug.
I think I can work around this issue in my game by simply avoiding these kind of complicated navigational tasks by making some changes in the NPC behaviors. If that is not enough I could still look into alternative navigation systems from the asset store.
Very interesting. Seems like that should be up to us to decide.
Did you find any reference of this any where?
I guess you are just setting the agents destination.
Did you trying the calculate path function to see if it gives any other results?
Or seeing if the path status is partial?
Unfortunately not, the Unity navigation documentation does not mention this partial pathfinding behavior & does not go into explaining the navigation debug view. So the stuff I wrote is just me assuming how things work after I investigated how the agent acts in my test project.
I originally used set destination, but tried calculate path & assigning it to the NavMeshAgent as well, same result unfortunately. The path status is “partial” for the paths that show the orange dashed line gizmo.
Unfortunately not, I’m still working around this problem by avoiding longer navigation paths from the gameplay side.
When I noticed this problem I was working on some “wandering traffic NPCs” so NPCs that spawn on roads and will follow those roads etc. Originally I only had those traffic spawning points set up at intersections only, now I added additional points on the roads inbetween so that the NavmeshAgent does not run into calculating complex routes.
In other places I always try to check if the path is valid, and if not I come up with alternative “backup” behaviours for the NPCs.
Same issue here - still present in 2020. Please just give us a slider unity… For now I’ll have to create intermediate navigation goals for longer paths.
For everyone struggling with this problem: At least in my case, this behavior was caused by the NavMesh agents stopping distance being set to 0. When setting a more reasonable stopping distance, the parts get generated as expected.
According to the Unity Docs small stopping distances encourage some unexpected AI behavior. I would have expected, that the stopping distance only affects when the agent recognizes that it has reached its goal, but it seems to affect the path calculation quite a lot which results in very complicated paths.
Maybe with a stopping distance of 0 the path gets infinitely complicated as the destination must lay exactly on a vertex of the NavMesh, which, depending on the resolution, will most likely never happen.
The downside is (to my knowledge, perhaps I am mistaken) .SetDestination runs async, while .CalculatePath does not. This could potentially be a lot more expensive if a lot of agents are running this at the same time.
