4.14.3
Why tho?
Not a bug. It’s because Recast has no concept of “inside”, just “blocking surface”. It’s a feature of Recast - what if you had a big blocking volume, that a player cannot get into, but where AI lives and can be observed? If you want to get rid of these areas use navmesh modifiers or play around with RecastNavMesh.MinRegionArea value.
Cheers,
–mieszko
1 Like
Well, MinRegionArea sounds pretty good. Is it works tho?
So, I have sphere to get random location to spawn enemy AI, what do I do so they wont spawn into meshes? How I can make him select a piece where he can reach player character, something like GetReachablePointToOtherActor.
MinRegionArea = 46 - doesnt remove anything
MinRegionArea = 47 - remove small piece
MinRegionArea = 47 to 2000000 - doesnt affect anything
1 Like
Hey Xukapy,
I’d actually recommend using Nav Modifiers here if the Min Region Area isn’t working out in this particular case. What you’ll want to do is just place Nav Modifiers set to NavArea_NULL so that the Nav Mesh won’t generate in those spots. This should resolve the issue and prevent the worry of characters spawning into objects.
Have a great day
So you recommend me to make NavModifiers for EVERY static mesh that has collision in my world? Do you understand how stupid this sounds? Just becasuse “I might want blocking volume where AI lives”? I’d just make static mesh of walls instead of solid mesh, dont you think?
Or maybe you can enter bug that MinRegionArea doesnt work
and feature request boolean like “generate NavMesh inside meshes”
Don’t make workarounds please where there are problem areas. This forum for troubleshooting not troublearounding
2 Likes
Hey Xukapy,
As Mieszko stated, the Nav Mesh generation is working as intended. If you’d like to make the desired changes and prevent the Nav Mesh from generating inside of the blocking volumes, you’re more than welcome to download the source and make these changes yourself.
Min Region Area is, in fact, working. The reason it’s not removing these smaller sections of Nav Mesh like what you’re seeing is because it’s only really meant to be used in isolated areas that are surrounded by areas that do not contain Nav Mesh. What you’re seeing is an area that lies on the edge of a tile, which means the Recast will assume that other tiles may contain Nav Mesh that can merge onto that tile, causing the size to meet the minimum region area requirements that you set.
That’s why I recommend using the Nav Modifiers in combination with Min Region Area changes to get your desired result. This is not a workaround, this is intended behavior. I recommend trying to keep your geometry in your level as smooth as possible to avoid any unwanted Nav Mesh generation as well on jagged or steep-inclined areas.
Let me know if you have any further questions regarding this, but we do not believe that this is a bug with the Unreal Engine at this time.
Have a great day!
I just discovered this as an issue myself and honestly I am surprised by Epics stance on this; you can literally place an opaque cube on top of another and get nav inside the negative space. While this might be excusable as lack of implementation on recasts part, its really not; you even suggest that OP implement this on their own…why not add the negligible lines of code to the recast generator and expose it as an option. You could literally just double down on the element enumeration within FRecastTileGenerator::DoAsyncGeometryGathering() and implicitly add null area modifiers using the same geometry collision data (albeit shrunk about the axis to not produce a net-zero).
The behavior of placing a cube in a default map and getting nav inside is just bizarre…dont pull a technicality here guys 
Edit: even more confusing is the nav generation for hollow BSP…the behavior is simply not cohesive.
2 Likes
I’ve been a Level Designer on AAA games for 15years, this is the first time I see such an inefficient and expensive way to tackle a simple issue. Not only that is an incredible waste of time, but each navmesh_null is taking a toll on the map memory usage.
Why not make a Remove Isolated navmesh algorithm ? Basically removing any navmesh not connected to a Character/Pawn blueprint or playerstart. Then, additionally, create an entity to force navmesh generation in places where the user wants one specifically.
4 Likes
Awesome. I’ve just come across this issue myself (items spawning within static meshes due to navmesh data existing inside meshes as well as ai trying to get to those locations).
This seems like such a simple problem that eliminates the automated nature of navmesh data. Good to know Epic’s solution is incredibly labourious and ill-advised.
2 Likes
I found a workaround to solve this kind of case (it’s not the ideal way of dealing with it, but at least it works).
Whenever you need spawn something on a navmesh, just test if its location can be pathfind to, using GetPathLength. You’ll get an enum that tells you if it succeed or failed. If it fails, try somewhere else.
You just need to check with the player’s location or something else that you know will be on the navmesh.
The work around I ended up using in my case was generating a linetrace upwards (as the positions I wanted were exposed to the “sky”). If it hit any mesh then it would pick another spot. Thanks for sharing your solution though.
Have to agree with other level designers here. Easily one of the most consuming parts of my gameplay passes on my teams project is cleaning up floating bits of navmesh as required for our internal tools. Been working on games for 17 years, won’t say this is the most tedious work I’ve done but it’s up there. Having to place pathnodes every 5-10 feet back in UE2 days still gives me feverish nightmares. That all being said, my previous company… famous for a marine slayer of demons, had an elegant solution with recast. We placed “seeds” and any island of navmesh not connected to a seed was automatically removed. The process of flying through a production took maybe 15 minutes, tops. The process I go through now using nav modifiers can take me 1-3 work days on final production maps with art. No bueno and it tortures my soul similar to pathnode days. Miezko you’re my only hope. Please address <3
1 Like
It’s rare to see an issue where 100% of the people posting agree.
Epic please fix this issue. At least give us a bool on the project .ini (if not on the static mesh itself).
…or keep being stubborn and thinking that everyone else is wrong.
2 Likes
Just adding my voice that I’d love a proper solution to this as well.
2 Likes
this is really a problem, I’m just starting making games professionally, and cleaning navmesh from undesired areas was a nightmare, i spent a week at least solving these “issues”, the only instance where i could find this approach “acceptable” is if you have a giant mountain mesh that’s just 1 big geometry and the game happens inside and outside… even then, an option to make it so navmesh isn’t generated inside blocking geometries is pretty much needed at this point…
as others have said, the workarounds are pretty time consuming and prone to human errors, which usually introduces bugs to no end…
On my use case we have a solid roadblock that can be removed during gameplay, one of the characters has a teleports that check destination viability using the navmesh (doesn’t have navmesh → destination is illegal), so I can’t use navmesh modifiers because we have to allow the AI to traverse where the roadblock was before, and allow the other things we use navigation checks for also work…
this really needs a fix, we already have the “fill collision undearneath for navmesh”, why can’t we have something along those lines for the negative space “fill collision inside for navmesh” or something like that…
I really hope this “issue” get some more attention, even if it’s working as intended, it’s pretty time consuming, error prone process to correct the undesired nav mesh positions, and even then, like in our case, we don’t have a workaround…
EDIT: I realized you can add a “Nav Modifier” component to an actor, and it will fill the actor bounds with that and remove the navmesh from it, although i doubt you can use it to allow surfaces to be “stepable”, so on objects that are obstacles and will have no navigable area, it’s fine to add a Nav modifier component to fix the issue (and a lot easier than doing so manually)
1 Like
so is epic just going to act like this isn’t an issue? read the comments in this thread. everyone here thinks this is a serious issue. it’s 2023 and this still hasn’t been fixed.
I wish if the nav mesh didn’t generate inside static meshes. Such a pain in a runtime procedurally generated world as it isn’t feasible to place nav mesh modifier volumes at runtime.
1 Like
so there is nothing to help with this ?
1 Like
I +1 in May 2023
1 Like
Had run into the same issue with a few of my AI EQS query picking locations inside the mesh and found a video that covered something similar but was able to fix my and seems like a lot of others issues.
Not sure if this is the best/most efficient way of doing this, but it seemed to have worked. Made a quick video showing what I did to fix the Navmesh inside meshes. Hope this helps some people out