Navmesh dual-cutting at certain updates disconnects rest of the graph (makes it light brown)

Hi, I’ve been using the pro version for a few months now quite successfully, but this problem has really stumped me.
I have a staircase with a narrow recast navmesh path leading from downstairs to upstairs. Normally it works just as it should.

Now, I have objects that use dual navmesh cutting to have tagged areas for avoiding them, tables ect.
When I place such an object on this path and move it around to update the navemesh cutting, it dual-cuts the path as expected, but at certain updates also disconnects the path to the upper floor, making it light brown and unaccesible (the whole upper floor changes color). And in the next update, everything turns blue again.

I’ve pinpointed that this certain (buggy?) update happens only when the centre plane of the navmesh cutter has moved from below the path to above it, or vice versa. So, almost everytime the cutter’s centre plane moves through the path, it disconnects it for that update. EDIT: This doesn’t seem to be the case after all. Now it seems to happen at the top and bottom planes of the cutter. It’s a bit messy to determine because my objects rotate. There seems to be no rhyme or reason to it frankly.

What could cause this? Seems like a bug to me.

Hi

Yeah, that has sometimes happened due to floating point errors. I have done some workarounds for this in my dev version. If you want I can share a preview version with you.

Brilliant! This problem shows up quite often for me so that would be much appreciated!

I have sent you a PM. This update also includes a large number of other changes, as long as you did not use the rvo beta version previously, I think it should upgrade ok.

Thanks! But I can’t see the graph at all now due to a couple of shader errors:

Shader error in ‘Hidden/AstarPathfindingProject/Navmesh Outline’: Duplicate system value semantic definition: input semantic ‘SV_POSITION’ and input semantic ‘VPOS’ at line 37 (on d3d11)

Shader error in ‘Hidden/AstarPathfindingProject/Navmesh Outline’: Duplicate system value semantic definition: input semantic ‘SV_POSITION’ and input semantic ‘VPOS’ at line 72 (on d3d11)

Ah, right. That shader doesn’t work on Windows yet.
You might be able to revert it by opening the RetainedGizmos class and changing the DrawLine method to

Gizmos.color = col;
Gizmos.DrawLine(a, b);

And in the Hasher struct constructor add

hash = (ulong)Random.Range(0,10000);

Thanks, that got it working!
Now I just need to make my cutter objects work again so that I can test for the main issue.

Welp, I got everything up and running again, but the main problem still remains the same. And all the scripts should be up to date as far as I know.

Hm… That’s annoying. Do you happen to have a screenshot/video of it happening?

What changes did you have to make? Is there something that did not upgrade cleanly?

The only major thing that had changed was that the navmeshcut center’s y coordinate no longer moved the box up or down (a bug?), so I had to change it so that I move the transform’s y coordinate instead.

Here are a few screenshots where I’m using a simple navmeshcut with it’s default settings on a spot of path that illustrates the bug easily. I’m moving the box through the path and showing different angles. It seems that when the box is touching only a single line the bug occurs. I can make the bug happen on the stairs as well, but only if I check rotation and have the box rotated.

I hope the image shows fine.

Any progress? This issue seems kind of difficult to work around with my setup.

Hi

Would it be possible for you to share a test scene with me so I could replicate the bug?

Yeah, it was actually really easy to replicate it! All you need is a ramp it seems (the bug does not occur on level ground).
I’ll send a link to a simple test project in pm.

Ah… It’s that bug.
I actually encountered that in another game and have already written a fix for it. I don’t particularly like it though because it does slow down navmesh cutting a bit and has some non-intuitive behavior in edge cases (but when using a tiled recast graphs they pretty much never occur)… but… it solves the problem, so I guess I shouldn’t complain too much.
I could send you a version with this fix included.

That’s great! As long as it’s not too slow. But I don’t use too many cutters anyway, and tweaking is always possible. So send away and I’ll give it a try!

Got the fix? I’m sure you have your hands full.