Hi!
In general, such a problem.
On the right is a tree created with procedural Foliage.
On the left is a tree in the form of a regular Static Mash.
Both have “block all” in collision, but the tree on the right does not change the NavMesh.
Below is a screenshot with FolageType settings
Does anyone know how to solve this problem? Changing the “Custom Navigable Geometry” setting has no effect.
Hey @FAR747 welcome back, just a couple of questions. In the static mesh component itself (not the foliage component), does it have navigation data attached? As well as is the mesh complex and assigned here? Was the foliage generated at runtime or painted? If I may see the settings for the mesh itself, I can test it on my side.
Update: Upon testing I could replicate on UE5.03 that instanced foliage actors aren’t receiving navmesh. I see a confirmed bug from a bit back and it’s listing as fixed on the bugtracker. (Unreal Engine Issues and Bug Tracker (UE-150147)), so I’ll take a look and see if that has been merged yet.
Update again: It looks like the expected merge of the bugfix is targeted for 5.1, so my best workaround in the meantime (if your scene isn’t massive) is likely to just make a pool and do manual blocking for testing until 5.1 releases, then when it does just delete the whole pool.
Is there any chance to backport a fix to 5.0x builds for those that started development on 5.0x?
If not:
Like Far747 above, we’re using foliage to place trees in our open world environment. Hand placing meshes as a workaround or manually blocking out is a significant undertaking. We can’t do AI testing on our main map at the moment because of this issue.
Hey @M0F0M0J0, welcome back to the forums!
There should be a capability to backport the fix to earlier builds if you’re of the savvy sort. The commit is linked on that bug tracker. If you have Unreal Github access already, you can take a look at it and see if you can implement it and build from the source from whatever version your project used.
The shift from 5.0X to 5.1 is shaping up to be a massive amount of bug fixes in combination with new features. Though no word so far on how clean the transition is going to be, but considering 5.0 was meant to be the first stepping stone into the stable landscape, it shouldn’t be the worst, but we won’t know for sure until it’s closer to release time.
There’s no tentative release date for 5.1 as of yet, and judging by the roadmap there’s tons left to pull off before then so I wouldn’t expect it too soon. I couldn’t even give a good faith estimate as this is a big one.
Sorry for the inconvenience, and I hope this helps!
Bugtracker Link: Unreal Engine Issues and Bug Tracker (UE-150147)
Thank you @SupportiveEntity! We’re just using the release of UE from the installer, however I am pretty familiar with making source changes. I just linked my github account and can see the commits they made. I’ll investigate if this is something we can do.
If you do end up making those changes, (and wouldn’t mind sharing with the community) let me know here when you do and we can post your snippet in the new snippets area to help out anyone else with the same issue. (which as you can see by this thread is a common one) haha. Enjoy the rest of your day!
Hi @FAR747 I’d like to share my workaround until 5.1 gets released.
Turn off ‘Update Navigation Automatically’ in Editor Preferences.
I’m doing a multi sphere trace by channel (my trees have their own trace channel) from the middle of the map large enough to cover all your trees.
Then I place a ‘tree collision’ child actor where the tree is, storing it’s reference in an array. This is going to absooolutely tank your performance but its just temporary.
Then I build all paths on the map. Then I loop over the placed collision components and destroy them. Performance restored.
The tree collider actor just has a capsule roughly the size of the base of a tree with Area Class set to NavArea_Null.
This is working for me for the time being. You’ll just need to remember to do this every time you need to build your nav.
Wandered back here looking for some navarea documentation and saw this updated. Thanks for the workaround! I looked at the changes in github and while at first glance it didn’t appear to be too daunting, I was curious about one of the comments with regards to making vislog unusable. We’re not using vislog at the moment so probably not an issue, but I haven’t had a chance to tackle it. Sidetracked on AI development.
Seems like this hasn’t been fixed in the current 5.1 release. Can anyone confirm?
Hey there @Elcoo! Welcome back to the forums! It looks like the PR that got accepted had ended up causing some issues with the vislogger so it may have been postponed. Here’s a link to the PR itself if you’d ever used source, you might be able to implement it.
https://github.com/EpicGames/UnrealEngine/commit/579c7dd025d04ef6bec01abc18a0efff7e3b9e92
(you can only open that link if you have access to the source)
(if you need it) Unreal Engine on GitHub - Unreal Engine
Yes, looks to be fixed in 5.1. At least for me with procedural foliage.
In 5.1 if I create procedural foliage, I can see them appear correctly in the navmesh, but if I am trying to build a nav mesh over existing foliage meshes, they don’t show up in the navmesh. I ensured that all the underlying meshes have collisions enabled, and that “Custom Navigable Geometry” is set to “Even if Not Collidable”.
I am on 5.1.1. Any ideas why this is not working?
Hey there @MSFT_AirSim! Welcome back to the community! So to understand correctly, ones you had place previously aren’t being registered, but new systems are. Right? Does resimulating the systems help? That will change their positions however.
Hey so I ended up having this issue as well, I’ve just managed to fix it by going into foliage mode & moving one of the single static meshes a few times and it magically fixed itself (much like the weird material bug in unreal engine)
