How to Avoid Stutter When Spawning A Lot of Objects?

Hello!

In my scene I have a big empty terrain. With a tick event and some transform calculations I spawn Hierarchical Instanced Static Meshes onto the terrain (grass in example below). Because of the size of the terrain I couldn’t make all objects appear at once, the loading time would be way too long! Instead, each time you come close a new region, the procedural generation kicks in and the objects are being spawned each frame while the game is running. When you eventually get to that place, all objects should have been spawned already.

However I have noticed that after a few thousand spawns the whole process begins to slack and eventually when the object count is above 100,000 the frame rate drops significantly and beyond that it will start to stutter heavily.

[See Picture]

As soon as I stop spawning objects the frame rate goes back to normal but when I start it again, probably because so many instances have been added to the scene already, the frame rate goes down the drain again.

How can I avoid these stutters? As you can see in the picture, large parts of the terrain are not even reached with my current spawn setup and already I have these stutters… What I need is a way to make every spawn last as long as the other without any stutters or frame rate drains at all. How can I reach that even beyond 100,000 instances… is it even possible?

I hope someone can help me out, I’d appreciate some insight, thanks a lot!

Have you looked into level streaming? I have not worked with it that much, but it is designed to break up large levels, into smaller, more managable chunks. I mean let’s face if, 100,000 of anything is a lot of something, when your considering that there is the potential to have to look at each object (and it’s not like the system is only composed of the objects your creating) in order to draw the frame, and then a person wants that done, 30 to 60 times a second.

There is also LODs that can be done, to reduce the load, for drawing when seeing something from a distance. But I would highly suggest that you don’t need to have 100,000 ISMs, that the average screen size (1920x1080), cannot actually even display 100,000 decent sized objects ( 1920x1080 is a little over 2 million pixels, divided by your 100K, leaves you at 20 pixels per object, not very large objects to be sure.)

I would also suggest, on spawning, immediately around the player, as the player moves, things of this nature.

.

I’m assuming from your explanation that you’re putting all of these into one HISMC (Hierarchical Instanced Static Mesh Component)? If so then yes as you add more it slows down as it has to rebuild a bunch of structures internally. You will probably want to do some combination of breaking up the HISMC into several different HISMCs as to reduce add/remove cost, also look into the foliage system as that’s what it was designed for. and like jayice said, 100,000 sounds quite high, you probably don’t need anywhere near that many loaded at once.

It’s not a solution to your problem, rather an alternative: did you try the foliage system?

thanks, for your insight about the HISM component, check out my answer, I was able to solve the problem with your hint!

Alright, I have found a way to increase the object count and still avoid stutters… at least to a point. If you have just way too many objects close by it will naturally slow down the game.

In my ProceduralBP I’ve set the object limit to 50,000, then a branch will return false and no more instanced are added. Outside of that I’ve created a new SpawnBP which actually spawns the ProceduralBP into the scene using SpawnActorFromClass.

When the ProceduralBP reaches 50,000 and stops working the SpawnBP will just again call the SpawnActorFromClass node which spawns a new ProceduralBP into the scene with all new HISM components.

After that you can add as many HISM’s with LOD’s as you want, the spawning times will be equally long each time, that is if you don’t overload the scene with too many objects itself.

I hope will help some one else too!
Thanks a lot for the contribution!