Navmesh Cutting

Navmeshes in the A* Pathfinding Project have been awesome when you have static worlds, but often very low-performing when any kind of dynamic updates are required.
The experimental version which has been released for a while (but now superseded by the beta version) improves that by enabling tiled recast graphs so that individual tiles can be recalculated.
This is however quite slow as well. It works, but it’s not something you want to do without player interaction, and definitely not several times per second.

So what I have been working on is to enable navmesh cutting. What navmesh cutting does is to take a valid navmesh (for example the one generated at start by a recast graph), punches holes in it to make room for dynamic obstacles (boolean operations), fixes it up a bit (fixing triangles not fulfilling the delaunay criteria) and then puts it back to be used for pathfinding. And it’s a lot quicker than recalculating a tile using recast.
The downside is of course that it only works for obstacles, not for something like moving bridges (or whatever) which must add new ground for the player to pathfind on. Luckily, you most often have these kinds of subtractive obstacles that are dynamic.

8 comments

Hi Aron I purchased a long time ago “Map magic” to generate an infinite desert with lots of randomly scattered debris and some buildings … Node AI and APex Path didn’t their work and i just wated my money …

I would like to know :
1 If it’s possible to calculate for spiders their way through an infinite map like “map magic” to chase and flee from protagonist …
2 If it’s possible to handle my flying drones with your AI to help them chase / flee from protagonist and even avoid pillars, rocks and floating rocks;

I wonder if this is what might get a project I’ve been working on to have a little better pathfinding.

I generate a map completely procedurally at runtime, but I haven’t found a package that offers run-time nav *mesh* generation. My maps don’t change during play, but getting that initial pathfind map up has been a real kicker. Right now I’m running off a hand-build A* + JPS algorithm (its still got a few bugs) but I’d really like a navmesh.

Amazing work! took me a while to figure out how to manually voxelize the world.
We already have a voxelize representation of our geometry that is more accurate then voxelizing the collision mesh. Using precomputed voxels means it only takes 33ms rather then 300-400ms to generate the recast gragh.

C#
No, not like that one. That recalculates the tiles, I only cut the tiles using boolean operations and fix them up. It is more limited, but faster. Recalculation of tiles is also possible in the system, but it is slower. Unfortunately C# is a bit too slow to make recalculation of tiles feasible in real time (it is not extermely slow though, just too slow for real time).