'Add Instance' of Instanced Static Mesh - not efficient?

Let’s say that we want to add 10000 instances to the Instanced Static Mesh Component. The only way we can do it for now is the ‘Add Instance’ or ‘Add Instance World Space’. If I’m understanding it correctly, after every ‘Add Instance’ call it needs to redraw whole instanced mesh… ? That would result in 10k redraws. If that’s true, then something like ‘Update Mesh’ bool input pin would be really helpful - this way we could add 9999 instances without updating, and then re-draw it only once, when adding the last one.
There is the ‘Mark Render State Dirty’ input in the ‘Update Instance Transform’ function, so when updating 10k instances we check this only for the last instance - but there’s nothing like that for *adding * instances.
Am I understanding it correctly?

PS. If I add more than 1 tag to the thread it throws ‘404 not found’ when I click ‘Submit New Thread’.

Hello Slavq.
Did you resolved this?

As far as I know, it’s still not possible to add many instances at once, without re-drawing a whole instanced mesh for every ‘Add Instance’ call. A new function ‘Add Instances’ with array of transforms in input would solve this.

Something like that would be useful e.g. for procedural generation, but I’m still not sure how much of a difference it would make.

You are not understanding it correctly, it isn’t “redrawing” anything after you add an instance. Adding instances happens on the game thread, and all “drawing” happens on the render thread after the game thread finished working on the frame, and since these are instances they are directly handled on the GPU. So if you add 10000 instances in one frame then there’s no issue with it, apart from that adding instances itself has a cost and doing it 10000 times will probably be quite expensive, but that has nothing to do with redrawing.

Ok, but why if I use AddInstance in blueprint it works fast, but with c++ implementation it really slow?

Here is example of how it works in editor with in OnConstruction function.
Almost the same with PostEditChangeProperty. It takes few seconds to regenerate ~100 instances.

1st is BP, 2nd is C++.

I already tried to nativize that BP and check it’s code but there is nothing special.
One difference is after nativization BP uses do-while loop to add instances. In c++ I use for loop.

Thanks, now I get it! The problem appeared when altering only one instance of a big ISM component:
… But it’s good to know that adding them all in one loop wouldn’t cause issues.

Did you ever find a solution to that issue?
I’m currently trying to move a grid system to C++ and I am super confused at how laggy instances in C++ seem to be compared to blueprints.


Nevermind, i found the solution here. I used it for my UPaperGroupedSpriteComponent and it worked perfectly.

There is a relatively new node Batch Update Instance Transforms - it would be nice to have something like a ‘Batch Add Instances’ too. For now we still need to call Add Instance in a loop one by one when adding large amount of instances.

That seems to hang the game for a few minutes upwards of 10k instances.

Have not had time myself just yet, but I would suggest again that you all have a look at the level loading procedure.

Obviously the foliage is getting created, instanced, and loaded.
since the loading process is generally less then a second it must implement some different way to generate the instances from their data… this could prove useful for c++.

I haven’t benchmarked it, but I assume calling “PreAllocateInstancesMemory” before adding them makes it much faster

Yes, this is totally true.
If you call that first with teh amount you are adding, you can even use BatchUpdateInstancesTransforms,

            int32 InstCount = StarTransforms*.Num();
            Comp->BatchUpdateInstancesTransforms(0, StarTransforms*, true, true);