UpdateInstancedClusters consuming a lot of CPU time because of a lot of models, even when aprented to nil

[WoloPoints (ArthurWellesley)]

My game is Conquest 2, a RTS game; when we first made a grand event with a lot of people spawning their units, the lag was especially big, when I checked the micro profiler, it resulted that the main cause of it was “updateInstancedClusters2”.

Now, I would kind of understand as “a lot of parts make instanced clusters have problem”, though I would really want to know why this is so inefficient. Anyways, the main problem is that even when round ended and the models got cached (my game does not destroy the models, it sets their parent to nil and cache them to be reused) updateInstancedClusters was still consuming a lot of CPU time, even when the units models were not actually parented to workspace.

System info:
Windows 11
Ryzen 7520U
Integrated graphics card (Radeon 610M)
8GB RAM GDDR5
SSD 512GB

Expected behavior

I would expect it that, even if updateInstancedClusters taking a lot of time is normal because of the amount of units, it should at least not require that many resources when the units are cached / parented to nil. If possible i would like an explanaiton about why updateInstancedClusters is too high

A private message is associated with this bug report

[Mmm_Wafflez (Sammy)]

Do your models have a lot of individual parts? If so, this might answer your problem:

ClusterUpdate and adornees are badly optimized

Hello, I have done a preliminary investigation. Very nice test case for benchmarking btw! So Adorns are really slow, they are not meant to be used in the way they are used in the test case. The mesh parts, I expected it to be a little costly while adding parts, due to the way that works internally. But I was surprised to see the cost continues after stopping the benchmark. I debugged this a bit and I will have to continue debugging it tomorrow or so, it seems to think the parts are dynamic, wh…

Unfortunately, it doesn’t look like adornees are optimized to deal with tons of parts and doesn’t get any cheaper efficiency wise when caching these models. Personally, I would try to find a different method to optimize part counts if this is the case like using custom meshes or unions.

[WoloPoints (ArthurWellesley)]

Interesting. My game units models are made of 2 meshparts only, but I use 6-7 parts to emit particles when attacking. (My game is based on the napoleonic era, and units are blocks of 12 men packed together)

Would attachments be a more performant alternative for the particle emitters, in order to reduce the time of updating instanced clusters

[ItzAidfoplays390]

@TigerRabbit2

Multicrew Tank Combat 4 - bad frame drops due to moving a lot of instanced clusters (see the updateInstancedClusters marker in microprofile)… this is something that we’ve been wanting to fix for a long time, it is basically a problem with the way the content is authored… each tank contains many many small pieces and it all moves at once… this does not play well with our caching system. This type of issue happens on a very small subset of games, so it isn’t the highest priority for us to fix (though we’ve had it on the plan for multiple years now)

Another related comment. I doubt this caching issue is fixed though…

[WoloPoints (ArthurWellesley)]

It is indeed really annoying; my game could support a lot more if it was not because of this issue.

[ItzAidfoplays390]

Last time I talked to the engineer, he said it wasn’t a high priority issue for them to fix, since it doesn’t affect a lot of games even though they wanted to fix it years ago. However, he also said that making a bug report can get it fixed faster and easier so.