NavMeshSurface data is incorrect when the Scene is loaded without disabling and re-enabling the NavMeshSurface GameObject

2021.3.X

Won't Fix

There are two options for avoiding this problem: 1. Use the overloaded function public static bool CalculatePath(Vector3 sourcePosition, Vector3 targetPosition, AI.NavMeshQueryFilter filter, AI.NavMeshPath path) in order to control precisely, with the filter parameter, for which agent type to run the query. In the case when multiple NavMeshes for the same desired agent type overlap, then their order in the system matters again. The function variant is described at the end of the scripting reference page https://docs.unity3d.com/ScriptReference/AI.NavMesh.CalculatePath.html . or 2. Make sure that the NavMeshes are always enabled in the same order, prior to doing the first calls to the generic CalculatePath(sourcePosition, targetPosition, areaMask, path). This is generally not the intended approach in scenes with overlapping NavMeshes because there is no control over which NavMesh is chosen by CalculatePath() for the start and end points. Please let us know if you can use any of these workarounds to implement the behaviors you expected. Here is a description of how the problem occurs. The scene in the provided project contains four overlapping NavMeshes, built in the same space for four different agent types. The NavMeshes are not all covering both the start and the target point of the wanted paths. The call to NavMesh.CalculatePath() from the provided script picks the first NavMesh that it can find at the desired ends. Internally, the NavMeshes are stored in the order in which they have been added to the system. When the scene is loaded, the gameobjects with NavMeshSurfaces get enabled in a different order than when their parent gameobject gets re-enabled. How the scene loads the objects is generally out of our control. It affects which NavMesh is found first at the points of interest, and thus it affects the outcome of the call to CalculatePath() in each of those situations. Two implementation details that can be relevant in this case are that: 1. CalculatePath() determines the NavMesh for the target point first; 2. Subsequently, the start point might wrongfully be found on another overlapping NavMesh (which leads to not finding a path that obviously exists).