NavMesh.clampMovement: may get stuck at corners

[Glidias]

From the code implementation it's pretty obvious that this may happen, since it only considers 1 single edge ("the closest one") from start position, instead of a set of multiple border edges along the contour. Also, wouldn't there be a case where the "closest edge" from start position may not necessarily be the edge you are colliding against? With only one "closest edge" being tested, what about potentially other edges that might be collided against further along the swept movement's volume? For fast moving objects, this can be an issue. Also, by "closest edge", the back-facing edges in relation to the movement's direction might be picked, and thus deal no effect?

As above, looking down onto navmesh in first person view. Red arrow indicates direction of movement... Since slided position lies outside of T bounds of clamping "closest" edge (indicated in blue), attempt to check if still within navmesh resgion is done. Because it no longer lies within navmesh region, a force reset to start position is done in the current implementation. Rather than force-reset, consider using the T value along edge to get the respective connecting incident portal edge by getting the T vertex (for T > 1 and T < 0 respectively), and repeat process with new closest border edge on neighboring polygon (find: border edge of neighboring polygon's T complement vertex === T vertex on clamping edge) to test along the actual contour. (by complement vertex meaning match: a.prev.vertex matches with b.vertex or a.vertex matches with b.prev.vertex respectively.).

In the event new border edge along contour is back-facing in relation sliding movement direction (thus, that border-edge isn't actually the true exiting border edge), find the closest front-facing border edge to sliding movement direction on neighboring polygon instead. If there are no such exiting border edges for such a neighboring polygon, then use the closest portal edge front-facing to sliding direction to check for the next neighboring polygon in order to find the exiting border-edge.

[Mugen87]

Yes, this is a known limitation of the current implementation.

the back-facing edges in relation to the movement's direction might be picked, and thus deal no effect?

Border edges do not have twin or opponent edges. When you say back-facing edges, on what edges are you referring to?

[Glidias]

Refering to edges "back-facing" towards the forward movement's direction rather than facing against the forward movement direction. eg. The movement direction will never hit closest edge if the closest edge picked lies behind the mover.