Recommended approach for runtime-switchable held objects on MetaHuman Crowd ISKM instances

Development Character & Animation
, ,
1

What is Epic’s recommended approach for attaching and runtime-switching held objects on individual MetaHuman Crowd ISKM instances?

Should tools use skeletal-mesh proxies animated alongside the character, SetInstanceBoneAttachment, separately updated static ISM instances, or another intended workflow?

The solution should support many item types, ideally without custom manual setup per item.

Best regards,

Matthias

[Attachment Removed]

2

Steps to Reproduce

  1. Create a MetaHuman Crowd using Mass and UInstancedSkinnedMeshComponent.
  2. Add static-mesh tools with an Equip socket.
  3. Attempt to attach each tool to the crowd character’s animated hand_r bone.
  4. Equip, unequip, or switch tools at runtime.
    [Attachment Removed]
3

Hi Matthias,

Could you give a bit more context of the kinds of objects you have in mind?

For accessories that are part of the character, like spectacles, even a briefcase, I’d probably have them as part of the Collection. For a use case like picking a book up off a table, you don’t need 100s of them, so I’d be thinking about leaving the book as its own actor and trying to animate it in sync with the ISKM, rather than making it an ISKM/ISM itself.

Let me know what you have in mind and I can advise further.

Henry

[Attachment Removed]

4

Of course:

They are supposed to carry tools, for example an axe for chopping trees, or a hammer for construction work.

Also, they need to carry items from A to B, for example a log on their shoulders, or a crate - ideally with varying content such as wood, iron ingots etc.

If the varying crate content isn’t possible, there might be a compromise like showing an empty crate for low res instances and do the full display only on high res actors, but we want to get as much out of the ISKMs as possible. Ideally, on “lower end” hardware, we only want to use high res actors for dialogue.

Important is that they can swap held objects during rutime.

[Attachment Removed]

5

OK, that makes sense. I think SetInstanceBoneAttachment on the ISKM component is probably the best tool for this job, so that the carryable objects would be animated by the character they’re attached to and you don’t have to set up animations for them or add them to the Collection.

You would want to set up some Mass code to manage this, as all the data you need is in Mass, so trying to manage the carryables from outside Mass would be really clunky.

I had Claude write up a plan for how to achieve this, and it looks like it would work.

Here’s the plan Claude gave me:

Phase 1 — Carryable as an ISKM

Stand up a system that owns one ISKM component per unique carryable mesh and hands out instances. Mirror how

UMetaHumanMassRepresentationSubsystem already manages body ISKMs. A carryable instance is created via the ISKM’s AddInstance, then bound with SetInstanceBoneAttachment.

Phase 2 — Mass data model

Add fragments that record intent and binding state.

Phase 3 — StateTree tasks that set intent

When the character should pick up an item, StateTree flips a “wants to carry X” desire on the entity. It doesn’t touch the ISKMs directly.

Phase 4 — A reconciler processor

One Mass processor reads desired-vs-actual carry state per entity, resolves the entity’s Top Garment ISKM component (which owns the hand bones) and ParentInstanceId, and calls SetInstanceBoneAttachment/ClearInstanceBoneAttachment.

This is the only place that touches the attachment API — same pattern as the existing MetaHumanMassUpdateCustomDataProcessor.

Phase 5 — Lifecycle & pooling

Handle entity despawn / LOD-out (release the carryable instance, clear binding).

Hopefully this helps to get you started.

Henry

[Attachment Removed]