Incremental Cooking leaves materials in a corrupted state when modifying Material Parameter Collection (Crash on runtime)

Development Pipeline & Plugins
, ,
1

Hello,

We are encountering a recurring problem and would like to know if there is any way we can solve it.

We have discovered that when we modify a Material Parameter Collection, subsequent builds with Incremental Cooking crash at runtime with this error:

LowLevelFatalError [File:F:\TeamCity\Agent\work\Project-main\Engine\Source\Runtime\Renderer\Private\ShaderBaseClasses.cpp] [Line: 252] 
Failed to find parameter collection buffer with GUID '6CF61BD145D53669750B6B827C62A0A4' for /Game/Project/Maps/OpenWorld/_Generated_/DXUGXMFP5BKQZMJCN4Q1V72B3.OpenWorld:PersistentLevel.LandscapeStreamingProxy_8VPQCO19F6FN8MQZLDFDBEC0G_510_10_10_0.LandscapeMaterialInstanceConstant_4.
Currently 2 listed default instances: 
0x00000198638772A0: MPC_WorldParameters: 8A2B0E824C1824DA91A3A8909B67BF11
0x00000198F1FEED40: MPC_WaterParameters: 304375D74A5F93B260261A9C8172923E

In the example, only one material is shown, but this happens with many materials. By resaving the parent materials (simply opening the material in the editor and saving it), the following builds will work correctly. So it seems that every time we modify a Material Parameter Collection, the following builds start to crash because there is a difference in the GUIDs in materials that use thatMPC.

If the builds do not have Incremental Cooking, they work correctly and this error does not occur. Is there any way we can fix this and keep Incremental Cooking active (since it’s quite useful because it optimizes build times considerably for us)?

Thanks,

Javi

2

Sorry it took so long to respond on this. I wanted to investigate locally and it took a few weeks to get the time free to do so.

UMaterials that use MaterialParameterCollections auto generate the build dependency on the UMaterialParameterCollection, so that the Material is recooked.

And UMaterialInstanceConstants based on a UMaterial add all of the materials build dependencies to their own, so they should recook as well.

But the object giving the error in your message above is a UMaterialInstanceConstant in a Landscape actor, and those are generated by the Landscape actor during the cook, and so I think they are bypassing the automatic build dependency that we normally add for MaterialInstanceConstants, so we don’t get a build dependency from the Map package that contains the Landscape actor so we don’t recook it and have the stale reference to the old guid of the MaterialParameterCollection.

To confirm that hypothesis, are all of your runtime errors coming from MaterialInstanceConstants inside of a landscape in a map package?

If so, then the fix will modify the c++ code for ALandscapeStreamingProxy (or whatever landscape object exists within the editor version of the map) to add an override of virtual void OnCookEvent, and handle the case CookEvent == UE::cook::ECookEvent::PlatformCookDependencies, and call Context.AddSaveBuildDependency with a cook dependency created through the function FCookDependency::TransitiveBuild, called on the material returned from ALandscapeStreamingProxy::GetLandscapeMaterial().

Can you try out that solution?

3

Hi Matt, thank you for taking the time to give us such a detailed response.

What you say makes perfect sense to me. In fact, the crash only occurs when opening the map we have with Landscape. So your hypothesis is correct.

I’ll try the fix and let you know if it solves the problem.