The async function looks like it limits the # of NavMesh.CalculatePath’s per update loop.
For me the pathfinding cost varies drastically based on distance and number of obstacles between source and destination. Limiting the # of pathfindings per Update loops might be an OK way of handling the problem but still gives 2 issues.
1: If the path is complex it could still cause FPS drop (unless the limit is set really really low for worst case scenario)
2: Close monsters would have periodic pathfinding causing jerky motion (unless smoothed out with additional code).
Not sure if there is a way to make an async function that varies the # of NavMesh.CalculatePath’s based on loading… but that would be more ideal than a fixed number of calculations.
@daxiongmao I’m not sure if I need to calculate the path every Update or not. But that’s currently the way I get the monster to “aim” at it’s target. If I recalculate every 100ms the monster jitter rotates as it only updates it’s aim every 100ms. I considered moving over to a different system if the monster is close… but my game has traps and obstacles an such that the monsters navigate around. So even if you are close to the monster I still want to pathfind around those. I’m not sure of any alternative to pathfinding every Update. Open to ideas.
In any case I LOD’d the NavMesh.CalculatePath rate and it seems to work well.
This NavMesh.CalculatePath cost is another thorn in the side of getting a smooth game. Getting smooth visual motion is already difficult (impossible?) with Unity due to Time.deltaTime variation issues.