Hi,
i’m just trying to generate graphs on unity terrain, but the results are wildly different depending on what type i use and even unusable in some cases.
Here’s the output of a grid graph:
which is mostly disconnected little squares that don’t really seem to respect slope limits and don’t interconnect properly. Connectivity between them can be improved by increasing the max climb, but this has the unwanted sideffect of overriding the slope limit.
And this is the output of the recast graph (tiled):
it’s more correct in respect to slope limit, but has cracks here and there which seem to affect node connectivity.
The non-tiled recast graph doesn’t have those cracks but is very imprecise in representing the actual terrain height, which i need because i want to use path movement without physics.
Can the precision (/subdivision?) be increased somehow or the cracks in the tiled variant be controlled?
And is there any checkbox i missed that makes the grid graph work correct on terrains?
max slope is only used to determine if the node is walkable or not. In your image it looks like all those nodes on the hillside are walkable. Two adjacent nodes will be connected if their y coordinate differs by less than max climb. The beta version (A* Pathfinding Project) has improved handling of this case and it takes the slope into account when calculating the nodes’ y coordinate difference. Usually it leads to much more intuitively correct behavior.
Those small cracks in the recast graph are actually fine. They look bad but the graph will be connected across them (in pretty much all cases). The reason they are there is because sometimes the border of a tile may be simplified in a slightly different way in the different tiles.
Usually I do not recommend movement without physics however. The graph’s y coordinate is usually not precise enough for that. The built-in movement scripts use a single raycast for positioning themselves on the ground which is pretty cheap.
Thanks for the fast answer.
I was intending to export and load the navmeshes on the server side where i’m trying to not depend on physics as i’d have to duplicate/create the whole level geometry, only for movement.
The confusion about the slope limit seems to be related to the way the recast graph generates the navmesh. I thought the slope in the screenshots above was not walkable until i decreased the cell size significantly to a point where the recast graph also generated a mesh there (with the unwanted sideeffect of also creating very small islands that don’t seem to be removed by min region size).
Using the beta version it indeed now generates graphs that look as expected, the nodes are connected and paths are calculated correctly. I’m using 2019.4.6f1 where it complains about unsupported burst on every scan though (i can’t find a toggle to explicitly disable it).
The grid graph seems to generate a good approximation of the ground now.
To achieve comparable precision with the recast graph i need to set the tile size very low (~10).
I need around 10 graphs with ~ 1km*1km size, used simultaneously.
And at some point i may need stacked graphs so my first instinct would be to use the recast graph, also because it doesn’t seem to need to contain unused nodes (unwalkable). But to achieve the required precision i’d have to use tiles which also creates a good amount of small undesired extra islands.
Does lowering tile size have noticeable performance implications compared to just using the grid graph? I’d imagine that the grid graph has special optimizations due to its structure.
Or is there an alternative setting to make the non-tiled recast graph follow the ground more closely?
Edit: Just sharing some observations:
Displaying the gizmos for a 1x1km graph slows the editor down to ~1fps.
Scanning the tiled recastgraph with tile size 16 takes 6minutes, Grid graph is almost instant.
Non-tiled version errors out right at the start with OutOfMemoryException (<0.175 cell size) in ParallelWorkQueue it seems, although unity itself only takes up about 3gb according to the taskmanager (16Gb system ram).
Looks like i have to use the non-tiled version with larger cell size, and physics for movement.
Edit 2: i just realized i can potentially use additional graphs where i need more precision, that will most likely solve my problem. Now i just need to find out how to do that properly. First tests find no paths where they overlap.
Edit3: ‘Full Get Nearest Node Search’ does it. The only problem now is that the path search sometimes alternates, creating wiggly movement when the selected graph changes.
It would be nice if there was a way to remove portions of a specific graph. Maybe there is; i couldn’t find one yet.
