As far as I’ve tested it, it does work with every Static mesh created dynamically or placed in Editor (Static Mesh actors just have StaticMesh components inside of them).
The dynamic instancing just doesn’t really reduce the “mesh calls” (stat SceneRendering), but instead the draw primitive calls (stat RHI).
I think that’s the limitation of this, and ISMC and HISMC do still have less perfomance cost.
But I could swear, as it came out in version 4.22 the mesh calls count dropped drastically with dynamic instancing enabled, and later with an update (somewhere after 4.22.1 or even later) it rose again and never changed the mesh calls since them.
I think maybe there was a issue in code that the wrong stat profiler macro was used and in the end was wrongly displayed, but that’s just my speculation.
It just works? I am bottlenecked at 20ms due to draw calls with 350 spheres on screen at one time, otherwise I get a locked 7ms draw. Can I not just drag static mesh actors into the level and have them auto instance?
Wow I was fooled by myself, tried it again with static mesh components, an it didn’t instance it. My testcode was unintentional using static mesh actors instead of comps… messed that up
Well nevertheless that must be a bug that static mesh components don’t work, or just not implemented yet…
But if it’s (and stays) by design that only static mesh actors are batched, that would be a real bummer…
I’ve watched epics tech talk about the new mesh drawing pipeline (4.22+)
and about ~36min in comes the explaination the new draw merging with “static mesh components”
So it must be a bug, that it doesn’t work with the tested comps (my comps didn’t break any of the named rules there)
Tested it now again with Static mesh comps (this time as BP class because it’s faster to setup)
It does work as expected! Added 40 static mesh comps to an actor in runtime, all the same meshes but with random primitive data for different colors (all have the same material instance constant applied)
Aaand not 40+ mesh draw calls, but 7!**