However, I’m a bit new to working with nav meshes, and I’ve got some best practice type concerns.
First, it should be known that I have a rather large persistent level, which contains an elaborate matinee cutscene and some fancy special effects. I then have the remainder of the map’s assets distributed among eleven streaming levels. It’s come time to finalize the map’s nav mesh, and I’m curious about the following issues:
For small levels, I’ve always used a single NavMeshBounds object to encapsulate the entire level. However, due to the size of this level, the bounds of such a box are 35000 x 50000 x 10000. Building navigation on a box that size takes an immense amount of time; so much time that I usually get impatient around the 35 minute mark and attempt to close the editor (which always just crashes not only the editor, but my entire computer). Am I better off just allowing this to complete? I know I need a better computer… but, ****! The editor is completely unresponsive during this process (seems frozen at Building Navigation (1).)
An alternative would be to split up the NavMeshBounds, and use multiple volumes to more tightly cover my intended surface area. Is this a viable workaround, and would it have any noticeable impact on navigation build times?
If using multiple volumes is viable, my solution would likely end up requiring quite a few volumes. Is it possible to place NavMeshBounds objects into streaming levels, or must they be part of the persistent level?
I’ve gone around the map and ensured that only intended objects affect the nav mesh, giving me a mostly clean build all around. However, nav mesh on terrain is awful! (It’s also one of the reasons I think my build is taking so long…). Is there a way to optimize terrain for nav mesh builds? Just go in and smooth it out, I guess?
Any insight on the subject would be great! Thanks in advance =p
I attempted last night to let the build process wind out on a large, single NavMeshBounds object. The size of this object was 40000 x 50000 x 10000. I began the build process Just before I went to sleep, and it very quickly went to (“Building Navigation (12)”) before freezing. I then left the process running all night while I slept, nearly nine hours. When I woke up, the editor was still frozen with the log displaying (“Building Navigation (12)”).
After that, I must deem that building from a single NavMeshBounds object is impossible (or just unacceptable?) for this level. I can’t just let my computer process that for two days each time I make a change, or however long it might take (assuming it would finish the build process at all).
I ended up splitting all NavMesh into seven separate streaming sub-levels. Turning them on, one by one, and allowing each level to build individually causes them to build successfully, it just takes FOREVER. Like literally, 10+ hours to do all of it.
I still need some insight into how to better optimize the navigation build process for landscapes, as well as very large levels such as CTF-Elemental. The landscape navmesh is almost certainly one of the culprits, as building any nav on landscape is an arduously slow process. Sure, it could totally be my computer… but I’m thinking that’s not the entire case here. (I run a quad core 3.4ghz AMD, 16GB ram).
Also you can disable automatic navmesh rebuilding in the editor, there is should option somewhere in Editor Settings, you can then build navmesh on demand using Build->Build Paths like static lighting.
You need dynamic navmesh then. Unfortunately dynamic navmeshes does not support streaming yet. But you can still use it with streaming levels, you will need to enable bUseFixedTilePool as mentioned in linked topic. With fixed tile pool navmesh will rebuild only areas covered by navigation volumes that is streamed in/out.
We will add proper support for streaming of dynamic navmeshes in near future.
In 4.8 version you will also have “semi-dynamic” navmeshes. It’s basically a static navmesh that supports dynamic obstacles (navigation area modifiers).
It would be great to have an option on Static Meshes so that they can block the Nav Mesh, but the Nav Mesh won’t build on them. It’ll save time building Nav meshes and memory on final Nav meshes.
Thanks for the reply. I actually did find that post while searching before I started this thread. It was helpful, certainly. At this point I’m guessing it’s simply my computer that isn’t able to handle these types of calculations all that well. Sucks, 'cause now when paths are all built, leaving them visible in the editor makes it impossible for me to use anything. The editor window just sits there, frozen in time. Lagged out.
I definitely turned off the automatic navmesh rebuilding, which at least made it so I could work at a regular pace again. But as soon as paths are visible, I’m donezo. Guessing I need to upgrade, but I can’t afford to do so right now =(
I definitely turned off the automatic navmesh rebuilding, which at least made it so I could work at a regular pace again. But as soon as paths are visible, I’m donezo. Guessing I need to upgrade, but I can’t afford to do so right now =(
[/QUOTE]
Yeah, this is a known problem, on big maps navmesh visualization degrades editor performance. Visualization is main reason why navmesh async build slows down in the editor as it has to recreate render information nearly every frame (even when visualization disabled). There are ongoing work to improve visualization performance, so it should be better in near future.
Despite that, I went ahead and installed a brand new graphics card. When I originally posted this thread, I was running on the very low end of the spectrum with an Nvidia GTX 550 Ti. While I’m still on the low end, I upgraded to a GTX 750 Ti tonite and I am pleased to report that the editor lag is basically a non-issue now. Building paths no longer hangs at low percentages, and instead completes quickly, as would be expected.
Once fully built, with full realtime graphics and nav visualization on, the in-editor frame rate is still not perfect… but it’s definitely smooth enough to continue development. Guess I can consider this solved on my end! Thanks for the input, ddvlost!
It is sometihng to the wirt geometry inside the nav mesh volume. I am new to the unreal 4 but with my practice shows for ex: if a very complex geometry is inside the nav mesh say it a instance static mesh cloud formation and if the generate nav mesh data is set to true with the cloud formation, nav building now builds for this cloud formation too. It also goes for the dons flying ai’s manager too. For this reason it issound to make the nav mesh volume with nothing in it. And then save the game step by step, adding the geometry inside it and saving again. With this i can spot what causes the nav mesh volume to make the very long time builds.
i experienced the same problem, i had a trigger which switches levels. but everytime I get to the second level the navmesh isn’t working.
everytime I load in it in the editor and play it works just fine