FI tested on the C++ demo an it has the same issue

Found this similar issue on recast repo From what I understand it might be a side effect of how pathfinding computes traversal costs using mid-edge points on polygons.

One suggested solution is to do a direct raycast between the start and end point, but not sure if I can use this solution and keep using Agent/Crowds at the same time; in other words I need to override the path corridor that the agent need to take

For anyone encountering the same issue, I ended up with trying a direct raycast first, if success then I use agent.requestMoveVelocity otherwise I default to agent.requestMoveTarget. Downside is you have to manually stop the agent when it 'reaches' the target point. As mentionned in recast docs, raycast helps only with 2D checks, so the workaround is only for when the target point is on the same level.

I tried pathOptimizationRange (inc updateFlags) but didn't work. Likely because optimizePathVisibility only checks for the corner after next one, which is based on the already suboptimal path computed.

Another possible alternative is to use agent.corridor.setCorridor to manually override the agent path but the method is not exposed in the current build of recast-navigation-js. And we might need to do other calls to leave the agent in the correct state.

Another possible alternative is to use agent.corridor.setCorridor to manually override the agent path but the method is not exposed in the current build of recast-navigation-js. And we might need to do other calls to leave the agent in the correct state.

Exposing setCorridor shouldn't be difficult - I'm happy to find some time for that if it's going to be useful!

Hi @isaac-mason thanks for your reply. Actually I don't think it's necessary, there're other cases direct raycast can't solve (eg taking the longer detour to go around a wall). I remember reading somewhere on Mikko's blog that for scenes with big open spaces tiled meshes should be preferred, since solo ones tend to create large polygons next to small ones, for which A* doesn't perform well. I'm taking a look back at tiled meshes (had some issues with them in the past)

I remember reading somewhere on Mikko's blog that for scenes with big open spaces tiled meshes should be preferred, since solo ones tend to create large polygons next to small ones, for which A* doesn't perform well. I'm taking a look back at tiled meshes (had some issues with them in the past)

For sure, tiled navmeshes should at minimum greatly limit the severity of these issues.

Also, thanks again for submitting a fix for the tiled navmesh issues you ran into!