Recast graph bounds

General Recast graph
#1

Hi there, how can get I graph bounds, which is set to build graph (on the screenshot)

image
image846×1503 125 KB

I need this information for flying player phase, to check whether player inside map, or not.

#2

Hi

I would recommend:

var graph = AstarPath.active.data.recastGraph;
var bounds = graph.GetTileBounds(0, 0, graph.TileXCount, graph.TileZCount);
#3

Thanks a lot! I’ll check it! Think it fit absolutely!

#4

Thank you again for this solution.
But I also found, when i use tiles, some of them exceeds graph bounds (cause size of tile)
And when I don’t use tiles, then it’s all ok.
Please tell me when its better to use tiles, and when it’s not?
And also, if I won’t use tiles, will this method works? (I think the tile count will always be equal zero on graph)

#5

Hi

If your graph is not rotated, you can use

var bounds = new Bounds(recastGraph.forcedBoundsCenter, recastGraph.forcedBoundsSize);
bounds.Contains(...);

In the next beta, I’ll add recastGraph.bounds and graph.IsInsideBounds(point) to make this simpler in the future.

Tiles are nice if you have a large graph since it makes the scan significantly faster. It also makes graph updates faster since it can update only some tiles, instead of the whole graph.

If you don’t use tiles, the graph will consist of 1 big tile. The method will work.

#6

Thank you.
Also if tiles are better to use for scan, can you tell more about amount of tile size. Which performance parameter depends on it? So if more tiles are better then less, so what will go bad if I will set too much tiles? And what number is this “too much”?

#7

Typically, a value between 64 and 256 is a good value for the tile size.

A lower value allows more parallelism when scanning the graph, but this stops mattering much once you go past 16-32 tiles.
A lower value may allow you to make faster graph updates, if you only need to update a very small part of the world.
A very lower value may make scanning slower, as too small tiles have an overhead.
A lower value causes the graph to contain more nodes, which slightly slows down pathfinding.
A lower value may cause less optimal paths in some cases (but the beta version improves on this).

#8

Thanks a lot, for such detailed answer.