From what I can gather from the forum, the recast graph is the recommended solution. I am able to generate the recast graph at run time by rasterizing the generated terrain and colliders. My question is, how do you handle penalties for different surface types like sand, water, etc. when using a recast graph? Also, I have been using the RecastMeshObj and using an area of -1 for obstacles as suggested in the tutorial video. Is this the recommended way to handle obstacles like rocks? It seems to work OK for large objects but smaller objects don’t seem to be picked up by the scan even with a high resolution. It also seems to be hanging when attempting to rasterize trees.
Large procedurally genrated open world terrain with accessible buildings and small obstacles
I am not sure if you are the same person that posted about hanging when rasterizing trees, but if not, do you know if it shows any exceptions in the log?
A (tiled) recast graphs would probably be the best bet.
Make sure that the max climb is set low enough so that the rocks will not be considered “possible to climb over” and that the Cell Height is low enough so that the resolution on the Y axis is high enough.
Generally I use the Character Height set high enough so that there is no navmesh generated inside of rocks, then it will usually work. It is a bit annoying to have to set an area of -1 on each rock.
It is a lot harder to use different penalties for different parts of a navmesh based graph since they don’t have the same granularity as other graph types like grid graphs.
However what you can do is that you use a RecastMeshObj and set the area to some positive number, then that will create a split in the navmesh and you could use a GraphUpdateScene component to mark it with a specific penalty or tag.
Yup, I am the same person who asked about the trees. It appears to just sit on the scanning popup progress bar forever. “Scanning graph 1 of 1”.
Does decreasing the cell height significantly increase scan time? All of our rocks are prefabs which are randomly scaled for variety so adding the RecastMeshObj to the prefab is not that tedious. I am running into trouble however because we are using LOD meshes with one collider for the prefab. I get an error in GetRecastMeshObjs because it cannot find the renderer because it is on the LOD objects, but the collider object is the one that has the RecastMeshObj added to it.
Another question, which I believe has been asked before to some degree. Would it be possible to store the recast graph information in a prefab of say, a house, and when loaded insert it into the terrain’s recast graph merging it into one?
Take a look at the Unity log. That will hopefully reveal some information.
No. Decreasing cell height should barely change scan time at all.
In fact I think I will rewrite the system so that it uses the smallest cell height it can automatically.
Can’t you just attach the RecastMeshObj to the LOD mesh then?
Sorry, that is not possible.
Well, it is possible, but it would provide almost no practical advantage in either memory or time over just scanning the tile again.
You can use a navmesh cut http://www.arongranberg.com/2013/08/navmesh-cutting/
Attaching the RecastMeshObj to the LOD fails because there is no collider on it and I am rasterizing colliders.
Hm… yeah, it might be possible that RecastMeshObj only supports meshes and not colliders. I will add this to my TODO list.