So, another update to my investigations. I was doing a some work on a separate branch of my project, and I ran into the crash again, this time being caused by one of the materials from the engine (the VivePreControllerMaterial material, on the Vive controller model). So, I added some more logging to the function that was crashing, (FClusterReferenceProcessor::AddObjectToCluster), and I know a bit more about where the crash is coming from.
My understanding of the crash is this: it appears that two materials, material a, and material b are interacting. When it crashes, a texture from the material a, is included in a “group” (package?) with material b’s textures, so when Unreal tries to add material b’s textures to the cluster, it also tries to add that texture, and it’s outer, which is material a. Since material a isn’t the root of this group (material b is), it isn’t skipped, but since it has a flag marking it as a root, it triggers an assertion.
When I only have one material (i.e. in my test cases above, and in this VivePreControllerMaterial case), material b was “staticDecalMaterial”, which was applied to a static mesh referenced by an actor-class that mainBP had a reference variable for (hence why it only crashed when mainBP was in the level), and I fixed it by changing the material on the mesh to none (since that’s what it should have been anyways). But, in my initial use case, I’ve added two new materials, and they’re causing it with each other, so I can’t just remove one.
More digging shall follow!
and I’ve attached the log from the crash with my two materials, complete with the new logs added to FClusterReferenceProcessor::AddObjectToCluster