I’ve been able to make a procedurally generated level using instanced static mesh components (simple blocks). Now I’m trying to allow the player to apply damage to these blocks to blow them up. I know how to do this by creating destructible mesh components, but I can’t figure out how I can use a Destructible Mesh instead of a Static Mesh for procedural generation. Is there some workaround so that I can allow my player to destroy my procedurally generated world?
Thanks!
HI
Yes, you can give each block a “Health” Var. When health = 0. Destroy actor / Mesh. Place a DM there and apply damage to it.
But they would need to be a BP. Give it a go, see how you Frame Rate sits.
Here is a quick example of it I did.
The best way to do destruction for InstancedStaticMeshComponents is to detect when an individual instance has been damaged and then delete individual instances and spawn a destructible actor in its place. That’s possible to do in 4.8 but it’s a bit clunky.
For line traces or point damage, Hit.Item contains the instance index that was hit.
One issue is that in 4.8 radial TakeDamage doesn’t work well with InstancedStaticMeshComponents because it doesn’t calculate the damage amount for each instance based on the falloff but rather treats the entire component as a single .
For 4.9 foliage I made a subclass of HierarchicalInstancedStaticMeshComponent which correctly calculates the damage, and also added some blueprint functions to allow you to find and destroy instances more easily, especially for radial damage.
The first 4.9 preview will be out soon, but the changes are in these commits if you want to have a look sooner:
https://github.com/EpicGames/UnrealEngine/commit/7a7e51a88dd1f0ec472b998d010e42d2a5392812
https://github.com/EpicGames/UnrealEngine/commit/8626c0ad9e757375844bb125544fa1eb5dcd573e
Hey , great to see some improvements for the HISMC! HISMCs are really awesome. but I’m curious whether you will for 4.9 also fix the flickering which occurs when HISMCs get scaled?
They show LOD0 for one frame after being scaled, and it looks really not nice. For me it's like the worst bug UE4 has at the moment. I need to use HISMCs for this because of performance, ISMCs don't have LODs and would decrease my performance extremely with foliage like this and regular Static Meshes would too.Hi ,
I’m sorry that I wasn’t made aware of this and had not been assigned the ticket (UE-16534). It was assigned to the rendering team and had not been passed on to me; it’s actually a foliage issue.
I’ve just taken it back and I’ll see what I can do but there is very little left before 4.9.
Great, thanks so much , you are awesome 
Yes, I do only change scale and in some special cases (tree get’s cut) also rotation, but usually don’t change the location, I don’t have ents in my game And for ents I would need to use skeletal meshes anyway.
I already told you how awesome you are, this bug is annoying me for months now and I already feared it will never be fixed, so awesome that you just look into it now
Hey for your usage case you’re only interested in changing the scale of the instances, not their position, right? I should be able to easily keep the existing LOD when changing only the scale or rotation.
Hi , just checking whether you also spotted the second HISM bug in Alcatraz’s [bug report thread][1].
Specifically this bug -
“In a packaged project the flickering after scaling occurs the same way as in the editor, but there is one more bug: After adding a new instance (or after scaling an existing one) sometimes all instances are flickering for one frame, and I can’t say it for sure but it looks as if the whole HISM would be invisible for one frame , really does not look nice.”
I have noticed the same thing as well in packaged projects. Like I’m also relying heavily on the HISM component for scaling (and thank you so much for making this excellent component!!!) and I’d be grateful if Epic could investigate the flickering issue when adding new instances.
I think the other thread also mentioned a repro project was available; in any case this can be reproduced by dynamically adding instances to a HISM component (eg: in a Tick event) and packaging the project for testing.
Hi VSZ,
The fix was more involved that I was hoping and we missed the 4.9 cutoff, but we do have a solution for the component scaling. We now patch the HISM tree with new bounds for instances that do not move so they retain their previous LOD and there is no LOD flickering at all.
We also now calculate an LOD for newly added instances which is almost always correct, although if it’s at a transition location it will change LODs abruptly rather than with a per-pixel crossfade when the tree does finish building, but it is not really noticeable.
These fixes should be submitted in the next day or so; I’ll post back here when they’re done.
I will investigate the issue with all instances flickering when constantly adding instances in tick only for packaged builds. I think this is a separate problem…
I’m afraid this will have to wait for 4.10 or for you guys to build it yourselves. We generally only issue hotfixes for things broken by the release itself - the testing required for any release is huge and is the limiting factor in our release schedule, so adding other items to 4.9.x will push back 4.10.
Constantly adding instances to an HISMC isn’t that bad. It will have a background thread building the tree most of the so there is that CPU hit. Any additional instance requires the whole tree to be rebuilt, so adding an instance to a 200-instance HISMC will take longer than for a 100-instance but the extra work happens in the background.
I’ll investigate the issue with all instances flickering. We have not seen that for a long but I’m looking at the with packaged build case now.
Hi , great to hear you have found a solution to the LOD flickering bug! So awesome. Could you add the fix in one of the possible hotfixes for 4.9 or will we definitely have to wait for 4.10 (or build it manually)?
The bug with all instances flickering does not only occur if you constantly add instances, one adding or scaling an instance can be enough, at least this is what I wrote above and I can’t really remember what exactly I did back then
Constantly adding instances would need a lot of performance, right? I think once someone from Epic told me that adding or removing instances in a HISMC can be quite expensive, do I remember this correctly? I think adding an instance to a HISMC where already 200 instances are inside is more expensive than adding one instance to a HISMC where only 100 are inside, right?
Hi VSZ,
I haven’t been able to reproduce any flickering with a blueprint adding a new instance every frame, in packaged builds or otherwise. I tested 4.9 with and without the LOD fix mentioned in this thread.
If you can reproduce it in 4.9, please post a new AnswerHub thread about it with a sample project and we’ll take a look.
Thanks
Hi ,
why do you always mention “every frame”? I don’t think it makes any difference here. I just tested it with my project where I scale instances once a second and after packaging sometimes all the instances (so even the ones which don’t get scaled) flicker, and it’s a flickering where I think I can see the landscape below for one frame, so they are invisible.
I converted the project to 4.9 now and I get the exact same problem there. Are you sure you have not tested it both times with the fix applied? I should upload the project now?
Here is a new answerhub thread about it with a repro project:
Hi ,
If you re-read my post, you’ll see I wasn’t addressing you with my request for a new thread, I was addressing VSZ who posted a new issue reporting flickering when adding instances every frame.
Regarding your repro you just posted, this is the LOD flickering in ticket UE-16534 which incidentally we fixed today. I just confirmed your content before/after the fix and it vastly improves the appearance and there is no LOD flickering.
The fix is available on github [here and the two files it concerns, [HierarchicalInstancedStaticMesh.cpp][2] and [HierarchicalInstancedStaticMeshComponent.h][3] are drop-in replacements for the 4.9 versions.
Cheers
https://github.com/EpicGames/UnrealEngine/commit/e4bcaaf03aeffbbf1c60fab9cb01014f63620580
[2]: https://github.com/EpicGames/UnrealEngine/blob/e4bcaaf03aeffbbf1c60fab9cb01014f63620580/Engine/Source/Runtime/Engine/Private/HierarchicalInstancedStaticMesh.cpp
[3]: https://github.com/EpicGames/UnrealEngine/blob/e4bcaaf03aeffbbf1c60fab9cb01014f63620580/Engine/Source/Runtime/Engine/Classes/Components/HierarchicalInstancedStaticMeshComponent.h
The bug VSZ mentioned was posted originally by me, and this is what I uploaded the repro project for. It’s not about the LOD flickering (although it also is apparent in the repro project) but about the flickering of the whole HISMC, so even the instances which did not get modified. The whole HISMC seems to be invisible for one frame. Maybe you should re-read VSZ’s post
He said “this can be reproduced by dynamically adding instances to a HISM component (eg: in a Tick event) and packaging the project for testing”, but he never said anything about “adding instances every frame”. The tick event was just an example. And it also happens on scaling, not only on adding/removing instances.
And thanks a lot for the fix on github
No worries, I understand now. I will reply in the new thread about this.
Thank you so mush JackP for the idea to use Destructible mesh only in place of hit. Works perfect in 4.10.1 with respective replaced instance of its InstancedStaticMesh from a lots of in the level. Thanks man!