Changing Recast Cell Size/Height Per Tile

Is it possible to change the Cell Size/Height on a per Tile basis? We have a large outdoor space that uses a Cell Size of 0.3 and Cell Height of 0.4. This works fine in most cases, but there are some places where it doesn’t give the desired results (and a smaller cell size would fix the issues).

Ideally we would be able to force specific tiles to use a smaller Cell Size/Height, and leave everything else (98% of the scene) to use the larger Cell Size/Height.


And you cannot just use the same small cell size everywhere in the world?
Cell height should usually just be set to as small a value as possible. I plan in the future to remove that field from the inspector and set it automatically.

It is not possible to change the cell size or cell height per tile unfortunately.
It might be possible to do with some code, I will think about it.

Using a small enough cell size (0.1) resulted in a larger (number of bytes) navmesh, and a much longer scan/bake time.

The outdoor space is about 2000m x 2000m.

It would be nice to have this feature, as typically in outdoor spaces you only need a smaller cell size for certain spots. Thanks for the speedy response.

Can you direct me to where Cell Height is explained? I don’t have a good sense for how that impacts the resulting navmesh and scan time.


If it generates a larger navmesh as in the number of triangles (which is directly linked to the number of bytes) you can increase the “Max Error” setting on the recast graph which will simplify the edges.

Yeah, it will take more time, can’t do much about it at the moment though.
You can try to open the “Optimizations” tab and enable the “ASTAR_RECAST_BFS” which will speed it up a bit, it is a bit more unstable however which is why it is disabled by default (so it might fail to generate a navmesh over some part of the world. It will log an error whenever this happens however so if it doesn’t log any errors for your level, it’s fine).

The whole world is rasterized into voxels (think minecraft, but smaller blocks), the cell height is the height of one of those blocks in world units (cell size is the width of them). As you say it is a bit hard to get a grasp on exactly how it affects the navmesh, it doesn’t really have a direct connection to the navmesh except that if you set it too large, your navmesh might not be connected where it should be and you might lose precision, if you set it too small, it might run out of bits to represent the whole level and integers will overflow internally (bad).
Because the connection to the navmesh is not very direct, I am planning, as stated above, to remove it and just calculate it automatically based on the assumption that the lowest cell height which will not cause internal errors is the best one (which is almost always the case).