In Unreal 5.4/5.5, Add Instance and Remove Instance operation is much slower than in was in 4.27.
Here is the comparison video:
Adding 5 instances per tick to the InstancedStaticMeshComponent, Material is just a PerInstanceRandom.
As you can see, UE5’s ISM is basically unusable after 10000 instances, while UE4 is great at 80000 (even more in packaged builds).
Lumen, VSM, TSR, Nanite are disabled for a fair comparison.
This is recorded in Editor so static performance is much worse in UE5, but this doesn’t affect the rest of the test.
Why is this happening and what can I do to improve UE5 ISM performance?
What’s the speed like after you’ve finished spawning the instances?
Do the cubes have collision on? If so, maybe test with it off.
Also, try spawning more than 5 instances per tick, if you’re batch adding the instances you may find that 5.4/5.5 are faster when spawning a lot.
I’ve been testing instance spawning and can spawn quite a few without a noticeable slowdown - In one test (it re-uses instances as well though) I’ve been able to spawn around 50K instances - that’s on a 4070 though, I’ll be testing on a 1080ti soon.
My guess is that it’s the collision rebuilding the entire instance set each time you add 5.
I’m wanting to explore that too - it seems a lot of the data that was directly accessible in UE4 like the PerInstanceSMData and PerInstanceSMCustomData can no longer be directly messed with, it’s possibly been abstracted for either threading reasons or for caching optimizations - something like that anyway.
Try using AddInstances() with an array of transforms - you should get much better performance (and can use a different thread to build the array if it’s big).
Another potential difference is Lumen/ RT.
Adding objects into the Raytracing BVH also carries CPU overhead much like collisions and slows down spawning large numbers of instances. With UE5 there is a much stronger emphasis on RT features.
Not sure if its relevant to your case specifically, but it’s helped me.
Yeah that works sometimes but still, when you spawn some large amount of instances - like 80k, it causes an unacceptable freeze, which is much longer in UE5 (like 4 times longer).
The same happens if you disable collision during adding instances and then enable it.
So, I guess more investigation is needed here, but in cases such as mine probably the only way is to make a custom collision solution, separate from ISM.
I did some testing and noticed non-instanced static meshes were giving better performance overall than with ISMs. This is probably due to how Nanite auto instances geometry, as I could confirm that tens of thousands of meshes were not increasing poly count or draw calls similar to what an ISM would do.
ISM seems to have degraded in performance with the latest engine versions. The problem appears to be collision calculation, maybe adding instances recalculates the whole ISM’s collision so continually calling AddInstance rebuilds the collision and the larger the ISM gets the more exponentially slow this is. That is what appears to be happening anyway.
When I disable collision on the ISMs it generates meshes very fast as expected. So to speed that up we can generate them with collision disabled at first, then turn collision on all at once afterwards. Still, this causes the game thread to choke and drop to zero FPS for a few seconds.
Also it seems strange because the meshes already have collision in the static asset files, so what’s it actually doing/calculating that takes so long? The collision is already in there, just bring it in!
Other testing with the procedural mesh component (PMC) we find that it has async cooking for collision which works a lot better for spawning lots of meshes with collision. Unfortunately async collision cooking is not available for regular or instanced static meshes.
It really puts a damper on trying to generate levels procedurally at runtime. A modern game engine should not struggle with this so badly, and it is indeed somewhat worrying.
in UE4, PhysX was used for physics. With UE5, Epic changed from PhysX to their own Chaos Physics. Unfortunately, ChaosPhysics is generally still slower and less optimized than PhysX, so that’s likely the reason for why you see this issue with collision performance in ISMCs in UE5.
