Gaps at tile boundaries on recast result

General Recast graph
1
  • A* version: [enter version here]
  • Unity version: [enter version here]

We’re seeing visible Y-axis seams along tile borders — adjacent tiles retain different vertices on the shared edge, resulting in gaps where the navmesh doesn’t connect properly. This is most noticeable on stairs and slopes. Is there a known fix or post-process to stitch tile boundary vertices?

image
image660×374 56.8 KB

2

The reason I am insistent on this issue is that our game features a joystick control function, which usually results in a very short movement distance per frame. This presence of height differences at the boundaries of tiles with gaps means that the point obtained using GetNearest() may be snapped back to the origin or other points on the edge of the original triangle, causing our character to get stuck and unable to pass through the tile edges. Could you please provide any good solutions to this problem? Thank you very much!

3

Hey there, sorry for the late response! Could you provide either a sample project or full instructions to reproduce this? I’ll need to know what version of Astar/Unity as well.

4

Thank you for your reply! Unfortunately, we cannot share our scene files for certain reasons TT. We have managed to resolve the issue on our own by making two key changes:

  1. We added height error correction during contour simplification. Specifically, additional points are inserted if the contour line deviates too much from the simplified line on the Y-axis (previously only XZ coordinates were considered).
  2. After parallel generation of tile meshes and before connecting the tiles, we introduced a stitching process. For the connection between every pair of adjacent tiles, if the height difference between two edges is less than the walkable climb, points that exist on one edge but not the other are added to each edge. Heights are then aligned, and original triangles are split into two.

At the cost of increasing the total number of mesh triangles by less than 1/10 and raising scan time by approximately 1/8 (the stitching process is not yet parallelized, so there is significant room for optimization), we have obtained a gap-free mesh.

We are using A* version 4.2.19, and we are unsure whether similar changes have been made in your later updates. We hope this solution helps others who encounter similar issues! If you see any potential risks in our approach or have other suggestions, please feel free to let us know.

1 Like
5

Ahhh gotcha. Yeah your fix sounds fine to me- no notes on my end so long as it works! Thanks for letting us know what your personal solution was.