Rebuilding navigation at runtime after modifying geometry.

Development Programming & Scripting C++
1

Hi guys,

I’ve been trying to post this in the AnswerHub but I cannot log in at the moment, so apologies if this is not supposed to be here :slight_smile:

I’ve got an environment build at run-time with a navmesh on top of it.
The project I’m working on requires LOTS of modifications to this environment at run-time so I started playing with this function


GetWorld()->GetNavigationSystem()->AddDirtyArea(kBox, iFlags);

I call it whenever I modify the world providing the area to set as dirty, in the editor the green area representing the navmesh turns red when I call the method (thus signalling that it was actually marked as dirty, I guess…) but when the area turns green again no modifications are applied.

And yes, the geometry and the collisions have both been correctly (and visibly) modified.

The thing is that I’m not completely sure about the meaning of the Flags parameter to pass to the function; Digging around I found this definition:



enum Type
	{
		Geometry	      = (1 << 0),
		DynamicModifier = (1 << 1),
		UseAgentHeight = (1 << 2),

		All = Geometry | DynamicModifier,		// all rebuild steps here without additional flags
	};

I’m currently using 3 which is “All” but it really doesn’t do anything!

Any ideas? Am I missing something?

Thanks!

2

You dont have to do anything in C++ to get the nav mesh to update properly!

Just go to

Project Settings->Navigation->Rebuild at runtime :slight_smile:

It will always stay up to date

7eb741e88087492cd334de01bc4adcfcb5ae49a2.jpeg

If you want to get really fancy change the update frequency to 1 instead of 60 in the other navigation category under Project Settings (Navigation System)!

Rama

3

Uhm, I have that checked but I’ve not tinkered with the value in the other window (60).

One thing that the editor lacks is the units of the various settings, it took me a while to understand that the recast values are in meters and not units :wink:

I’ll give it a go.

Thanks Rama!

4

Just tried setting “Dirty Areas Update Freq” to 1: nothing.

Let me explain my situation a little bit better:

When I launch my game a terrain is generated and its geometry and collisions are added to the scene. I’ve got a big NavMeshBoundsVolume that wraps all the geometry and it correctly creates the navmesh from my geometry and collisions.

If, at run-time and after it was generated the first time, I do modify my terrain (by removing or adding geometry and collisions) the navmesh doesn’t update anymore.

I’ve also just noticed that if I move (Eject->Select the actor->Translate) the actor containing my terrain around, the navmesh DOES update around the new geometry.

I’m going crazy after this thing!

5

“If, at run-time and after it was generated the first time, I do modify my terrain (by removing or adding geometry and collisions) the navmesh doesn’t update anymore.”

You have a much bigger problem!

You cannot modify landscapes at runtime in packaged games!

Or are you saying your terrain is made of static mesh actor pieces?

Have you tried packaging what you have so far?!

Epic has told me many times they are adding support for runtime collision cooking in packaged games soon

but you should make sure all your concepts are sound before proceeding any further,

and if you got runtime landscape collision generation to work please do let me know!

Rama

6

I’m not packaging the game!

No, it’s made using your tutorial on the wiki about generating meshes at run-time :wink:

Not so far, but, at this point, I will :slight_smile:

7

I think I have a series of HUGE problems to be honest.

I’ve been testing lots and lots of possible solutions to my current problems and nothing seems to work :frowning:

Let me wrap them up:

I want to generate a “Minecraft-like” (not exactly the same, but it’s to give an idea) environment at run-time. I managed to generate the environment (thanks Rama for the wiki entry!) and it’s actually pretty fast, so I’m happy!

Now for the problems:

  1. I want to be able to modify the environment, think about adding/subtracting blocks, to stick with the Minecraft analogy, I managed to do that, (again, pretty fast!) but the navmesh cannot be bothered and I cannot find a way to update it at run-time.
  2. So I switched my focus to making some ACharacters move on top of my environment but they don’t want to do that. The same ACharacter (same blueprint) put on a static mesh runs around like Usain Bolt!

I’m pretty bored of attempts so I’ve got two questions:

  1. Is it possible to modify the shape of a piece of geometry and have the navmesh update based on the new geometry?
  2. Is it possible to use navmesh navigation using a navmesh COMPLETELY generated at run-time?

Thanks, and sorry for the rant, I’m stressed

8

This is your fundamental problem right here

You can’t generate collision for procedural meshes in a packaged game yet!

Epic still need support for this

Also the wiki was written by Dmacesic, I can’t take credit for that one :slight_smile:

See Dmacesic’s request to Epic about adding packaged game support for procedural meshes!

Your project cannot realistically continue in the manner of using procedural meshes for collision until this fundamental issue is addressed!

You could try using instanced static mesh actor but I am not sure about collision issues with that, wont be as fast as procedural mesh

Best to encourage Epic to implement procedural mesh collision support for packaged games!

I can’t continue with my UE4 Max (3ds max remade in UE4) until Epic does this!

Rama

9

I don’t care about packaging the game. I’m trying to understand whether these things work in the editor or not.