I’ve been trying to use navmesh with tiled landscapes. However, when a new map (with tiled landscape) gets loaded, navmesh doesn’t get built on it, UE4 builds it on top of the first loaded tiled landscape. In essence, the first tile gets multiple navmesh layers built on it.
Edit: Just to clarify, not trying to stream in navmeshes (that is not possible as of now, right?), but trying to build them as new levels load, on runtime.
Is there any way of using navmesh with tiled landscapes? What is the preffered workflow here?
Another question is the use of navmesh on large landscapes (8k x 8k). I tried to use it, but seems very crashy when working with large areas. Is it better to use a single large bounds volume for the whole playable area, or is it better to use multiple smaller bound volumes?
After some troubleshooting, it seems navmeshes can’t compensate when the origin of the world changes. That is why they build every tile on top of 1 tile (like pancakes).
I’m assuming this is a bug, as currently there is no way of working with navmeshes while using origin shifting, which is basically a requirement for the world compositor to work (right?).
Coupled with the instability of navmeshes on large maps, I’m at a loss on pathfinding at the moment. Any input is appreciated!
Don’t know what caused it, but making a clean import fixed the issue with navmesh and world compositor/tiled landscapes. It works in the game, probably did something the wrong way in editor first time around. Thanks Ehamloptiran.
Were you ever able to find anything out about using nav meshes with large terrains? I too am getting a lot of crashes with nav mesh volumes that are large in size.
Nope, it still crashes if the bounds volume is too large, or if I change the settings during its update. I assume those will be fixed eventually.
Currently, we do not use bounds volumes bigger than 2000x2000 size, even at that size, it can crash if you “bother” with it while it is doing its thing though.
I’ve had this problem as well. It seems that if you’re using streaming levels and the project isn’t set to rebuild navmeshes during runtime then you can end up with all the levels’ navmeshes on top of each other instead of correctly offset as Chariots mentioned.
I enabled rebuilding and thought it still wasn’t working until I looked in the properties for the RecastNavMesh object generated when building nav meshes and saw that the Rebuild at Runtime check box was still unticked! It seems that the project settings don’t update existing things very well. Checking Rebuild at Runtime in the RecastNavMesh then resolved the issue.
After I had changed the project settings any new RecastNavMeshes were fine.