[Blueprint only] How to update NavMesh locally after moving objects?

Development Programming & Scripting Blueprint
, ,
1

Hi everyone!

I’m working on a project entirely in Blueprints (no C++), and the player can move objects around during gameplay. I need the NavMesh for NPCs to update accordingly when objects are moved.

I’ve been trying to find a way to partially update the NavMesh, but ran into several limitations:

  • Functions like Rebuild Navigation and Update Nav Octree seem to be unavailable in Blueprints — I couldn’t find any way to call them either through nodes or console commands.
  • I tried using NavigationInvokerComponent, but after enabling “Generate Navigation Only Around Navigation Invokers”, my NavMesh completely disappeared, even with the invoker active. So maybe that’s not a suitable solution for my case.
  • For now, I’m using NavModifierComponent as a workaround. It helps, but:
    • I can’t dynamically control the size of the area affected.
    • Most importantly — if the object was placed in the level before the game starts, and I move it during gameplay, the NavMesh doesn’t regenerate in the old location, so NPCs still avoid the empty spot.

Also, switching to Runtime Generation: Dynamic isn’t an option for me due to performance concerns.

So far, it seems like calling Rebuild Navigation through C++ might be the only reliable solution — but I’d really love to hear if someone has found a better way to handle this kind of scenario in Blueprints.

Thanks in advance for any suggestions or experience you can share!

2

Hey @Solya_Minor!

I do have to ask what you mean by this? It’s 100% based around the size of your navmesh, if it’s too big you need to focus on making your invoker idea work because that would limit the size necessary, then use dynamic on top of that. You can also lower the refresh rate of the dynamic Navmesh to also lower the overhead.

But the problem here lies in the name itself, you see. “Static” and “Dynamic” literally mean “unchangeable” and “changeable”. :frowning:

Why don’t we focus on getting your invoker to work? Get back to us on that, what is happening there, why isn’t it working? :slight_smile:

1 Like
3

Hi! Thanks a lot for your reply and your thoughts — I’ll try to explain what made me think Navigation Invoker might not be the best fit for my case. Maybe I misunderstood how it works, and I’d really appreciate clarification if that’s the case.

In my project, I have Interactive actors (like furniture or boxes) that the player can move around the level during gameplay.
I also have NPCs who need to interact with those same objects — walk to them, use them, etc.

So from what I understood, for an NPC to be able to find a path to an object, that object must be inside the radius of a generated NavMesh.
And since NavMesh is generated only around Navigation Invokers, I assumed that each NPC would need an active Invoker Component, with a large enough radius to include any object they might need to reach.

Let’s say I have 10 NPCs — then I’d have 10 active Invokers on the map, all with big radii, to make sure interactable objects are covered. That seemed inefficient and potentially heavy for performance, especially if the NavMesh needs to constantly rebuild around all of them.

So maybe I misunderstood something fundamental about how Navigation Invokers work, or how to set them up properly. I’d love some guidance there.

Also, I’ve found the setting to limit how frequently the NavMesh updates when using Runtime Generation: Dynamic, so that’s no longer a problem. Thank you!

My NavMesh area isn’t very large, so maybe using Dynamic updates really could work well in my case.
It’s just that I’ve read in many places — both in forums and in official documentation — that this approach is generally not recommended, so I was hesitant to rely on it.

But perhaps with proper configuration, it might actually be the simplest and most effective option for my situation.

Thanks again — I really appreciate your time and help!

4

You could use the ai sight to gather interactive objects in the ai’s memory through senses.
You could then use the distance between the ai to the object to calculate the radius of the invoker.
Then trigger the invoker radius and calculation for the intractable that interests you.

1 Like
5

Thank you! Your approach sounds great. But I’m not using AI Perception yet and the invoker radius can’t be changed via Blueprints directly. I thought about creating several invokers with different preset radii and enabling them as needed — but that feels like a bit of a workaround and not a very flexible method in the long run.

6

The invoker component already has a function for this, it’s just not blueprint exposed

void UNavigationInvokerComponent::SetGenerationRadii(const float GenerationRadius, const float RemovalRadius)
{
	TileGenerationRadius = GenerationRadius;
	TileRemovalRadius = RemovalRadius;
}

as for the update rate, it’s not driven by the invoker. The invoker seems to register with UNavigationSystemV1 => the navigation system, and that drives the update rate. You could call the rebuild manually as well.

Unfortunately not all parts of the engine are exposed to blueprints, and with time you may find that you will have to dabble in some simple c++.

If you don’t use the ai senses then you could alternatively to a sphere cast around the ai filtered only to intractable objects. and then build a path between the ai and the object through “find path to location synchronously”.

1 Like
7

Thanks so much for the detailed explanation — and for sharing yet another interesting approach!
The idea with sphere cast and Find Path to Location Synchronously is great, I’ll keep it in mind.

And yeah… it’s starting to look like I’ll eventually have to dip into C++ after all.

Thanks again