Adding Additional Outfit Slots to the MetaHuman Crowd Collection Pipeline

Development Character & Animation
, ,
1

We are using the MetaHuman Crowd Sample and need to add more outfit slots to its MetaHuman Collection, such as “Gloves”. However, we’re having trouble translating the custom pipeline documentation into a working implementation: https://dev.epicgames.com/documentation/metahuman/metahuman-collections-in-unreal-engine#create-a-custom-pipeline

Is there a more detailed explanation, or could you provide a minimal working example showing how to create and assign a custom pipeline with additional outfit slots, specifically for a crowd pipeline?

Thanks in advance for your help.

Matthias

[Attachment Removed]

2

Hi Matthias,

If all you need to do is to add another wardrobe item, the process should be simpler than having to write the kind of custom pipeline that’s mentioned in the docs.

The collection pipelines support the concept of real slots vs virtual slots. A real slot defines how the processing of the object happens, the inputs, outputs, etc. A virtual slot forwards its selection to a real slot. In the case of the crowd pipeline, the garment slots and the shoes slot are virtual slots that forward to the real outfits slot. So, assuming you don’t require any special processing of your wardrobe item, you should be able to add it by just adding a new virtual slot. To do this you would:

  • Subclass UMetaHumanCrowdPipeline add a virtual slot and add it to the specification in your constructor as follows:
FMetaHumanCharacterPipelineSlot& Slot = Specification->Slots.FindOrAdd(GlovesSlotName);
Slot.TargetSlot = OutfitsSlotName;
Slot.SlotColor = FLinearColor(0.66f, 0.11f, 0.0f);
  • Subclass UMetaHumanCrowdEditorPipeline and specify the types that are supported in the constructor:
FMetaHumanCharacterPipelineSlotEditorData& Slot = Specification->SlotEditorData.FindOrAdd(UMetaHumanCrowdPipeline::GlovesSlotName);
Slot.SupportedPrincipalAssetTypes.Add(UChaosOutfitAsset::StaticClass());
Slot.SupportedPrincipalAssetTypes.Add(USkeletalMesh::StaticClass());

The collection editor should then automatically pick up on the new wardrobe item, as should the processor when you build the collection.

We haven’t done much testing on this, so if you run into problems, then let me know.

Thanks,

Euan

[Attachment Removed]

3

Thanks for the suggested approach. We attempted to implement it using native subclasses, but encountered linker errors with Unreal Engine 5.8.0, CL 55116800, on Windows.

UMetaHumanCrowdPipeline is declared with MinimalAPI. Our derived class compiled successfully, but linking failed because the base constructor and several virtual method implementations are not exported from UnrealEditor-MetaHumanCrowd.dll.

Representative unresolved symbols were:

UMetaHumanCrowdPipeline::UMetaHumanCrowdPipeline()
UMetaHumanCrowdPipeline::SetDefaultEditorPipeline()
UMetaHumanCrowdPipeline::AssembleCollection(...)
UMetaHumanCrowdPipeline::AreSlotSelectionsAllowed(...)
UMetaHumanCrowdPipeline::GetActorClass()

Inspecting the DLL exports showed the generated UClass symbols and explicitly exported static slot names, but not the constructor or virtual implementations required by a subclass.

UMetaHumanCrowdEditorPipeline appears to have the same issue. It is declared without METAHUMANCROWDEDITOR_API or MinimalAPI, and its constructor and implementation symbols are not exported from UnrealEditor-MetaHumanCrowdEditor.dll.

Would both classes need to be exported for the recommended subclass approach to work from a project module? For example, should UMetaHumanCrowdPipeline use METAHUMANCROWD_API and UMetaHumanCrowdEditorPipeline use METAHUMANCROWDEDITOR_API?

There is also a wiring question. UMetaHumanCrowdPipeline::EditorPipeline is private, and SetDefaultEditorPipeline() instantiates the standard editor pipeline using the hardcoded class path /Script/MetaHumanCrowdEditor.MetaHumanCrowdEditorPipeline.

How is the custom editor pipeline subclass intended to be associated with the custom runtime pipeline subclass? Should it be assigned manually to the instanced EditorPipeline property, or should the runtime subclass override the editor pipeline accessors?

As a project-only workaround, we currently add the same runtime and editor slot definitions to the existing collection pipeline specifications when those pipeline objects are constructed. This works, but we would be eager to understand what the intended workflow is.

[Attachment Removed]

4

Hi, thanks for flagging this. It does seem like there are quite a few blockers to extending UMetaHumanCrowdPipeline and UMetaHumanCrowdEditorPipeline. We’ll need to make API changes to these classes to allow them to be extended. Unfortunately, since that involves making public header changes, we won’t be able to include them in the 5.8.2 release so they’ll go into whatever the next major release is.

> How is the custom editor pipeline subclass intended to be associated with the custom runtime pipeline subclass? Should it be assigned manually to the instanced EditorPipeline property, or should the runtime subclass override the editor pipeline accessors?

I would override SetDefaultEditorPipeline to do this however, both EditorPipeline and Specification are private, as you noted, and the getters are const so I think that we should make both of these properties protected instead.

Until those changes are available, the best option is to modify the existing classes as you mentioned unfortunately

[Attachment Removed]