Download

What about Auto-Instancing?

Hey guys,
did anyone of you manage to get the static mesh auto-instancing to work, where the same meshes with same materials get batched together, which was introduced with 4.22?

I’ve tried it:

  • by placing them dynamically and manually
  • in both 4.22 & 4.23
  • also switched the lighting modes from stationary to static etc. (according to a reddit post, that fixed it for him)
  • packaged build( on pc: sm5, sm4, and android: open gl 2.0 & 3.1)

And of course tested in a fresh project.

and it did not work, the draw calls weren’t reduced.
“stat scenerendering” always shows the exact same draw calls, so nothing batched.

So I wonder if I need to activate something, do something wrong, “stat scenerendering” is bugged, or the feature was just removed?

Edit://
Seems fixed by using the command r.MeshDrawCommands.DynamicInstancing 1/0 to enable/disable it.

After re-enabling it via this command, it seems to work now.

unfortunately doesnt work with static mesh components, just static mesh actors…

@SQUAREBYTES_GmbH
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?

If I bake them into the level as static then I get my locked 7ms again. Is this an expected disparity?

@stomatogod
, @SQUAREBYTES_GmbH

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…

Edit://

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)
[https://youtu.be/qx1c190aGhs]

**Edit2://

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!**

hey can I add you on discord, I ve got a similar issue and maybe you can help me out.

Thanks!