Non-Deterministic cook result of NiagaraDataInterface instances in MultiProcess Cooking

Development Pipeline & Plugins
, ,
1

We found that when we use multiprocess cook, the NiagaraDataInterface property would have non-deterministic Cook result if the outer BlueprintClass is inherited from another BlueprintClass.

​

Let’s consider the following BlueprintClass and it’s NSComponent containing a NiagaraDataInterface property.

[Image Removed]

The cook result of B_BP_C is different whether the A_BP_C is cooked in the same cook worker. I dived into the cook process and find that this is because of the new NiagaraDataInterface instance generated in the cook process.

void UNiagaraComponent::CopyParametersFromAsset(bool bResetExistingOverrideParameters)
{	
        // DataInterfaces are unique per component so we need to make new instances if they are not already
	for (int32 i = 0; i < AssetExposedParameters.GetDataInterfaces().Num(); ++i)
	{
		UNiagaraDataInterface* AssetDataInterface = AssetExposedParameters.GetDataInterface(i);
		UNiagaraDataInterface* OverrideDataInterface = OverrideParameters.GetDataInterface(i);
		if (AssetDataInterface != OverrideDataInterface)
		{
			// We must copy the data regardless as there is an expectation that data interfaces are always reset to the original state
			AssetDataInterface->CopyTo(OverrideDataInterface);
		}
		else if(AssetDataInterface)
		{
			OverrideDataInterface = NewObject<UNiagaraDataInterface>(this, AssetDataInterface->GetClass(), NAME_None, RF_Transactional | RF_Public);
			AssetDataInterface->CopyTo(OverrideDataInterface);
			OverrideParameters.SetDataInterface(OverrideDataInterface, i);
		}
	}
}

Consider the two senarios when cooking WaterMesh in B_BP_C.

  1. WHen the A_BP_C is cooked in the same worker. The A_BP_C is generated the new waterMesh called waterMesh_1. When the generated waterMesh_1 of B_BP_C is serialized for cook, it compares to the archetype which is the waterMesh_1 of A_BP_C having loaded and the values are the same.
  2. When the A_BP_C is cooked in another cook worker, the DiffObject of the generated waterMesh instance (we called waterMesh_1) is the CDO, because the A_BP_C didn’t generate a new object called waterMesh_1, which leads the DefaultMesh to be compared is NULL.

​

My Questions are:

  1. Why the NiagaraDataInterface instances need to be genrated dynamically when cooking. The A_BP_C and B_BP_C should be deterministic after they are edited and saved. Why not just serialized the NiagaraDataInterface instances to the disk?
  2. Given the current situation, is there anyway to workaround this non-deterministic issue?
2

Hi,

I’m currently working on a change in this area that is currently going through a series of tests.

It uses deterministic names for template / instance / override data interfaces based on the parameter name.

This won’t land in 5.7 unfortunately as it’s too late in the day / risky, but should hopefully be in 5.8 providing I don’t run into any unexpected roadblocks

The current change has fixed a pretty long standing bug where you could expose two DIs of the same type (i.e. two curves), add the system into a BP modify the DI properties, place instance in world, modify the properties, then delete a DI from the original system and the data would be lost on the placed instances.

Perhaps we could avoid generate them during cooking, but this code is all pretty gnarly / error prone, so as much I would like to not generate UObjects / throw them away it will likely remain this way for the near future. Longer term we would like to move away from using UObjects for data interfaces and move to a UStructs instead, this is along the lines of the UObject being the editor data and the UStruct being the runtime data.

I’ve taken note of this ticket and will send the CL once it’s in, I don’t see a reason why it can’t be backported, but 5.3 is pretty old at this point, I don’t recall if the variant cache was in which fixed dragging in unused data interfaces into the cook.

Thanks,

Stu

3

Hi Stu,

Thank you for this detailed reply. Could you please provide the CL in which the variant cache thing be fixed? We can check if that is the problem.

Thanks,

Xiuxuan

4

Hey Xiuxuan,

I’ll pass the CL on once it’s in, I ran into a few issues without customization for blueprint around undo/redo. Otherwise it was passing the cook at least.

Thanks,

Stu