So I’m currently working on a game where you clean a planet of trash, one of the ideas i had was to make it on scale that I’ve never seen before in terms of visual mass. so basically hundreds of thousands to a million trash items visible.
I’ve been working on a system that will allow me to spawn and run all these items in a way where the player actually gets a good FPS. My question is: “Is the way I’ve done it so far actually viable?”.
The part I’m worried about is this:
-The world is split into 2500,2500 chunks, each chunk on spawn takes data from prefabs i make and spawns them all in as Hierarchal instanced static meshes.
-If the player is in the chunk it converts them to my custom Static mesh components where I’ve disabled physics and overlap calls etc.
I’ve created a points system where based on factors such as distance and visibility (Couple other things too) each trash comp in the chunk your in will get given points. based on these points the top 100 are given physics activation. this makes it seem like they all do when in reality just those 100 do.
If there’s any other details you would like to know i can explain but currently when i run this is editor it works fine (when all HISM i get over 100FPS and when i have 40k static mesh comps it around 90FPS) but this is my first game so im worried there could be something im missing or a much easier way.
Your approach (HISM everywhere, promote to real components only near the player, physics budget of ~100) is essentially the standard “simulation LOD” pattern, so yes, it’s viable. Things I’d watch:
Conversion cost. Creating/destroying thousands of UStaticMeshComponents when you enter a chunk will hitch. Pool them, or spread the conversion over several frames (a few hundred per tick). Even cheaper: keep everything as instances and only spawn a physics actor for the top-N items, then write the final transform back into the instance when it goes to sleep.
HISM updates. Adding/removing instances triggers tree rebuilds. Batch changes (e.g. BatchUpdateInstancesTransforms, or UpdateInstanceTransform with MarkRenderStateDirty only on the last call).
Measure in a packaged Development build with stat unit, stat gpu and Unreal Insights — editor FPS with 40k components can be misleading; the render thread / draw calls are usually the first wall.
Nanite trash meshes + instancing keep the GPU cost low; for a million items also make sure far chunks aren’t loaded at all (World Partition streaming or runtime PCG generation).
If you later need behaviour per item, Mass Entity with ISM representation is built for this, but you don’t need it to ship the current design.
look into the dehydration/hydration tech the engine is working towards. The Saturn/Cassini(?) sample project is a practical example of this.
It’s mean to drive things like asteroid fields, or object-rich/dense scenes where you only have to see a thing, have it be there, beyond a certain range (dehydrated to a simpler/simple-thing) and only interact with it up close (hydrated to it’s full-level-coded-thing).
