In our code we have an actor component associated with a custom `FPrimitiveSceneProxy`. The `FPrimitiveSceneProxy` has in its constructor an asset load (to be able to work out what size boxes it wants to draw). As part of this asset load, some Niagara systems are loaded (must be referenced somewhere). Loading these Niagara systems causes `UNiagaraRendererProperties::UpdateMaterialParametersMIC` to be called. This means that when we try to load our actor component, a chain of events occurs which ends up trying to assign a `FPrimitiveSceneProxy` to our actor component twice.
I’ve attached a pair of callstacks (indented bit happens first before popping back out) so you can see more clearly what I’m trying to communicate.
Anyway, we have resolved this issue by modifying `UNiagaraRendererProperties::UpdateMaterialParametersMIC` to change from
...
MIC->UpdateStaticPermutation(MaterialParameterSet);
...
to
...
FMaterialUpdateContext materialUpdateContext(FMaterialUpdateContext::EOptions::SyncWithRenderingThread);
MIC->UpdateStaticPermutation(MaterialParameterSet, &materialUpdateContext);
...
This doesn’t seem to have any bad effects from what we can see but wanted to ask you in case you spot something that will bite us in future. We have verified that we can also resolve this issue by changing the way that we get the information for custom `FPrimitiveSceneProxy` (load a much smaller asset which doesn’t have any references to other objects other than exactly what we need) so definitely won’t be upset if you point out anything blocking our divergence.
[Attachment Removed]