The question is answered, right answer was accepted
How can I enforce off mesh link planning to actually use the link start and end point?
We are currently using Unity's built in navigation system for nav mesh generation and path planning, but we are using our own locomotion system for following the paths returned. We are currently however encountering problems when using off mesh links. The way we expected them to work is if there is path over off mesh links that is shorter or the only one possible due to disjoint navigable regions it will plan over the off mesh link and add waypoints for the link start and end to the path. What we found however is that the path returned does not necessarily use the start and end point.
Below you can see an image with two disjoint navigable regions and two visualized paths returned by Unity's navigation system. Please note that if the off mesh link depicted is removed or disabled no path can be planned between the two path start and end points. A path planned from the start and end of the green line is fine and traverses over the off mesh link, with waypoints on the link start and end. For a path planned between the red line start and end point however we get a path as the red line is depicted and does not traverse over the off mesh link start and end point at all.
The region in which we can move over non-navigable terrain like that seems to increase as the distance between the two links increases. In our use case we want the off mesh link as depicted, and not just on the edge of the nav mesh.
Are we doing anything wrong? Or can we somehow force the nav mesh link to be used? We've already tried to set the link cost override to 0 or very low values.
Best regards,
does the bug also appear when you do the calculation from the right? I just read through the manual and it sounds like pretty solid when it comes to that. I'd do a simple test. simple agent, place him at the red line start and programmatically tell him to go to the red line end. what does he do?
Hi hexagonius, thank you for for answer. It made us double check everything and find a bug in our path following. The off-mesh link worked as expected and documented.
Follow this Question
Related Questions
Have players NavMeshAgent ignore Enemy NavMeshObstacle carving 0 Answers
=> How to Avoid NavMeshAgents Clumping Up Together?! <= 1 Answer
navmesh agent won't move on navmesh generated at runtime. 0 Answers
Navmesh, need an destroyable obstacle which will remove it's entity in terms of NavMeshPath 2 Answers
How do I generate a good navmesh for uneven procedurally generated terrain? 2 Answers