When cooking a large number of static mesh we run into the following error:
“Failed to build Nanite from static mesh. See previous line(s) for details.”
This is not happening on the same mesh on each run. We can get a 100% repro when building on our CI system with a large number of meshes. Incremental builds do not fail (smaller number of meshes being cooked).
When looking through the logs a bit deeper, the failure is coming from FBuilderModule::BuildMaterialIndices(). We see the following error:
“Unable to build Nanite data. Unsupported number of sections: 74”.
74 seems to always be the number we see in the logs when the failure happens. In 5.4, MaxSectionArraySize is 64. It seems the issue is happening upstream, and looks like its related to cooking multiple meshes in parallel when a large number of meshes are cooking (in our case over 10000).
We were wondering if there was a fix for this in 5.5 or 5.6 that we could patch in our version of the engine.
Steps to Reproduce
Issue seems to happen when cooking a large number of Nanite static meshes. We see it when doing clean builds without cache / incremental in AWS. It happens 100% at the moment in this case. It does not happen on the systems where we do smaller incremental builds.
Hello, the error “Unable to build Nanite data. Unsupported number of sections: 74” is due to a limitation where you can’t use more than 64 materials in a single Nanite mesh and I haven’t found any fixes in this area in 5.5 or 5.6 that seem related. We have an internal issue to keep the content worker from crashing but it has not been resolved yet. Can you verify if any of the meshes in question have more than 64 materials?
It may also be that there is something DDC key related - for example a refactor caused an issue in UE 5.5 where building a static mesh could change the key causing it to have duplicate render data CL#35571580
Thank you so much for the extra information. We were able to track down the model with the issue.
One thing that would be nice to have on there would be the name of the model/mesh that caused the error. While the name is printed before the error, with multiple processes running in parallel (or multiple threads processing multiple meshes in parallel) it is hard to track down what mesh/model failed to cook. Any suggestions?
Ideally we’d update our error messaging to provide that the mesh/model that failed - but in looking at the code, there are many places where that information would need to be passed in and error messages to be updated, so we may need to update the error message higher up, say in InitNaniteBuildInput(). Another option is the Data Validation Plugin which lets you write custom BluePrint or C++ validators that run on asset save and can as part of your CI.
UnrealEditor-Cmd.exe <PROJECT_NAME>.uproject -run=DataValidationThis is a convenient place to check for issues like these that the engine doesn’t handle gracefully and also allows your artists to be made aware of them on save and address them before they make it to your CI system.