Recast mesh on procedual hex tiles

Hey Aron,

In our prototype we are creating our maps procedurally by instantiating hex prefabs when the scene loads. We are using 19 tiles with a 50 meter radius. The tiles are mostly open ground with a few obstacles and roads on them.

We do an Astar Scan once everything is instantiated and have been measuring how long this will add to our level load times. With a cell size of 0.1 the scans are longer than 20 seconds, but with a cell size of 0.25 our scan times are much better and only about 2 seconds.

A cell size of 0.25 might be a little low though, especially for indoor spaces, and we would like to get our pathfinding load times as fast as possible.

We were wondering if you had any thoughts about how best to optimise our setup.

Should we explore caching a recast mesh for each hex, then stitch them together?

Do you have any tools that would help us do that?

Hi

You will have to figure out which cell size works best for your game.
Some general tips for recast graphs:

Make sure you have multithreading enabled in A* Inspector -> Settings -> Threads.
Rasterizing colliders only (not meshes) is usually faster than rasterizing meshes since colliders usually have fewer polygons.

Stiching meshes together like that is unfortunately not supported. Especially not with complicated shapes like hexagons. Doing that would be very tricky I’m afraid.

Keep in mind that you can also use an asynchronous scan (the AstarPath.active.ScanAsync coroutine) which might enable you to hide the loading time from the user slightly. This depends on how your game works though.

Thanks for the notes Aron! I’ll try and post back with how everting works out.

1 Like

Do the threads in settings speed up the nav mesh generation, or just the pathfinding once its done. We don’t seem to get much improvement.

Ah. Nevermind. I forgot that the recast graph automatically uses a lot of threads regardless of that setting.
They used to share settings, but I separated them some time ago.