I was going to change “maxZ = math.clamp(maxZ, cropZ, cropZ);” to “maxZ = math.clamp(maxZ, 0, cropZ);” locally but wanted to flag it here in case it’s a legit bug that can be resolved in a future update so I don’t need to keep making the change locally. I assume it is because it doesn’t make sense at the moment and just forces maxZ to equal cropZ.
I use onCollectMeshes with RecastMeshGatherer and add my own RecastMeshGatherer.GatheredMesh data during updates as I move the pathfinding bounds around my open world. Right now I don’t seem to have any issues with this except I do get lots of “Vertex has multiple shared edges. This should not happen. Navmesh must be corrupt. Trying to not make it worse.” errors from “if (multiSharedEdges > 0)” in CanRemoveVertex in VoxelMesh.cs.
I’ve just commented out that error for now because I haven’t been able to resolve it by changing the input data as yet. I haven’t been able to identify any reason the mesh data I’m adding would lead to that. It’s seemingly working fine though.
What had me looking at VoxelRasterization.cs was partially that and partially trying to resolve a crash I was having that I believe was a race condition on my end that I resolved. I just noticed the “maxZ = math.clamp(maxZ, cropZ, cropZ);” line while looking through that method. It’s unrelated to any issue I was having, I just saw it and thought it was wrong and was just wasting performance by always making the bounds be possibly larger than needed.
On the “onCollectMeshes → (multiSharedEdges > 0)” issue I’m having, when I have time I can try put together a small project reproducing it if you’re interested. Maybe it’s a bug on the astar side or it might be something on my side.
Sorry I didn’t see your reply. I could try to come up with a way to repro it in a simpler project, but I did resolve it on my end by making a change to VoxelMesh.cs. I don’t remember the tests I did to identify the issue anymore and resolve it, but I got AI to look at the git history and reproduce the error and fix in python with data I had. Its explanation:
"JobBuildMesh.Diagonal checks InCone(i, j) and edge intersections, but does not check InCone(j, i).
On captured Recast contours containing hole bridges, a candidate diagonal passed the first endpoint’s interior-cone test while failing the other endpoint’s. The triangulator consequently emitted a reversed triangle and duplicate directed edges.
The fix requires the diagonal to be inside the contour at both endpoints:
return InCone(i, j, n, verts, indices)
&& InCone(j, i, n, verts, indices)
&& Diagonalie(i, j, n, verts, indices);
Replaying two captured contours reproduced the original failures exactly. Adding the second check eliminated them while preserving triangle counts, boundaries, and area. Additional replay cases passed, and subsequent Unity testing showed no warnings or observed navigation problems."
Basically I added that second InCone() check with i and j flipped in the params in Diagonal() and that resolved the "“Duplicate triangle edges were found in the input mesh. These have been removed. Are you sure your mesh is suitable for being used as a navmesh directly?
This could be caused by the mesh’s normals not being consistent.” errors and I haven’t noticed any issues with the navmesh since.
Sweet, thanks for contributing that! I’ll let Aron know about this, and I’m glad to know this worked on your end! If this can be rolled into the asset itself he’s the one that’ll let you know and if not why not. Thanks a ton!