clampStep seems to teleport the position sometimes, instead of sliding, other times it slides when it should allow passage

[hamzakubba]

I made a repro codesandbox of the issue in action:
https://codesandbox.io/s/crazy-ully-9k98qs?file=/src/App.js
(you also change x to 7 at the top of the file to see the box correctly slide at first)

And in the other direction, sort of the opposite happens as well, where it gets stuck along the edge between polygons:
https://codesandbox.io/s/goofy-goodall-h27mny?file=/src/App.js

Thank you so much!

[hamzakubba]

More variations, in case it's helpful... these first 2 are the same as the first 2 examples, but I broke the 2 polygons down further into some triangles (with the same total shape):
https://codesandbox.io/s/amazing-waterfall-1q9jc7?file=/src/App.js
This time the problem is reversed, the box can't traverse down properly at first

Going up is also reversed in this version:
https://codesandbox.io/s/vigilant-tree-d9gs63?file=/src/App.js
This time the box warps at the "wall".

Final couple of variations, this time I combined everything into one big polygon, and clamping works perfectly here in both directions:
https://codesandbox.io/s/peaceful-hypatia-x8ibbt?file=/src/App.js
https://codesandbox.io/s/zealous-wildflower-uonvxv?file=/src/App.js

So I may actually use this as a workaround for now (one nav mesh for path finding and another for clamping)... hopefully that will work for a larger map Update: it does not scale as a workaround

[donmccurdy]

Unfortunately, this project (and Patrol.js before it) have always had some trouble with very long/narrow triangles. This didn't tend to be an issue when using Blender's built-in navmesh generator (Recast) but they've removed that feature and understandably custom meshes from other sources have a lot more variance.

If you have the option, one way to solve this is to retopology the mesh in Blender with quads or voxels, then export —-

before	after

This uses more triangles (the number can be adjusted) and they're more consistent in size. Usually the navmesh does not have a high polygon count compared to the base scene anyway.

I'd certainly like to fix the underlying issue, but I'm not sure to what extent it's a minor bug or something more subtle in the search algorithm.

[hamzakubba]

Thanks for the reply. I tried several variations of voxelized meshes. Unfortunately, I could only balance it to either have decent quality or decent performance, but not both simultaneously. It's possible that there's a way to get the best of both worlds (I got to a half-decent place at the end), but the iteration process is also slow since the result of voxelizing a 2d navmesh in blender is a 3d mesh, that then needs to be made 2d again. Even if I fix it for my test map, the process doesn't scale very well and seems very dependent on manual testing for flipped normals and so on.

My map is somewhat large, and I was hoping it could have lots of nooks and interesting features. It was already a few thousand faces. I was hoping to avoid needing to use multiple zones and all that to achieve reasonable perf. Anyway, I'll figure something out on my end, I will likely need to switch to a tile-based pathfinder like pathfinding.js or easystar.js -- my gameplay is 2d, and I already keep track of 2d tiles -- though I was really hoping to use this library since the paths it finds are more appealing than tile-based paths I've seen so far, even with long triangles I have on my nav mesh (I used the helper to visualize them). Clamping the player and AI agents along slopes is also much more appealing han having everything following an invisible square-ish grid. If clamping can be fixed without a massive perf hit, it would still be my preference to use this library over a tile-based one for pathfinding and clamping, but I appreciate that this has been a difficult challenge!

Anyway, thanks again for the workaround, it will likely work well for small to medium sized maps with manual cleanup, or for people not crazy enough to attempt 1+ pathfinding search per frame :)