Dynamic NavMesh Generating

[MaxPower42]

I wish UE4 would have better support for procedural level design.

And one thing you could improve rather easily (I assume) is how NavMeshes are generated.

Recast NavMeshes are great for hand-made levels that have some moving elements. The way I understand it, the updating is running in the background with minimal cpu usage.

But when you create large parts of a level procedurally, it would be better if you had an option to update the NavMesh as quickly as possible with all available resources, and freeze the simulation in the meantime.

[Jambax]

It would take much longer to create the NavMesh on the main thread since IIRC, it splits the work off into multiple worker threads to speed up the process. If you have a large level, you don’t want to be using one giant navmesh anyway, it’s way too expensive and resource heavy and if anything your pathfinding will be slower with such a huge mesh to plot through.

There’s probably a delegate that fires when the navmesh has built, you can possibly block the main thread anyway until that delegate fires? You’ll have to do some poking around to find it though, or alternatively dig into engine source yourself. I’m not sure Epic would make this change themselves, since for most games with large worlds generating it in chunks in significant areas is more suitable. Never know though…

Either way (I’m making assumptions about the design of the game here), do you really want players sat doing nothing waiting for NavMesh to build all the time? It’s not very fast and dependent upon the users CPU power, which might not be as great as yours. Some levels take several minutes to build a navmesh.

[MaxPower42]

Well, I just want to be able to generate truly random levels. And it would be better if the player had to wait a little longer until the level is loaded than starting to play immediately while the AI isn’t able to move for a potentially long time. It would perhaps be helpful as well, if each “module” used in random level creation could have its own pre-built NavMesh and they would just be stitched together. That wouldn’t help with “dynamic landscapes” created at runtime of course, but those will never be added anyway…

I know way too little about how the engine works internally to judge if simply “stopping” the main thread would speed up NavMesh generation. From my amateurish point of view it just “feels” like it could be done quicker when smoothly running a game at the same time is not a prerequisite…

Since I have a large non-linear level that requires all AI units to be able to move freely, why wouldn’t I “want to be using one giant navmesh”? Are you suggesting I should use several smaller ones like in a grid or something?..

[jonimake]

What’s wrong with the runtime generation that’s in now? Does it not work in this case?

[ambershee]

We’re using run-time generated nav-meshes without any great issue. If you want to completely generate the nav-mesh instead of only the parts where it is required at a given time, I would suggest stalling the start of the game until navigation is ready.

[zeOrb]

Here is tutorial about NavMesh Invokers from developer

[MaxPower42]

@jonimake;601629

What’s wrong with the runtime generation that’s in now? Does it not work in this case?

It works well. It’s just that on a large procedurally generated map it takes very long to generate and AI units can’t really act until it is done.

@ambershee;601686

We’re using run-time generated nav-meshes without any great issue. If you want to completely generate the nav-mesh instead of only the parts where it is required at a given time, I would suggest stalling the start of the game until navigation is ready.

I don’t suppose you know if there’s any way to speed up the process and “channel” all the resources that would normally be needed for the game simulation into NavMesh generation? Don’t know if this sounds naive…

[MaxPower42]

I’ve got 2 questions about obstacles on NavMeshes.

1. Is it possible to give areas a cost-multiplier or are there only all-or-nothing obstacles?

2. Is it possible to make obstacles apply only to selected agents and not all of them?

[MaxPower42]

@Chariots;601687

Use the UNavigationSystem::OnNavigationGenerationFinishedDelegate to get notification on when navmesh generation finishes. If you don’t want the game to be playable until navmesh generates, just extend the loading screen until the delegate fires.

Speed-wise it doesn’t really matter to stop the game thread to generate things faster, you won’t get significantly shorter generation times.

I’ve done runtime generation on 2kmx2km patches before in runtime, and it worked just fine. If you need to navmesh a larger area, I highly suggest using navmesh invoker components, as they’ll be significantly faster and more memory efficient.

@zeOrb;601827

Here is tutorial about NavMesh Invokers from developer

Thank you, I will look into that.

Doing it the normal way seems to be much too slow for what I’m trying to do. I’ve got this large open landscape and I randomly place trees and rocks on it after loading. It serves as a battlefield when two armies meet. By the time the NavMesh has handled all the trees and rocks the battle is already done…

edit: hmm, I don’t think “invokers” are really an option for me. I need characters to be able to navigate from one side of the battlefield to the other right from the start.

Maybe I can tweak NavMesh settings somehow to speed up the generation. Or maybe I picked the wrong engine for procedural design and should go back to Unity.

[MaxPower42]

It would be enough, in the case of trees and rocks, if I could simply cut out small areas of the NavMesh on the landscape. But there is no fast and simple way to do this, is there?