[BUG] Navmesh cuts sometimes create multiple areas

[dnomn8r]

First, here is the basic graph, with some ramps, and a navmesh cut component in the middle(in green). The debugger is set to show the different navmesh areas. So far so good.

Now, if we move the navmesh cut even a little bit upwards (0.06), we get this graph.

As you can see, we now have two separate areas (the pink and red), and this means that we can no longer find paths from one area to the other. As far as I can tell, there should be no reason this is happening, since the two areas are still adjacent, and still share edges.

Even stranger, if I remove the object which creates the green area, we get this.

With this object removed, the navmesh cut works normally, and can cut the mesh just fine(on the ramp).

No idea what is going on. I’ve tried playing with various settings, and none of them seem to fix the issue.

[dnomn8r]

Hmm, we still have this happening, and can’t figure out why. Any thoughts?

[aron_granberg]

Hi

I’m working on a new release which includes a significant rewrite of the navmesh cutting system.
It should be faster, allocate less garbage, and most importantly, be much more robust.

I hope I can release it within a week.

[HM-Hugo-L]

• A* version: [5.3.3] (Purchased A* Pro)
• Unity version: 2022.3.57f1

Apparently the issue still exists. We’ve been using 4.3.92 for a while and had the issue before when navmesh cuts were placed on slopes but weren’t tall enough, so the navmesh would go above or below, and this typically caused a seam to form (and a new area if that was the last connection)

Making the area bigger to ensure it only crossed the navmesh from the sides removed the issue in our case, but after upgrading to 5.3.3, the problem is back, and is much more finicky.

Here are a couple recordings of the issue, it is both unpredictable and consistent. If it starts happening at a given place with navmesh cuts at a certain size, then it will basically always happen, persisting through rescanning the graphs and stopping and starting playmode again.

navmesh cut splitting area

navmesh cut semi consistent seams

I’m not sure what to do, every config I tried would always end up causing an area to randomly split, sometimes it affects every graph, sometimes only a few. And using tags still doesn’t appear to work as long as at least one navmesh cut is used.

Here’s the graph setup, the other “medium” ones are similar though with different character height and step, “large” ones also have a bigger character radius.
When a “medium” graph is cut, typically all others are as well, though I believe it once cut only one of the medium.

The issue seems to appear when a specific vertex gets removed by the cut operation, but apart from that can’t find another pattern. it can happen on the border between two tiles as well as in the middle of one, regardless of whether there are other surrounding navmesh cut or not.

Detail that maybe could have something to do, both the ramps and floor panels use the RecastNavmeshModifier to force the navmesh to actually be on the surface, without it had a tendency to simplify so much the paths or GetNearest node queries were unusable, maybe it causes some weird interaction with the cuts?

[tealtxgr]

@HM-Hugo-L

Detail that maybe could have something to do, both the ramps and floor panels use the RecastNavmeshModifier to force the navmesh to actually be on the surface, without it had a tendency to simplify so much the paths or GetNearest node queries were unusable, maybe it causes some weird interaction with the cuts?

If you take this component out, how does it behave then? Outside of being not a good fit for your project, I’m curious if this could indeed be related?

[HM-Hugo-L]

@tealtxgr

If you take this component out, how does it behave then? Outside of being not a good fit for your project, I’m curious if this could indeed be related?

Just tested, seems to not make a difference, quickly found two spots with a seam.
I also realized the floors did not have it to begin with, my bad.

I’m not sure if it was improved or not but the navmesh isn’t as far from the actual surface as I thought it’d be in a lot of cases. Though if the tile contains a straight line from one edge to the opposite, it still will simplify into a straight surface, dodging all the navmesh cuts.

Whatever the issue comes from seems to have something to do with the ramps as I can’t observe the issue anywhere else, I’ll continue experimenting see if I can isolate a culprit.

[HM-Hugo-L]

Hm well I’ve removed everything in the prefab apart from the collider, the navmesh cuts and a script to trigger a graph update, and it still happens all the same.
Tried changing the collider from a mesh collider to a box collider rotated to match the previous, observed maybe slightly more seams but overall it’s the same.
Tried making it thicker, then larger with about a meter of overlap, neither made a difference.
Tried smaller with some small gap (~0.2m) between the panels and again no difference.

At this point I’m fairly confident the issue doesn’t come from some faulty setup in the ramp prefab.
Would it help if I manage to recreate the issue in an empty project?

[tealtxgr]

@HM-Hugo-L

Would it help if I manage to recreate the issue in an empty project?

This is what I was gonna suggest actually yeah- or even just the ramp itself. An example project may be better to cut down on possible differences in the set up though.

[aron_granberg]

Hi

This is a known issue that is sadly pretty hard to combat.

It happens when there are two adjacent triangles, and a navmesh cut that spans both of them when seen from above, but only one is actually within the bounding box of the navmesh cut on the Y axis.
For most games, this is never an issue, but it looks like your test scene really causes them a lot.

As a workaround, I would recommend making the navmesh cuts tall enough that they always cut both triangles.

[HeroSyndromeTheGame]

Hi, Hugo and I are working on this.

We tried setting the height of the navmesh cut to be extremely large, but we still see this issue. It does seem to help some of the time, but it still doesn’t remove all of them.

In fact, one of the clips Hugo posted above uses super tall cuts.

[aron_granberg]

Hi

Do you think you could send me a unitypackage with a scene that demostrates the issue?
Ideally a few different examples, if you’ve got them.

[HM-Hugo-L]

Hi,

I’ll try to get a minimal setup that triggers the issue!

[HM-Hugo-L]

Here’s an empty project with some simple code to move the camera and place objects.
Imported a couple meshes we use in the project and the exact setup we have for the cuts.
The AstarPath settings also match the ones we have in the main project, in case it matters.

Navmesh Cut creates seams.zip

EDIT: Removed the 120 MB astar example scenes folder

To my relief, the issue was triggered fairly easily, though it seemed a bit less prone to appear, perhaps because the terrain here is centered around 0,0,0, whereas in the project the test scene is around 1000,300,500?

I’ve added a few messages based on a couple differences in the “perceived experience” of the issue.

Here’s what it looks like in play mode for me in case the repro is machine dependent:

Found a bonus problem I never observed before, occasionally gaps seem to appear!
Placing/removing stuff in the same tile can affect it, sometimes the gap stays even after removing the last object:

[aron_granberg]

Hi

Thanks!
I’ve managed to fix most of these now. Some remain and are very tricky, but I’ll try.