When compiling in Mutable, I’m getting a crash with the error message “Array index out of bounds”. I’ve tried to narrow it down, but at this point it feels pseudo random, and in my case, the crash is specifically triggered by a certain Skeletal Mesh (Causing a near 100% crash rate, but if this SKM is not included, then the crash rate is more sporadic). Sometimes the Mutable editor survives the compilation, but when working on a CO-instance, it seems to always crash upon compilation.
When this SKM doesn’t cause the crash, the shader itself is broken (Almost causing a radial-looking UV coord that tiles infinitely).
I’m most likely to produce the crash when I use SKM parameters (Material parameters works so far fine, from what I’ve seen), and I have the impression that the crash is more likely to happen when I combine SKM parameters together with Macro libraries.
Lastly, I also get a very high likelihood of a crash of I combine the usage of SKM constants and SKM parameters (i e using a body mesh as a constant and clothes as parameters).
A few things I’ve ruled out (but still need to be verified because maybe this only partially solved a bigger issue, but I can’t tell because the crash is caused nonetheless):
Mismatch of amount of UV sets (Whether the reference mesh in the parameter has more or fewer UV sets than the mesh that ends up fed in)
Blend shapes missing / expected
Using deform meshes that are not skinned / have a joint hierarchy that does not match the SKM component reference.
Additional note; I’m also being a bit suspicious at the order of how things are plugged in. Unplugging some Object Groups that are not problematic and only keeping the Object Group that is problematic somehow makes it much more stable.
Can you attach a full crash call stack and log to the case? We’ve addressed a bunch of these recently, and it would be good to confirm that. An array out-of-bounds crash could be related to the content directly, or it could be an internal issue within the Mutable graph. Without a crash log, we can’t really advise you on the issue.
Thanks for the above. I’m still working with the team to determine if we’ve addressed this case or not. There have been many changes to many different parts of Mutable (and skeletal mesh definition data as well), but not in the area you’re looking at, so your fix could be hiding an issue. They’re currently really busy in the bug-fixing phase for 5.8 and won’t be able to look right away. If the above fixes your issue for now, I would roll with it. I’ll let you know more info as soon as I have it.
Here is some portions of the code that looks useful:
[Inline Frame] UnrealEditor-Engine.dll!TArray<FSoftSkinVertex,TSizedDefaultAllocator<32>>::RangeCheck(int) Line 1095 C++
[Inline Frame] UnrealEditor-Engine.dll!TArray<FSoftSkinVertex,TSizedDefaultAllocator<32>>::operator[](int) Line 1173 C++
[Inline Frame] UnrealEditor-Engine.dll!TArray<FSoftSkinVertex,TSizedDefaultAllocator<32>>::operator[](int Index) Line 1186 C++
> UnrealEditor-Engine.dll!FSkeletalMeshLODModel::GetMeshDescription(const USkeletalMesh * InSkeletalMesh, const int InLODIndex, FMeshDescription & OutMeshDescription) Line 1528 C++
UnrealEditor-CustomizableObject.dll!UCustomizableInstancePrivate::RegenerateImportedModels::__l98::<lambda_3>::operator()() Line 7639 C++
[Inline Frame] UnrealEditor-CustomizableObject.dll!Invoke(UCustomizableInstancePrivate::RegenerateImportedModels::__l98::<lambda_3> &) Line 47 C++
UnrealEditor-CustomizableObject.dll!UE::Tasks::Private::TExecutableTaskBase<`UCustomizableInstancePrivate::RegenerateImportedModels'::`98'::<lambda_3>,void,void>::ExecuteTask() Line 898 C++
UnrealEditor-CustomizableObject.dll!UE::Tasks::Private::FTaskBase::TryExecuteTask() Line 518 C++
[Inline Frame] UnrealEditor-CustomizableObject.dll!UE::Tasks::Private::FTaskBase::Init::__l2::<lambda_1>::operator()() Line 180 C++
[Inline Frame] UnrealEditor-CustomizableObject.dll!LowLevelTasks::FTask::Init::__l13::<lambda_1>::operator()(const bool) Line 499 C++
[Inline Frame] UnrealEditor-CustomizableObject.dll!Invoke(LowLevelTasks::FTask::Init::__l13::<lambda_1> &) Line 47 C++
[Inline Frame] UnrealEditor-CustomizableObject.dll!LowLevelTasks::TTaskDelegate<LowLevelTasks::FTask * __cdecl(bool),48>::TTaskDelegateImpl<`LowLevelTasks::FTask::Init<`UE::Tasks::Private::FTaskBase::Init'::`2'::<lambda_1>>'::`13'::<lambda_1>,0>::Call(void *) Line 162 C++
UnrealEditor-CustomizableObject.dll!LowLevelTasks::TTaskDelegate<LowLevelTasks::FTask * __cdecl(bool),48>::TTaskDelegateImpl<`LowLevelTasks::FTask::Init<`UE::Tasks::Private::FTaskBase::Init'::`2'::<lambda_1>>'::`13'::<lambda_1>,0>::CallAndMove(LowLevelTasks::TTaskDelegate<LowLevelTasks::FTask * __cdecl(bool),48> & Destination, void * InlineData, unsigned int DestInlineSize, bool <Params_0>) Line 171 C++
[External Code]
Section.BaseVertexIndex 67876 const unsigned int
SourceVertexIndex 2340 const int
This looks suspect:
VertexIndexBase 385782 const int
Corner 0 int
IndexBuffer...
[385779] 67875 unsigned int
[385780] 67862 unsigned int
[385781] 67874 unsigned int
[385782] 2340 unsigned int
[385783] 2341 unsigned int
We found that it could be due to IndexBufferFormat mismatch where if 1st mesh uses 32bit format and 2nd one 16bit there is a path where IndexBufferFormat is “None” causing silent truncation hence the jump 67874 -> 2340.
Adding this in OpMeshMerge before the format switch, fixed the issue, but not sure if this just hides some other real issue instead.
