UE Mutable 换装系统（二）：角色资源规划与 Mutable 对象拆分

总览

第一篇解决系统边界，本篇解决资源边界。换装系统能不能长期维护，很大程度取决于第二篇这些决定：角色基准模型怎么定，Mutable 图暴露哪些参数，服装按什么 Slot 拆，身体如何裁剪，材质通道怎么统一，Groom、Cloth、Morph 和动画由谁负责。

很多项目卡在这里，不是因为 Mutable 不能用，而是因为一开始把所有衣服、身体、头发、材质和特殊部件塞进一张大图里，后面每次加装备都在拆旧逻辑。本篇目标是先把资源合同定清楚。

本篇目标

1. 定义角色基准资源：骨架、基础身体、体型、LOD、材质槽和动画约束。
2. 规划 Mutable 主对象、子对象、参数组和 Slot 拆分方式。
3. 建立参数命名规范，让蓝图和数据资产能稳定写入参数。
4. 设计身体裁剪、遮挡区域和服装互斥关系。
5. 明确哪些内容由 Mutable 生成，哪些内容留给 UE 原生系统处理。
6. 给出资源校验和验收标准，避免打包后才发现资产断链。

非目标

1. 本篇不讲每个 Mutable 节点怎么连线，只讲系统级资源规划。
2. 本篇不讨论装备数据表字段，数据合同在第三篇展开。
3. 本篇不实现换装蓝图流程，运行时流程在第四篇展开。
4. 本篇不要求所有项目都拆成完全一样的目录，而是给出可维护的边界。

角色基准模型

换装系统必须先有一个“稳定角色基准”。所有装备都要对齐它，而不是每套衣服各自带一套假身体。

推荐先按角色族群建立基准：

/Game/Characters/Human
  /Base
    SK_Human_Base
    SKEL_Human
    PHYS_Human
    MI_Body_Base
  /Mutable
    CO_Human_Appearance
    COI_Human_Default
  /Outfit
    /Upper
    /Lower
    /Shoes
    /Head
    /Hair
    /Accessory

CO_Human_Appearance 是 Mutable 主对象，不应该让 UI 或存档直接引用它内部选项。外部只认 ItemID 和数据合同。

Mutable 对象拆分

生产项目里有两种常见拆法：

推荐结构：

CO_Human_Appearance
  Body
    BodyType
    SkinTone
    BodyRegionMask
  Head
    Face
    Hair
    Helmet
  Outfit
    Upper
    Lower
    Shoes
    Hands
    Back
  Materials
    PrimaryColor
    SecondaryColor
    Pattern
    DirtWear
  Attachments
    WeaponVisual
    Accessory

Mutable 图里可以复杂，但对外暴露参数必须稳定。比如外部只写 Slot_Upper = Jacket_A，不要让蓝图知道图里到底用了几个 Mesh Switch、Image Projector 或 Material Layer。

Slot 规划

Slot 是三件事的交叉点：UI 分类、状态存储、Mutable 参数。建议第一版采用小而稳定的 Slot 集合：

不要让“空”成为未定义状态。没有帽子也应该是一件 eq_head_none，它可以把 Slot_Head 写成 None，并确保相关裁剪和隐藏参数回到默认值。

参数命名规范

Mutable 参数是数据层和表现层的合同。命名要有语义、类型和稳定性。

不建议把业务 ID 写进参数名。比如不要有 bClip_Jacket_A_Torso，应该是装备数据决定穿 Jacket_A 时写 bClip_Torso = true。

身体裁剪与遮挡区域

服装穿模通常不是靠“美术再调一下”解决，而是靠稳定的身体区域裁剪体系。

推荐基础区域：

裁剪参数不要分散在 UI 里。装备数据应声明它会隐藏哪些身体区域，BP_OutfitComponent 应用完整 Snapshot 时统一写入裁剪参数。

材质槽和贴图通道

服装材质最好在角色族群内建立统一通道，而不是每件装备自定义一套材质参数。

材质参数和 Mutable 参数不一定一一对应。颜色这类轻量参数可以直接通过动态材质实例预览；真正会改变 Mesh、贴图合成或 LOD 的内容才触发 Mutable 生成。第五篇 UI 会用这个原则做拖拽预览防抖。

Groom、Cloth、Morph 和动画边界

不要把所有外观表现都塞进 Mutable。生产上要按系统能力分工：

边界越清楚，越容易 Debug。比如披风抖动异常是 Cloth 问题，发型不显示是 Groom/Slot 问题，身体穿模才优先查裁剪参数。

资源变量清单

建议在角色蓝图或配置资产中明确这些引用：

这些引用不要散在 UI 蓝图里。角色和系统配置应能一眼看出它依赖哪些资源。

资源校验流程

上线项目前，应该有一个编辑器校验按钮或 CI 检查：

Validate Appearance Resources
 -> 检查 Skeleton 是否一致
 -> 检查 SlotConfig 中所有默认装备存在
 -> 检查每件装备 SlotClaims 合法
 -> 检查 Mutable 参数名存在
 -> 检查 Enum 选项存在
 -> 检查 BodyRegion 名称合法
 -> 检查材质通道存在
 -> 检查 Soft Reference 可被 Asset Manager 管理
 -> 输出具体资产路径和字段名

校验报告必须指向具体资产和字段。只输出“Mutable 参数错误”没有价值，内容团队无法修。

失败路径和回退

资源错误分两类：会破坏角色可见性的错误必须阻止发布；只影响局部表现的错误可以线上降级，但要记录足够信息。

验收标准

1. 每个角色族群有明确的 Skeleton、Base Body、Mutable 主对象和默认实例。
2. SlotConfig 覆盖所有运行时 Slot，并且每个 Slot 都有默认装备。
3. Mutable 参数命名稳定，装备数据可以只通过参数名和选项值写入。
4. 身体裁剪区域有统一枚举或配置，不由 UI 临时写死。
5. 材质颜色、贴图、投影通道命名一致，可被 UI 和数据层复用。
6. Groom、Cloth、Morph、动画的归属边界明确，不全塞进 Mutable。
7. 编辑器校验能检查参数名、Enum 选项、Slot、默认装备、资源引用和裁剪区域。
8. 打包后默认角色、默认套装和至少一套完整服装能稳定显示。
9. 新增装备不需要修改 UI 蓝图，只需要新增数据和资源。
10. 资源错误能定位到具体资产路径和字段。

本篇结论

资源规划是生产级换装系统的地基。Mutable 图可以很强，但对外必须暴露稳定、少量、可校验的参数合同。Slot、身体裁剪、材质通道和默认装备在这一层定住，第三篇的数据资产才能把业务 ItemID 稳定翻译成 Mutable 参数。

参考资料

• Mutable Quickstart Guide
• Mutable FAQ
• Mutable Resource Usage at Runtime
• Mutable Plugin API Index
• UCustomizableObject::CreateInstance
• UCustomizableObjectInstance::GetComponentNames