Here’s a simple comparison of 2222 spheres, one scene as instances of Instanced Static Mesh, second scene as blueprint actors with Static Mesh Component: https://i.imgur.com/3UVYQh0.png
Auto Instancing is turned on (checked the console command and changed the directional light Mobility, as there’s still a bug where auto instancing doesn’t work before we change light mobility).
~1.2ms with ISM vs **~5.3ms **with static mesh components with auto instancing.
It seems that for scene optimization, we still need to use the ISM or HISM. For example, for an in game building systems. That’s always quite cumbersome, since we need to operate on the instanced component and switch instances to blueprint actors counterparts when needed, and back, instead of just having a ready-to-use actors.
I wonder what’s the best use case scenario for auto instancing…? I guess that it is really useful in cases where we can’t use ISM or HISM for some reasons…? For example, for many mesh actors with active physics simulation?
When I first heard about auto instancing, I was hoping to e.g. be able to use blueprint actors for each building system placeable part, since that would be much easier - but it looks like we still need to use created/detected ISM or HISM component with the same mesh and add meshes as instances.
Well, at least it helps with moving/physics objects so that’s good
I’d like to revive this post, since today I’ve found that dynamic instancing doesn’t really merge the draw calls when doing the shadow depths pass.
I’ve tried with Unreal 4.25.1 creating a scene with 10 spheres (tried both with actors and static meshes), and then I have compared this with 10 cones spawned using an ISM.
As shown you in my post above, I get the same results from auto instancing and ISM only at the moment I disable shadows. Otherwise, the auto instancing will not merge the calls of the shadow depths, but ISM does.
