Having problems with overlapping Nav Modifiers

Hello, i’m currently working on the AI for my game but have gotten a bit stuck with using the Nav modifiers.
I understand how the modifiers work and how they should be used, but that is not the issue i’m having.

For what i’m doing i would like to have modifiers that overlap, but it seems very random what modifiers will affect the navmesh when they are overlapping. I will try to explain what is happening, in this first image i have two modifiers, one that is quite wide, and another one that is thinner than the first one. The dark green color indicates that the wider, first nav modifier is being used, not the thinner one in the middle.

In this next image i have pulled up the thinner nav modifier away from the navmesh and then placed it back into it’s original location. However, now the thinner nav modifier is also being used as you can see by the different green color.

It’s really annoying to work with nav modifiers that are overlapping since it seems that the nav modifier that was placed into position last will override the other ones that are already there.

Is there any way to set some kind of priority to the nav modifiers which forces them on top of other nav modifiers? Or is there something else that can be done to make overlapping nav modifiers easier to use?

Thanks.

You can enable ares “sorting” in Project Settings > Navigation Mesh > Sort Navigation Areas by Cost. Once enabled the navmesh generator will sort areas to be applied based on their cost making sure the most expensive areas end up on top. Of course this is not always what you want, so you can override the function that does the actual sorting, ARecastNavMesh::SortAreasForGenerator

Cheers,

–mieszko

2 Likes

This is great for dealing with multiple modifiers that effect the same agents all of the time.

In a situation where two modifiers overlap but only one is used per MoveTo request based upon an agent’s default navigation filter, would the navigation system handle this? Say the one with higher cost has ended up “on top” but is not actually used, but the one “below” is - Would the one “below” be effective in this case in areas where it overlaps the dormant “on top” one?

They should add an INT based priority system to the Nav Mesh Modifiers.