Hi Everynone, and thanks for your detailed suggestion!
Couple things on that one:
- You’re assuming wrong
. I am using parenting between actors. As in, I have that structure in my level outliner.
- I can try with some extended Static Mesh Components… But why would they be lighter than an actor?
Actually, I just did a test… a big “For Loop” creating hundreds for static mesh components, and disabling collision. Seems not to work. Here’s a test with 10K moving meshes (each of the 10 cubes has physics enabled, and 1000 nanite static mesh components without collision attached). Notice in particular the game thread timings and the unitgraph indicating that the editor was happily at 60FPS until I hit Alt+S.
I’ve also had a brief look at the instancing idea… but the bottleneck really seems in my mind to be the transform computation on the CPU. I could be wrong, but I’ve always thought of instancing as a great tool to reduce draw calls. In my case, I’m not over-budget on draw calls, otherwise, I wouldn’t be at 60+ FPS when nothing moves.
(plus I think unreal has auto-instancing, and I only use nanite which is rendered in a single big call.)
So, unfortunately, despite the great detail in your answer, I don’t think yet that switching to components or instancing will really improve performance. I do appreciate your suggestion though, and feel free to tell me if I misunderstood it.
EDIT: I really thought about the Niagara idea… so I did a new test.
This is 120K meshes (!) falling towards the ground at 60+FPS. You can see the GPU time reaching the 16.7ms budget however.
Here it looks like the CPU knows nothing of the GPU mesh particles. It seems that since it’s all GPU computed, rasterization capacity is the only limitation since the CPU never has to update the mesh transforms went the parent gets moved. In that regard, it seems even better than instantiated static mesh components.