Issue with importing alembic files: the skeletal mesh asset doesn't contain LOD description

Development Programming & Scripting
, ,
1

Helloo everyone!! :grinning_face_with_smiling_eyes:

We are experiencing an issue with importing skeletal meshes from alembic. For reference, this issue happens in vanilla engine 5.7.4, but it doesn’t occur in versions 5.6.x.

1) After importing an alembic the skeletal mesh asset doesn’t contain LOD description. Just after the import when we want to open/use the asset we have a crash on FSkeletalMeshModelingToolsEditorModeToolkit::OnEditorModeInitialized.

[Image Removed]

The AssetLODModes array is empty.

2) When we save the skeletal mesh asset and then after restart of the editor we want to load the asset it is trying to recover LOD info on the post load step of the asset loading(PostLoadRecoverConvertLODModelsToMeshDescription).

In most cases, it causes memory overflow and crashes the editor. The worst thing is that the recovery process is running without any prompt to the user. We have only a “Waiting for skinned asset to be ready 0/1” task popup and we have no option to skip it or trigger the LOD rebuild manually, after the recovery also looks like the asset is not marked as dirty and the process can be repeated after each restart of the editor.

The problem escalates because any load of the asset (our internal tools, validators or even native Unreal tools) triggers this time and memory consuming process of LOD recovery.

The callstack of time and memory consuming task:

UnrealEditor-SkeletalMeshDescription.dll!TMeshAttributeArrayBase>::Insert(const int Index, const UE::Math::TVector & Default) Line 192 C++ UnrealEditor-SkeletalMeshDescription.dll!TMeshAttributeArraySet>::Insert(const int Index) Line 422 C++ UnrealEditor-Engine.dll!FAttributesSetBase::Insert(const int Index) Line 1769 C++ UnrealEditor-Engine.dll!FMeshElementContainer::Add() Line 82 C++ [Inline Frame] UnrealEditor-Engine.dll!FMeshDescription::CreateVertex() Line 206 C++ UnrealEditor-Engine.dll!FSkeletalMeshLODModel::GetMeshDescription(const USkeletalMesh * InSkeletalMesh, const int InLODIndex, FMeshDescription & OutMeshDescription) Line 1440 C++ UnrealEditor-Engine.dll!USkeletalMesh::PostLoadRecoverConvertLODModelsToMeshDescription() Line 3690 C++ UnrealEditor-Engine.dll!USkeletalMesh::ExecutePostLoadInternal(FSkinnedAssetPostLoadContext & Context) Line 4085 C++

3) Import options mostly default, unchecked Bake Matrix Animation

[Image Removed]

We are currently experimenting with different Alembic export/import options to find a solution. However, we would greatly appreciate any guidance or assistance you can provide us.

Thanks in advance and wishes of a wonderful day!:heart:

Sara

[Attachment Removed]

2

Hey Sara :waving_hand:

Thanks for the detailed report and callstack. It looks like an engine-side regression in 5.7, not a problem with your Alembic settings, so the export/import options you’ve been trying won’t fix it.

In 5.7 skeletal meshes moved their imported source to FMeshDescription. The Alembic-to-Skeletal path in 5.7.4 isn’t authoring that MeshDescription source (it only fills the legacy LODModel), which is why:

- the asset opens with empty AssetLODModes and crashes the modeling toolkit,

- on reload the engine runs PostLoadRecoverConvertLODModelsToMeshDescription to rebuild it and exhausts memory, and

- it repeats every load, since the rebuilt data isn’t persisted and any load re-triggers it.

Two things that would help the report:

1. Does the same Alembic import cleanly as a GeometryCache instead of Skeletal?

2. Roughly what’s the per-frame vertex count and is topology constant or varying?

Workarounds while we wait:

- Keep this pipeline on 5.6.x if you can, it’s the cleanest option.

- If it’s vertex-cached animation and you don’t need a skeleton, use GeometryCache, it avoids the conversion entirely.

- If you need a skeletal asset, import via FBX instead; that path authors the MeshDescription correctly in 5.7.

- Don’t save affected assets, and have your tools skip loading any that already exist, to stop the repeated crashes.

I’m checking with the team if another workaround or a fix is possible. I’ll keep you updated as this moves forward! :folded_hands:

[Attachment Removed]

3

Thanks for the reply, Sara!

The vertex count definitely explains the OOM issue. The team responsible for the Alembic importer has been impacted by recent events, so it may take a bit longer than expected to investigate and address the issue.

I’ll do my best to gather the right people and resources to figure out how we can improve and adjust the importer accordingly.

[Attachment Removed]

4

Hi Sara,

My apologies for the very late answer.

I created a public issue, UE-396815, so you can track its resolution. Note that it may take some time before the link becomes operational.

Thanks for your patience.

Regards,

Jean-Luc

[Attachment Removed]

5

Hiii Stéphane,

Thank you so much for coming to our rescue! :grinning_face_with_smiling_eyes: We really appreciate all the tips!

Answering your questions:

  1. Importing the same Alembic as a Geometry Cache works correctly.
  2. The topology is constant, but we’re not sure about per-frame vertex count. We’ll confirm with the production team of this project and get back to you.

As an temporary workaround, the team has switched to importing these assets as Geometry Cache instead of Skeletal Mesh, which avoids the crash. However, this isn’t a complete solution for our use case, as we ultimately need the assets to be imported as Skeletal Meshes in order to support multiple UV layers, which Geometry Cache currently does not support.

Thanks again for your help!:heart:

Sara

[Attachment Removed]

6

Helloo again!! :grinning_face_with_smiling_eyes:

Just got confirmation that the per-frame vertex count is 657182.

Have a great day!

Sara

[Attachment Removed]

7

Roger that, thank you so much Stéphane! :folded_hands:

[Attachment Removed]