I have a behaviour in my farming-like game where if the player puts down a patch of soil, I’m using ‘GetInstancesOverlappingBox’ or ‘GetInstancesOverlappingSphere’ to get any surrounding flora to be removed.
In UE4.27 this behaviour worked perfectly, however since updating to 5.0 I’ve noticed this is no longer working after the first plot of soil… e.g…
Player puts down one patch of soil. The flora around this is removed as expected.
Player moves and puts another patch of soil down, the flora is not being removed. Nothing is being returned correctly from the GetInstancesOverlappingBox/Sphere node.
Hmmm, I’m still on 4.26 so I can’t check directly, but see if maybe there is a function in the FoliageHISM actor to rebuild the Foilage HISM cluster data after removing the first batch. Like:
BuildTreeIfOutdated(true, true)
I thought this was called indirectly when removing instances but I’m not positive on that, and things may have changed for 5.0
Thanks for the reply @Countsie , I did a diff between 4.27.1 and 5.0.0 on the HISM cpp, and couldn’t find anything out of the ordinary. Quite a few lines have changed but it looks like the BuildTreeIfOutdated logic has remained untouched. Although I noticed in both versions it was (true, false) instead of (true, true).
Also, if I may ask - is HISM what I should be looking at? As InstancedFoliageActor and FoliageInstancedStaticMeshComponents are the items that are made here.
FoliageInstancedStaticMeshComponent inherits from HISM with hooks for the editor tools and a few other things, most functionality resides there or in it’s parent InstancedStaticMeshComponent.
the params are (async, forceupdate)… async does the rebuild on another thread, forceupdate will rebuild regardless if there is a change or not. I suggested (true, true) to make sure it did rebuild, but in practice you probably dont want to force the re-build.
Honestly, this may be barking up the wrong tree, but it was the first thing that came to mind if the Foliage HISM gets out of sync. You might be right… there may be a bug. I’m assuming the foliage painting/erasing in the editor work fine?
FYI for convenience you can manually rebuild by using the console command: foliage.RebuildFoliageTrees
You could try digging a spot, run the command, then dig another spot. This would at least ensure cluster tree is updated so you can see whether or not that makes a difference.
Thanks for that information about HISM, and explaining the arguments. I switched it over to true just to see if it made any difference, but alas it is still not working.
I also did foliage.RebuildFoliageTrees, but it still isn’t working. Which implies there might be something else going on.
I’ve had a bit of a mess around and now the problem has developed haha.
I repainted some of the foliage in the editor and now it’s not working at all. (yes the editor still seems to work)
However if I increase the size of the Overlapping check, it does seem to retrieve something, but the result seems way off. Foliage gets removed at a large offset away from where I’m digging in the game.
The other thing I’ve noticed is that despite running the removal on all foliage actors (grass_varA, grass_varB, flowers, plants, etc) it only seems to remove the grass type elements.
So yea, seems like something a bit funky is going on…
Huh… make sure you’re passing the info in WorldSpace coordinates and setting the appropriate bool. Otherwise it assumes you are passing the box/sphere in local component space. Odd that your first shovel-load worked fine.
If you have lots going on in your map I would set up a super simple level just to test this issue.
I wonder if something changed 5.0 in how it handles passing in world/component space coords.
For my project 4.27.2 instanced static mesh collisions worked as expected. Converted to 5.0 and collisions detection work , but does not return proper index of the instance hit (or overlapping). Collision detection for instances might be broken or different approach is needed. Couldn’t find anything in the documentation for HISM.
Sounds like exactly the same thing I’ve experienced @Dejan33 , as I explored further I noticed other HISM objects I have behaving oddly when it came to instance retrieval. I reported this as a bug, and in the mean time I will see if anything obvious stands out to me in the source.
I checked the history on the HISM and it looks like between 4.27 and 5.0 there has been some fixes around transformations introduced. I reverted those commits and I now have it working closer to how it was before. Unfortunately I think it’s tangled with some rendering code so now I have foliage disappearing and reappearing based on my camera position, will continue to look into it!
Ok I fixed it for my specific case. I observed the following…
UE5.0 introduced a variable on InstancedFoliage.cpp called bUseTranslatedInstanceSpace - From what I loosely understand, this aims to solve foliage precision in large worlds due to the use of floating points. The logic takes the first instance position and uses that as an origin space for all other foliage to calculate from.
The problem I believe is that this value is used when building the foliage tree, but not taken into consideration in both the GetOverlappingSphereCount or GetOverlappingBoxCount functions.
As for why I was experiencing this only after the first case, I think my foliage still had data stored from UE4.27, then when I removed instances it rebuilt the tree, causing the bug to be introduced. I also noticed that if I painted in the editor, the bug would occur on the first instance too.
So to fix this, as my worlds aren’t very latge - I put bUseTranslatedInstanceSpace to false instead which means the positions would always be based on 0, 0, 0 space. What I then had to do was make small edits to my foliage so the data was regenerated to whatever the UE5 required. I suspect that this might also be fixed if I rework the logic in the overlap functions to use this new variable.
Have the same problem and someone already reported it.
If you want to get it fixed asap you can upvote it here:
or if someone is good at c++, there is always the option to make a pull request. And thanks for sharing your finds at least now I know why it doesn’t work.
I pulled the current main branch and was delighted to see that the bug was gone. (In my testings) I will just have to ignore the newly added graphic glitches.
