Looking back through this and the old forums it seems the way A* is heading with larger areas will be Tiled Recast, as in the experimental build (3.3.1.) Before diving into (and reverse engineering how to use) that, I wanted to check if it’s still “the plan” and under development, and if there’s any examples or other docs (however rough?)
For context, I’m working with Pro to evaluate if it’s a fit for our setup, which (in terms of terrain size) is:
Multiple, areas each 100km2 linked only by portal
Each area broken into 1,000m2 tiles (this can change if need be.)
Very low resolution terrain tile loads triggered by main camera movement as they "approach" the visible horizon (which is generally 3-10km away); being replaced with high resolution tiles before becoming adjacent to the camera's tile.
Terrain data is completely static (actually coming from externally drawn height maps,) objects upon the terrain not so much, e.g., new buildings over time. We could also generate static nav mesh tiles, but that doesn't seem to get over the problem of a "holistic" mesh to avoid linking issues.
To see where things are now (Pro 3.2.5.1) I took a medium complexity 1,000m2 tile and ran Recast on it, both the C# and C++ approaches took in the vicinity of 80-90 seconds to generate a mesh. This tells me we’d be looking at some form of background and incremental loading, though not necessarily generation, e.g., if we could load static, tiled meshes that worked well together.
I just recently purchased A* pro and am encountering this limitation as well. I definitely would like to know what he future is for recast since it seems to be the best option for my game, but the current graph build times are way too long.
My use case in particular is a base heightmap with some buildings pre-placed, then other ones placed when the scene starts (Start() event in Unity). At this point extra buildings, which are enterable, are procedurally generated with randomized interiors thus requiring for me to do a scan for the pathfinding graphs at this point in time. These buildings may also have multiple floors, which is one of the reasons I’m looking at recast navmeshes rather than grids or pre-created navmeshes (since things are procedurally generated).
It would be nice if we could at least scan a section of the graph only, such as for example, the area where a building/new object was placed. I expect this would speed up scan times greatly.
Rico’s addition is valid and probably something we’d be looking at too; I marked it as rejected only because Vanilla Forums insists every comment is actually an answer and incorrectly flags the question as answered/closed.
A bit of a snag I have encountered is that, for tiled recast graphs to work well, there are some changes which a I have needed to make to the core of the pathfinding system. This does unfortunately slow down normal pathfinding. I really want to merge the tiled recast into the master branch, but also I really don’t want to lower performance…
100km^2 is possible to handle. It will take some time to generate, but it is definitely possible.
When using the tiled recast graph, each tile can be independently updated. This is however quite hard on the GC and even though it can now run in a separate thread (not sure if that is in the latest experimental build though), it is something you don’t want to do too often in a game.
Loading tiles incrementally is also theoretically possible, but no code for it exists at the moment (would basically consist of dumping the vertex and triangle arrays into a file, it shouldn’t be too hard to add since all the basic infrastructure for it is already there).
There are no examples in the docs for using the tiled recast yet (well, except a video tutorial about the new RecastObj class, but that barely counts).
Thanks for the information. Sounds like you’re still heading that direction; good to know. The more I’ve thought about it, the more I think I’ll have to develop static navmesh generation as part of the pipeline outside of Unity—unlike Rico’s more dynamic scenario, the navigation for me static and known at build, the real problem is there’s just too damn much of it.
I’ll explore some possibilities here during this coming week. If there’s a way to stich neighboring navmesh graphs together that could allow the system to load grids as tiles when terrain is loaded. Or, if we could reload one master graph from a set of predefined navmesh graphs that all overlap (loading the one currently centered on the game’s focal point, reloading as the focal point moves around the area.)
Anyway, thanks for the response, much appreciated.