From RecastNavMesh.cpp:
// rule of thumb, dimension tile shouldn't be less than 16 * AgentRadius
if (TileSizeUU < 16.f * AgentRadius)
{
TileSizeUU = FMath::Max(16.f * AgentRadius, RECAST_MIN_TILE_SIZE);
}
This comment doesn’t explain anything. What is supposed to happen if tile size is made smaller than 16 * AgentRadius? For example, 8 * AgentRadius. What will break if tile size is less that RECAST_MIN_TILE_SIZE (300)?
Probably nothing will break, since we already bumped up limit of max tiles and polys.
Main reason behind it was ensuring that users don’t end up with thousands of tiles holding just a single cell. 16x agent radius (~ 2 or 3 cells) means at least 32x32 cells in tile, which gives region detection code something to work on. Ideally you’d want to have >100x100 cells for tile, both for performance (less tiles = faster) and usability (bigger tile = bigger polys = easier pathfinding) reasons.
Hi,
We think this post contains useful information which we would like to share with our public UE4 community. With your approval, we would like to make a copy of this post on the public AnswerHub which includes the discussion but strips out your username and company name. Please let us know if you are okay with this.
Thanks!
bigger tile = bigger polys = easier pathfinding
Well, my reasoning is kinda reversed: bigger tile = bigger polys = worse path quality
While we’re here, could you comment on cell size? We currently use CellSize = 0.25f * AgentRadius.
Keep in mind that A* is limited to 2048 (if I remember correctly) node pool. If level’s geometry / area costs leads heuristic to local minimum you may run out of nodes before reaching goal. More polys you have, less chance of completing path. Not to mention time spent in A* loop.
How path quality is worse with bigger polys? Each poly is collision free walkable space, paths are usually string pulled before using anyway, so actual size should matter. If anything, bigger poly gives more leeway inside corridor for avoidance.
That’s reasonable value. Basically, smaller grid gives more accuracy in tight corridors (1 cell wasted as partially colliding on each side) at the cost of generation time. We’re usually having more coarse grid: 2…2.5 cells per radius, but that really depends on project requirements (especially static vs dynamic generation)
Sure, no problem