UE 虚拟人技术体系：MetaHuman、Live Link 面捕/动捕与动画模块集成

文章开头先放一个链接，PLAVE ‘Star Trace’ M/V

前几天刷 B 站，看到 PLAVE 的新 MV《Star Trace》。近几年我偶尔刷Melon榜单的时候会经常听到这个男团的作品，而且排名还非常的靠前，在韩国那个偶像产业极度内卷，近年来对于音乐作品要求逐渐变得更加严格而且趋向欧美化的情况下，这支虚拟男团还能再榜单占据一席之地并且开办自己的演唱会（JYP家团甚至经常进不了前十，Melon和JYP的爱恨情仇啊），这件事还是令我感到非常震惊。

（前段时间还看过一个虚拟形象是狗的男团，给我整破绷了，很难想象制作人和团员的精神状态。）

我真不行了

这件事的分量，不在皮更好看。真正的变化是三条链路被拉直到同一个时间尺度上：表演捕捉、资产与绑定、实时渲染与合成。过去它们各走各的节奏 —— 动捕一天、渲染一夜、后期一周；现在被压进同一秒。虚拟制片也真正的加入到工业化生产流水线。

把视线拉回国内，Asoul、星瞳，以及抖音上各家做的皮套人和饼干人，其实各自占据了这条光谱的不同位置：有的验证了直播陪伴的商业模式能不能持续变现，有的把大场直播的技术上限往上顶了一格，更多中小团队则在验证低成本、可日更的可行性。单看任何一家都不足以说明问题，三家拼起来才是一条完整的产业曲线 —— 从能播，到能看，到能上台。（甚至抖音自己就有皮套人商城）

行业认可也已经不是媒体口径的自说自话。PLAVE 成为首个在韩国主流音乐节目拿到一位的虚拟偶像团体，又在体育场级别的场馆里完成演出；Epic 官方把他们作为 UE 集成管线的代表性案例对外讲述；Hololive 的 FLOW GLOW 用全篇 UE 制作完成了一整场免费 3D live。引擎厂商、音乐工业、演出主办方，三个原本互不相干的圈子在同一条产线上碰面。

再往后看两三年，竞争点会从 “做得出来” 转向 “做得起、改得动、播得稳”。成本结构一旦降下来，虚拟制片就会从顶流专属的炫技，变成中型团队的标准配置；而面向动画师的工作界面正在被统一。

本文将该链路划分为五层：资产（MetaHuman）、传输（Live Link）、解算与重定向（MetaHuman Animator、IK Retargeter）、驱动（AnimBP、Control Rig）、输出（Sequencer、录制与烘焙）。未标注部分为工程经验与取舍，不代表官方规范。

0. 阅读说明

0.1 适用读者

0.2 核心结论

• 分层是排错的前提：资产、传输、解算、驱动、输出分别对应不同的故障模式。最终表现可能同为“角色不动”，但修复位置完全不同。
• MetaHuman 的资产与运行时对象分离：Character 资产是源资产，经 Assembly 生成角色蓝图与运行时资产；修改 Character 后必须重新装配。
• Live Link 的核心是三元组：Source 定义数据来源与传输方式，Subject 定义数据流名称，Role 定义数据契约；三者任一不匹配，消费端都无法获得数据。
• 静态数据与帧数据分离：StaticData 描述名称表、骨骼层级与属性 schema，只在连接或拓扑变化时推送；FrameData 每帧传输数值。静态数据重推会清空该 Subject 的帧缓冲，不能每帧调用。
• 面捕分为实时与离线两条路径：实时路径优先保证延迟与交互，离线路径优先保证质量与可重复性；两者的输入要求、处理流程与成本结构不同。
• 动捕的关键环节是重定向：源骨架与 MetaHuman 骨架不同，需通过 IK Retargeter 与 Retarget Pose 对齐；脚底滑动、腕部扭转、脊柱塌陷通常源于该环节。
• 动画集成以两套 AnimBP 为基础：身体与面部分别驱动，在角色蓝图、Control Rig 后处理与 Sequencer 层合流；单 AnimBP 方案会增加调试与复用成本。
• 实时流与最终资产分离：Live Link 适用于制作、预览与实时直播；需要稳定回放或交付时，应录制或烘焙为 AnimSequence、Montage 或 Level Sequence。
• 排错顺序固定：插件、Subject 名、Role、消费端（组件或 AnimNode）、骨骼与重定向、渲染与 LOD。

0.3 术语最小集

0.4 五层模型

flowchart LR
  subgraph CAP["采集 Capture"]
    F["面部
Live Link Face / 视频 / 音频"]
    B["身体
光学 / 惯性 / 手套"]
    A["声音
麦克风 / 音频文件"]
  end
  subgraph TRANS["传输 Transport"]
    LL["Live Link
Source → Subject → Role"]
  end
  subgraph SOLVE["解算 / 重定向 Solve & Retarget"]
    MA["MetaHuman Animator
离线解算"]
    IK["IK Retargeter
身体映射"]
  end
  subgraph DRIVE["驱动 Drive"]
    ABP["AnimBP
身体 / 面部"]
    CR["Control Rig
后处理 / 手动"]
  end
  subgraph OUT["输出 Output"]
    SEQ["Sequencer / Take Recorder"]
    BAKE["AnimSequence / Montage"]
    GAME["运行时角色"]
  end
  F --> LL
  B --> LL
  A --> LL
  LL --> MA
  LL --> IK
  MA --> ABP
  IK --> ABP
  ABP --> CR
  CR --> SEQ
  SEQ --> BAKE
  BAKE --> GAME

各层的典型故障模式与首要检查项如下：

0.5 目录

• 第 1 章 虚拟人的系统边界与产线划分
• 第 2 章 MetaHuman：资产、装配与运行时
• 第 3 章 Live Link：Source、Subject 与 Role
• 第 4 章 面捕：实时、离线与 MetaHuman Animator
• 第 5 章 动捕：光学、惯性与重定向
• 第 6 章 与动画模块集成：AnimBP、Control Rig、Sequencer
• 第 7 章 工程落地：流水线、性能与验收
• 第 8 章 常见问题与排查
• 第 9 章 最小实施路径与参数对照
• 总结
• 第 10 章 附录与参考

第 1 章 虚拟人的系统边界与产线划分

1.1 虚拟人与常规角色的差异

虚拟人并非普通角色资产的简单升级。二者在动画来源、面部复杂度、骨架来源、时间基准与交付形态上均存在差异：

因此，虚拟人项目的主要工程量集中在表演数据的稳定采集、时间对齐与绑定映射，而非模型导入。

1.2 实时与离线两条产线

设计原则：实时产线优先保证连续性与可恢复性，离线产线优先保证可重复性与可修正性。两条产线的资产、参数与采集规范应分别管理，避免混用。

1.3 延迟构成

实时虚拟人的响应延迟由完整链路决定，网络仅是其中一环：

若瓶颈位于采集端或无线网络，提升引擎侧算力不会显著改善延迟。

1.4 案例分析：PLAVE 与实时虚拟偶像管线

PLAVE 是韩国 VLAST 推出的五人虚拟男团，2023 年出道。与完全由 AI 生成的虚拟形象不同，PLAVE 的角色由真人表演者通过动作捕捉与面部捕捉实时驱动；Epic 官方将其列为基于 Unreal Engine 的虚拟偶像案例[19]，路透社的报道则描述了其“动捕棚直连演出场地、表演者可实时看到观众反应”的演出方式[20]。从管线角度看，PLAVE 是 UE 实时虚拟制片能力在音乐演出场景中的落地案例，而非单纯的 3D 动画企划。

PLAVE 五位成员的赛车主题造型（图片由用户提供）。

图中展示了五人的赛车主题造型。发色、服装分区与配饰是角色识别的主要手段；在实时管线中，这些设计需要转化为可复用的材质、发片与绑定方案，而不能停留在静态插画层面。

需要先区分路线：从公开形象看，PLAVE 的角色属于风格化 3D 形象，制作方法和角色资产构成与 MetaHuman 写实资产存在略微差异。二者共享“资产—传输—解算—驱动—输出”的管线结构，但预算分配不同：写实路线把成本投入皮肤、毛发、眼球与微表情；风格化路线把成本投入轮廓、材质分层、表情可读性与舞台表现力。

从制作与技术管理视角看，PLAVE 的参考价值主要有三点：

1. 角色设计与技术预算匹配：风格化形象降低了写实渲染成本，但对轮廓、发型、服装与表情设计提出更高要求。角色越简洁，观众越容易把注意力放在表演与音乐上；这也意味着绑定和表情系统必须足够稳定。
2. 实时链路与现场反馈闭环：VLAST 将动捕棚与演出场地直连，并让表演者看到观众反应[20]。这不是单纯的渲染问题，而是采集、传输、驱动、输出与现场导播的协同；任何一环延迟，都会破坏“人在现场”的感觉。
3. 内容形态决定管线取舍：演唱会强调实时与低延迟，MV 与综艺可以使用预渲染或离线精修；同一套角色资产需要同时支持两种输出。制作上通常采用“实时预览 + 录制/烘焙 + 后期”的混合流程，而不是把所有内容都压在实时链路上。

公开资料有限但是可以从中提取出 PLAVE 的管线结构与技术要点，整体还是基于UE的实时虚拟制片管线。

第 2 章 MetaHuman：资产、装配与运行时

2.1 MetaHuman 的资产组成

MetaHuman 由一组相互绑定的资产组成，而非单一骨骼网格，可分为外观资产与驱动资产两类：

面部与身体是两套相对独立的绑定，各自拥有骨架、rig 与 AnimBP，最终在角色蓝图层组合为完整角色。

2.2 从 Character 资产到可运行角色

在 UE 5.6 中，MetaHuman Creator 作为引擎内置的 Character 资产编辑器工作[13]。编辑完成的结果是 MetaHuman Character 资产，尚不能直接作为关卡角色使用；需通过 Assembly（装配） 生成角色蓝图与运行时资产[10]。

flowchart LR
  A["MetaHuman Character 资产
身份 / 外观 / 毛发 / 材质"] --> B{"选择装配管线"}
  B -->|"UE Cine"| C["影视级装配
最高保真"]
  B -->|"UE Optimized"| D["实时优化装配
High / Medium / Low"]
  B -->|"UEFN Export"| U["UEFN 资产"]
  B -->|"DCC Export"| X["外部 DCC 资产"]
  C --> E["角色蓝图
Body + Face + Groom + AnimBP"]
  D --> E
  E --> F["放入关卡 / Sequencer / 录制"]

官方提供四种装配目标：UE Cine、UE Optimized、UEFN Export、DCC Export。其中 UE Optimized 与 UEFN Export 均提供 High、Medium、Low 三档优化级别，可按目标平台分配预算。

注意：装配并非一次性步骤。修改 Character 资产（面部、材质、毛发、LOD）后必须重新装配，否则关卡中仍使用旧版本资产。

2.3 身体与面部两套绑定

由于面部与身体使用独立绑定，“面捕与动捕”通常对应两个 Subject 与两套 AnimBP。将二者合并到单一 AnimBP 会增加调试与复用成本，更常见的做法是分别驱动，在角色蓝图或 Sequencer 层合流。

2.4 运行时对象与开销

MetaHuman 的开销具有组合特征：单独评估毛发或皮肤时，开销尚在可接受范围；与实时面捕、光追同时启用时，预算会快速耗尽。应先确定目标平台与帧率，再选择装配管线。

2.5 实施注意事项

• 区分 Character 资产与角色蓝图：Character 是源资产，关卡中应放置装配后的角色蓝图。
• 材质修改需追溯源资产：仅修改材质实例时，重新装配或切换 LOD 后可能被覆盖。
• 保持 LOD 同步：身体、面部与毛发各有 LOD，切换不同步会导致外观不一致。
• 确认 Groom 绑定：Groom 为独立资产，装配或迁移时需检查绑定关系。

第 3 章 Live Link：Source、Subject 与 Role

3.1 设计目的

若缺少统一的数据总线，每个设备厂商都需实现独立的数据注入逻辑，角色蓝图将被厂商 SDK 耦合。Live Link 的设计目标是将采集设备与引擎消费端解耦[5]：

数据流可以概括为：设备或软件 → Source（传输实现） → Subject（命名数据流） → Role（数据契约） → 消费者（AnimBP / 组件 / 工具）。

该结构带来的直接收益包括：

• 面捕应用、光学动捕、惯性动捕与视频源可同时接入，互不干扰。
• 更换设备时只需更换 Source，角色侧的 Subject 名与 AnimBP 尽量保持不变。
• 同一份数据可被多个消费者读取，用于预览、录制、调试或多角色驱动。

3.2 三元组：Source、Subject 与 Role

三者中，Subject 命名是最常见的错误来源。设备端填写的名称、引擎中选择的名称与 AnimBP 中读取的名称必须完全一致；大小写、空格与后缀均属于名称的一部分。

3.3 Role 与数据面

Role 决定 Subject 的数据契约，同时约束静态数据与帧数据的具体类型：

面捕与动捕数据绝大多数落在 Animation Role 或 Basic Role。身体动捕通常提供完整骨架的 Transform，面捕通常提供表情曲线；头部位姿可能作为帧数据的一部分提供，也可能拆分为独立 Transform Subject，取决于源类型与配置。

3.4 静态数据与帧数据：PushStaticData 的设计

Live Link 将 Subject 的数据拆分为两类生命周期不同的部分：

• StaticData（静态数据）：描述数据的结构，例如骨骼名称、骨骼父子关系、曲线名称表、跟踪标志。它不随帧变化。
• FrameData（帧数据）：描述某一时刻的取值，例如骨骼 Transform、曲线 float 值、世界时间与到达时间。

3.4.1 LiveLinkFaceSource 中的 PushStaticData

Live Link Face 属于曲线型面捕源，位于 MetaHuman Live Link 插件的 LiveLinkFaceSource 模块：App 通过 UDP 发送表情曲线值与头部位姿，源侧接收并转发给 Live Link Client。PushStaticData 是源侧的静态数据登记入口，最终调用 ILiveLinkClient::PushSubjectStaticData_AnyThread(SubjectKey, Role, StaticData)[15]。

对于这类源，静态数据的核心是表情曲线名称表。FLiveLinkBaseStaticData::PropertyNames 的定义即“每帧将发送的曲线值的名称”；帧数据中的 PropertyValues 按相同顺序提供对应的 float 值[16][17]。头部位姿属于每帧数据，是否包含头部旋转与位移由 ULiveLinkFaceSourceDefaults 中的默认配置项 bHeadOrientation 与 bHeadTranslation 控制[18]。具体静态数据类型可能由插件定义为派生结构，以下代码仅表示调用关系。

// 结构示意：类型名与 Role 以所用插件版本为准
void FLiveLinkFaceSource::PushStaticData()
{
    FLiveLinkStaticDataStruct StaticData(FLiveLinkBaseStaticData::StaticStruct());
    FLiveLinkBaseStaticData& FaceStatic = *StaticData.Cast<FLiveLinkBaseStaticData>();
    FaceStatic.PropertyNames = BlendShapeNames; // ARKit 52 条曲线名，顺序即帧值顺序

    Client->PushSubjectStaticData_AnyThread(
        FLiveLinkSubjectKey(SourceGuid, SubjectName),
        RoleClass,
        MoveTemp(StaticData));
}

void FLiveLinkFaceSource::PushFrameData(const FFacePacket& Packet)
{
    FLiveLinkFrameDataStruct FrameData(FLiveLinkBaseFrameData::StaticStruct());
    FLiveLinkBaseFrameData& FaceFrame = *FrameData.Cast<FLiveLinkBaseFrameData>();
    // 填充 WorldTime、PropertyValues 等字段
    FaceFrame.PropertyValues = Packet.BlendShapeValues; // 与 PropertyNames 同序

    Client->PushSubjectFrameData_AnyThread(
        FLiveLinkSubjectKey(SourceGuid, SubjectName),
        MoveTemp(FrameData));
}

需要特别注意：PushSubjectStaticData_AnyThread 会清空该 Subject 已缓冲的所有帧。因此静态数据不能在每帧调用中重复推送，否则会持续丢弃帧缓冲并导致动画停滞或跳变。其合理调用时机包括：

1. Subject 首次建立、设备首次连接。
2. 设备断开后重连。
3. 曲线集合或骨骼拓扑发生变化，例如应用切换 blendshape 集、固件升级或更换设备。
4. 源设置改变了数据结构，例如启用或关闭头部位姿数据。

3.4.2 为什么这样设计

将结构数据与帧数据分离，主要基于以下考虑：

1. 降低带宽与序列化成本：52 条曲线名若每帧重复发送，会显著增加网络负载；名称表只需发送一次，帧数据只传 float 值。
2. 先声明后赋值：Client 与消费端可以在值到达前建立名称映射、分配缓冲并校验 Role；这对后续加入的编辑器会话与重连场景尤为重要。
3. 支持按名称绑定：重定向资产与 AnimBP 通过曲线名或骨骼名建立映射，而不是依赖数组下标；名称表是这套映射的基准。
4. 支持动态拓扑：当设备或应用改变曲线集合时，重新推送静态数据即可重建 Subject，而无需重启引擎。
5. 线程与内存友好：静态数据是不可变快照，可被多个消费端共享；帧数据只需填充与名称表等长的数值数组，减少每帧的名称开销与分配压力。

若只推送帧数据而没有可用的静态数据快照，Client 通常无法将该 Subject 视为有效，帧数据也不会进入正常的评估流程。因此 PushStaticData 是 Subject 生命周期中的必要步骤，而不是可选的优化。源侧与 Client 的接口约定、Source 的实现方式，参见 Live Link Plugin Development 文档[14]。

3.4.3 数据类型的层次

除 StaticData 与 FrameData 这两个核心类别外，Live Link 还使用若干辅助类型描述 Subject 的身份、容器与时间信息：

其中 FLiveLinkSkeletonStaticData 包含 BoneNames 与 BoneParents，FLiveLinkAnimationFrameData 包含与骨骼顺序一致的 Transforms；FLiveLinkBaseStaticData 则只包含 PropertyNames，由 FLiveLinkBaseFrameData::PropertyValues 按同序提供数值。Role 的作用在于把这些类型组合成消费端可解释的数据契约。

3.5 数据如何到达 AnimBP

Live Link 数据进入角色主要有三种方式：

Live Link Pose 的关键参数包括：

• Subject Name：指定读取的数据流。
• Role：指定数据类型，通常为 Animation。
• Retarget Asset：源骨架与目标骨架不同时所需的重定向资产。
• Evaluate / Interp：控制是否评估与是否插值；插值可降低抖动，但会增加延迟。

从数据包到 AnimBP 的处理链路如下：

1. 源侧接收：LiveLinkFaceSource 通过 UDP 接收数据包，解析曲线值与头部位姿。
2. 静态数据登记：首次连接或拓扑变化时调用 PushStaticData，向 Client 提交曲线名称表与 Role。
3. 帧数据推送：每个数据包调用 PushSubjectFrameData，提交曲线值、时间戳与元数据。
4. Client 缓冲与评估：Client 保存静态数据快照与帧缓冲，按 Subject 设置进行插值、时间偏移与丢帧处理，生成评估帧。
5. 消费端读取：AnimBP 的 Live Link Pose 节点或 Live Link Controller 在求值时取得评估帧。
6. 重定向与映射：ULiveLinkRetargetAsset 依据静态数据中的骨骼名与曲线名，将源数据映射到目标骨架与目标曲线。
7. 驱动与录制：AnimBP 输出骨骼 pose 与曲线，Control Rig 进行后处理；Sequencer 与 Take Recorder 消费最终结果。

需要强调：AnimBP 不会直接接收 StaticData 结构，它接收的是经过 Client 评估与 Retarget Asset 转换后的骨骼 pose 与曲线；StaticData 的作用是使这些骨骼名与曲线名在链路中可解析、可映射。

sequenceDiagram
  participant APP as 面捕 App
  participant SRC as 源 Source
  participant LC as Client
  participant LN as Pose 节点
  participant RA as Retarget
  participant ABP as AnimBP
  APP->>SRC: UDP 数据包（每帧）
  SRC->>LC: PushStaticData（连接或拓扑变化）
  SRC->>LC: PushFrameData（每帧）
  Note over SRC,LC: StaticData 仅一次；FrameData 每帧
  LC->>LC: 缓存 + 插值 / 时间偏移
  LN->>LC: 请求评估帧
  LC-->>LN: 评估帧
  LN->>RA: BuildPose / BuildCurve
  RA-->>LN: Pose + Curves
  Note over LN,RA: StaticData 名称表用于映射
  LN-->>ABP: FPoseContext
  ABP->>ABP: 分层混合 / Control Rig

在这条链路中，StaticData 不参与每帧数值求值，但主要决定三个方面：Subject 是否有效、帧数据中的数组如何解释、消费端如何按名称建立映射。调试时应先确认静态数据结构与名称表是否符合预期，再检查帧数据是否持续到达。

各模块的职责如下：

3.6 时间、插值与同步

实时表演的时间一致性涉及四项因素：

1. Subject 时间戳：源端时间与引擎时间不一定一致，Live Link 会进行缓冲与评估。
2. 时间偏移：音画不同步时，应分别确认音频延迟、网络延迟与动画求值延迟，再决定调整哪一侧的 offset。
3. 插值：插值可减少抖动，但会引入额外延迟；直播场景优先保证声画同步。
4. 时间码：面部、身体、音频与摄像机合流时，Timecode 是比手动对齐更可靠的公共基准。

3.7 Live Link Hub

Live Link Hub 是独立应用，用于接收、管理和录制实时动画数据，并向同一网络中的多个编辑器会话分发数据[4]。其适用场景包括：

• 设备较多的单人场景：面部、身体与视频源集中管理，引擎仅负责消费。
• 多人或虚拟制片场景：现场多台机器与多个编辑会话共享同一批 Subject。

官方对资源竞争有明确说明：MetaHuman 的实时视频与音频源会大量占用 GPU；若 Live Link Hub 与 UE 运行在同一台机器，两个进程会竞争 GPU 资源，动画生成速度与质量可能下降。因此：

• 可放在引擎内 Live Link 面板运行的源，优先放在引擎内，由单一进程统一调度。
• 必须使用 Live Link Hub 时，优先部署在另一台机器。
• 同机运行时，应通过 t.maxfps 为引擎与 Hub 设置帧率上限，避免无上限渲染耗尽 GPU 资源。

3.8 源类型与选型

第 4 章 面捕：实时、离线与 MetaHuman Animator

4.0 概念全景与渲染链路

没有对系统和管线的改造需求，这节可以跳过。这节内容记不住也没关系，我也记不住

面捕数据最终要改变屏幕上的面部形状，中间涉及两类形变数据：骨骼变换（骨骼通道）与顶点偏移（顶点通道）。二者不是两条并行管线，而是在顶点处理的同一阶段先后生效；BlendShape/Morph Target、Control Rig、蒙皮与遮罩分别处在这条链路的不同位置。如果想要全面的了解相关的知识点，需要先建立这张概念地图，再进入 4.1 的面捕数据与后续的 DCC 处理。

“Mask Skin”通常指带遮罩的蒙皮权重层：蒙皮决定骨骼变换如何分配给顶点，Mask 用于按区域限制、排除或覆盖权重；UE 中可用 Skin Weight Profile 切换或覆盖权重。骨骼变化只影响权重非零的顶点，蒙皮本身不会改变骨骼或控制值。

一个骨骼变化从输入到屏幕，通常经过以下阶段。需要注意的是，顶点形变与蒙皮不是两次独立遍历，而是在同一个顶点着色器内先后执行，因此合并为「顶点处理」一个阶段：

sequenceDiagram
  participant IN as 输入
  participant EV as 动画求值
  participant SK as 骨骼链路
  participant VP as 顶点处理
  participant RD as 渲染
  IN->>EV: 曲线 / 控制值
  EV->>EV: 控制值 → 骨骼局部 Transform
  EV->>SK: 骨骼局部 Transform
  SK->>SK: 逐级累乘 → 组件空间
  SK->>SK: 乘绑定姿态逆矩阵 → 蒙皮矩阵
  SK->>VP: 蒙皮矩阵调色板
  VP->>VP: 叠加 Morph delta（参考姿态空间）
  VP->>VP: 按权重混合蒙皮矩阵
  VP->>RD: 顶点位置 / 法线 / 切线
  RD->>RD: 光栅化 / 材质 / 阴影 / 后处理
  RD-->>IN: 屏幕结果

关系可以概括为两条不同的驱动路径，它们在顶点处理阶段相遇：

骨骼路径（Control Rig / 骨骼动画）：Control Rig 实实在在地改变骨骼变换，骨骼链路将其逐级累乘，再乘绑定姿态逆矩阵得到蒙皮矩阵；蒙皮阶段用这些矩阵把顶点搬到新位置，于是姿态、轮廓与表情随骨骼运动而变化。

顶点路径（Morph Target）：Morph Target 不产生任何骨骼数据，它只改顶点——在参考姿态的网格顶点上叠加 delta。这里要注意 delta 的基底是网格顶点，而非骨骼数据；delta 也不改变蒙皮权重与蒙皮矩阵，它改变的是「即将被蒙皮的顶点」，因此蒙皮结果随之变化，这些顶点仍会被同一套矩阵带着跟随头部运动。

两条路径都能表达表情，只是载体不同，也因此可以混用：Sequencer 中既能给 Control Rig 控制值或面部骨骼打帧，也能给 Morph Target 曲线打帧。MetaHuman 的面部以骨骼与 Control Rig 为主，Morph Target 更多承担局部校正与辅助形变（见 4.1.3）。Live Link 与面板都只是输入源，本身不直接产生最终画面。

4.0.1 蒙皮：骨骼如何带动顶点

蒙皮解决的是「顶点不知道骨骼在动」这个问题。顶点与骨骼之间没有直接引用，二者靠导入时烘焙的一份绑定信息建立对应，运行期只做查表与加权求和。静态侧有三份只读数据：

动态侧，动画、Control Rig 与 IK 的输出都只是骨骼相对父骨的局部变换，需要逐级累乘后再折算回绑定姿态：

$M_b$ 即蒙皮矩阵，也是唯一真正作用到顶点上的量。它有一个自校验性质：骨骼回到绑定姿态时 $G_b = B_b$，于是 $M_b = I$，顶点完全不动。所有「骨骼没动就不该变形」的正确性都由这一步保证。

顶点按索引取到自己的若干蒙皮矩阵后做加权求和，即线性混合蒙皮（LBS）：

运动与形变来自同一个式子的两种取值：权重集中在一根骨骼上的顶点整体随该骨骼做刚体运动，表现为位移与旋转；权重跨两根骨骼的顶点被两个矩阵拉向不同方向，混合结果落在中间，表现为关节处的弯曲、挤压与拉伸。关节形变并不是额外施加的形变，而是权重渐变把离散的刚体运动变成了连续场。

法线与切线需用蒙皮矩阵变换后重新归一化，严格做法是取逆转置；骨骼矩阵为正交时两者等价，存在非均匀缩放时才有差别。漏掉法线变换的典型症状是光照不随肢体弯曲变化，皮肤呈塑料感。

LBS 的固有缺陷来自「对矩阵做线性插值」，而旋转不在线性空间中：关节大幅扭转时混合后的矩阵不再正交，顶点被向内吸，出现糖纸效应与体积塌陷。常见对策如下。

UE 侧的关键实现是：所有 $M_b$ 组成蒙皮矩阵调色板上传 GPU，顶点着色器按 BoneIndices 索引；启用 Skin Cache 后蒙皮结果写入缓存，供深度、阴影、GBuffer 等后续 Pass 复用，避免每 Pass 重算；每顶点影响数默认为 4，可在项目中提高，代价是顶点数据体积与带宽。

flowchart LR
  R["参考姿态顶点
Position / Normal / Tangent"] --> W["按 BoneIndices
取对应矩阵"]
  P["骨骼局部变换
动画 / Control Rig / IK"] --> G["逐级累乘
得到组件空间变换"]
  G --> M["乘绑定姿态逆矩阵
得到蒙皮矩阵"]
  M --> W
  S["BoneWeights
默认 4 个影响"] --> V["加权求和
混合各骨骼矩阵"]
  W --> V
  V --> O["组件空间顶点
再转世界空间与渲染"]

4.0.2 顶点处理内部的顺序

在同一顶点着色器内，Morph 与蒙皮的执行顺序是固定的「先 Morph、后蒙皮」：

Position = RefPosition + Σ w_i · delta_i     // 参考姿态的局部空间
Position = Σ_j w_j · M_bj · Position        // 蒙皮到组件空间
Position = ComponentToWorld · Position      // 到世界空间

这个顺序有实际意义：Morph delta 是相对参考姿态雕刻出来的局部偏移，先叠加再蒙皮，表情就会跟随头部旋转与身体运动；若反过来先蒙皮再叠加未经变换的 delta，表情偏移不参与骨骼转动，转头时五官会「留在原地」并把面部撕开。

4.1 面捕的数据形态

面部捕捉的原始输出通常为一组归一化系数或曲线，而非最终表情。以 ARKit 体系为例，Live Link Face 发送约 52 条 BlendShape 曲线、头部位姿与音频，覆盖眉、眼、鼻、颊、嘴、下颌与舌头等区域。

数据到达 MetaHuman 面部前还需经过解算与映射：

flowchart LR
  A["表演
面部与声音"] --> B["追踪
BlendShape / 深度 / 视频"]
  B --> C["解算
表情系数 → rig 控制"]
  C --> D["重定向
源面部 → 目标 MetaHuman"]
  D --> E["后处理
眼睑 / 眼球 / 舌头 / 修正"]
  E --> F["面部 AnimBP / Control Rig"]
  F --> G["渲染"]

ARKit 的 52 条曲线与 MetaHuman 的面部控制并非一一对应。MetaHuman 的面部包含更多控制项（眼睑、眼球、舌头、牙齿、面颊细节等），因此中间必然存在映射与补全；这也是同一段面捕数据应用于不同面部资产时表现存在差异的原因。

4.1.1 BlendShape 的基本概念

BlendShape（混合形状）是一类基于顶点差值的形变技术。它先保存一组目标形状（target shape）相对于基础网格（base mesh）的顶点偏移，再按权重将偏移叠加到基础网格上。其数学形式可概括为 $V(w) = V_{base} + \sum_{i} w_i \left( V_i - V_{base} \right)$，其中 $w_i$ 是第 $i$ 个目标形状的权重。

flowchart LR
  B["Base 顶点
静态参考数据"] --> A["加权累加"]
  D1["目标 A 的 delta
V_A − V_base"] --> M1["× w_A"]
  D2["目标 B 的 delta
V_B − V_base"] --> M2["× w_B"]
  D3["目标 N 的 delta
V_N − V_base"] --> M3["× w_N"]
  M1 --> A
  M2 --> A
  M3 --> A
  A --> O["输出顶点 V(w)
写入新的顶点缓冲"]

为什么是累加

当只有一个目标且 $w=1$ 时，$V = V_{base} + (V_i - V_{base}) = V_i$，$V_{base}$ 被自己抵消，结果正好落在目标形状上——这正是「把差值直接加到 base 上」的直觉写法。累加是为了覆盖多个目标同时生效的情形：微笑与张嘴往往并发，两者的偏移都必须计入，因此 $\sum_i$ 遍历的是目标形状列表，而不是顶点。

把式子展开可以看清 base 的地位：

base 相当于一个权重为 $1 - \sum_i w_i$ 的「第 0 个形状」：所有 $w_i = 0$ 时余项为 1，完全回到 base；$\sum w_i = 1$ 时 base 被抵消，结果退化为目标形状的加权平均；$\sum w_i > 1$ 时余项为负，base 被反向扣除，于是出现过冲。

两层遍历

计算中有两层循环，只有一层写进了公式：外层遍历目标形状（显式的 $\sum_i$），内层遍历所有顶点（隐式，逐元素运算）。单看第 $k$ 个顶点：

顶点之间互不搬运位移，第 $k$ 个顶点只吸收自己在各目标形状中对应的 delta。因此各顶点的求值完全独立，可任意并行；但也意味着顶点索引一旦变化，delta 就会错位——这就是后文 Check Topology 与重拓扑后需用 Wrap deformer 传递形变的根本原因。

base 必须是静态只读

每次求值都从同一份 base 重新计算，结果写入另一份顶点缓冲，base 本身永不修改。这使该运算成为纯函数：输出只取决于 base、delta 与权重，与之前算过几次、以什么顺序算无关。若改成把偏移累积写回当前顶点，权重从 0.9 突降到 0.1 时旧偏移无法撤销，每帧重复求值还会持续漂移，多系统叠加也会变成顺序敏感。

两个使用约束

权重不做归一化，因此 $w_i$ 可以小于 0（反向）或大于 1（夸张外推），这是表现力的来源，也是穿插与体积膨胀的来源，需要校正形状兜底。另外必须保持基础网格与目标形状的顶点数量、顺序、拓扑完全一致，否则按下标对应的 delta 会整体错乱。

目标形状除顶点位置外，还可携带法线与切线增量；引擎在合成时据此更新位置与着色数据，并对法线重新归一化，否则光照会随表情变化而变暗或翻转。BlendShape 适合局部、可叠加的形变，例如表情、口型与肌肉隆起；大范围旋转、体积保持与肢体运动通常交给骨骼或 Control Rig。

4.1.2 Maya 中的 BlendShape

Maya 将 Blend Shape 实现为一个 deformer：基础网格加一个或多个目标形状，由 blendShape 节点的权重控制[29]。典型创建流程是复制基础网格、雕刻目标表情，先选择目标形状、最后选择基础网格，再执行 Create Deformers > Blend Shape。

In-Between 是 Maya Blend Shape 的关键选项。开启时，目标形状按选择顺序串联，形变会从一个目标过渡到下一个目标，适合下巴张开等分段变化；关闭时，多个目标并行叠加，适合多个独立表情的组合。面部绑定通常关闭 In-Between，以便用多个基础表情组合出更丰富的表情。

Blend Shape 的权重可以关键帧、Set Driven Key 或表达式驱动，Shape Editor 用于管理目标形状。基础网格与目标形状必须保持相同的顶点数量与顺序；拓扑不一致时，需要先重拓扑或使用 Wrap deformer 传递形变。校正形状（corrective shape）通常在极端姿态下复制基础网格并雕刻修正，再作为额外目标加入，由组合权重或驱动关键帧控制。

4.1.3 UE 中的 Morph Target

UE 将 BlendShape 称为 Morph Target，并将其作为 SkeletalMesh 的顶点形变数据。通过 FBX 导入时启用 Import Morph Targets，Maya 的目标名称会成为 Morph Target 名称，通常为 [BlendShapeNode]_[BlendShape][26]。Morph Target 按 LOD 存储，每个目标记录顶点位置增量与切线 Z 增量，运行时按权重叠加。

UE 中常见的驱动方式有三类：

1. 蓝图显式设置：在 Event Graph 中使用 Set Morph Target 节点，目标为 SkeletalMeshComponent，输入名称与 0–1 的权重[27]。
2. 动画曲线驱动：在 Skeleton 资产上建立与 Morph Target 同名的曲线，在 AnimSequence 中为曲线打关键帧；SkeletalMeshComponent 维护 MorphTargetCurves，按名称将曲线值写入对应的 Morph Target 权重[28]。
3. Live Link 曲线驱动：Retarget Asset 的 BuildCurveData 将面捕曲线写入 PoseContext；若曲线名与 Morph Target 名称一致，最终会驱动对应的顶点形变。MetaHuman 的面部并非纯 BlendShape 方案，而是由控制曲线驱动 Control Rig、骨骼与校正形态；BlendShape 在其中主要承担局部校正与辅助形变。

UE 中的 MetaHuman 面部 Control Rig 面板会在面部显示一组控制点与控制器，并按眉、眼、鼻、口、下颌等区域组织。选中控制点后，可在视口中移动它，直接写入 Control Rig 控制值，再由 Control Rig 驱动对应面部骨骼。部分工具会把这些控制项进一步组织为滑块或属性面板，但核心仍是 Control Rig 控制值，而不是 Morph Target。它主要用于手动摆 pose、检查曲线映射与录制预览，也可在 Sequencer 中对控制值打关键帧。

UE 编辑器中的 MetaHuman 面部 Control Rig 面板，黄点为面部控制点，可用于手动调整表情与骨骼。

如果某个控制项最终驱动的是 Morph Target 曲线，它才会间接改变顶点形变；MetaHuman 面部板仍以骨骼与 Control Rig 为主。调试面捕时，可以先在面板中移动控制点，确认目标骨骼或控制项是否有响应，再回到 Live Link 曲线检查输入，从而区分“曲线没有进入”和“绑定没有响应”两类问题。

对于自定义曲线，通常需要在 Skeleton 的 Curve Metadata 中将其标记为 Morph Target，动画与 AnimBP 才会把它识别为形态目标曲线；导入的 Morph Target 若缺少对应元数据，也应在 Skeleton 中补齐。

性能方面，每个处于激活状态的 Morph Target 都会参与顶点计算，目标数量、网格顶点数与 LOD 共同决定开销。Morph 与蒙皮共享同一次顶点处理（见 4.0.2），启用 GPU Skin Cache 后二者在同一顶点任务内完成，不会额外遍历一遍顶点，但增量仍随激活目标数与顶点数线性增长。应在 Project Settings > Rendering > Optimizations 中按目标平台决定是否启用 Use GPU for computing morph targets[27]，并通过删除无用目标、按 LOD 配置目标、控制校正形状数量来维持预算。

4.1.4 从 Maya 到 UE 的交付要点

flowchart LR
  A["Maya 基础网格 + 目标形状"] --> B["Blend Shape 节点
权重 / In-Between"]
  B --> C["FBX 导出
Blend Shape 通道"]
  C --> D["UE 导入
Morph Target（+ 可选曲线）"]
  D --> E["Set Morph Target / 动画曲线 / Live Link"]
  E --> F["SkeletalMesh 顶点形变"]

4.1.5 面板控制与 Live Link 的流程差异

1. 拖动控制点或滑块时调用的函数

在 Control Rig 编辑模式下拖动控制点时，FControlRigEditMode::SetControlShapeTransform 的直接编辑分支会调用 UControlRig::SetControlGlobalTransform，把视口中的世界变换交给 Control Rig；如果存在约束，还会通过 SetControlLocalTransform 修正局部值并更新关键帧数据：

// ControlRigEditor/Private/EditMode/ControlRigEditMode.cpp（节选）
ControlRig->SetControlGlobalTransform(
    InShapeActor->ControlName,
    InGlobalTransform,
    /*bNotify=*/true,
    InContext,
    /*bSetupUndo=*/true,
    /*bPrintPython=*/false,
    /*bFixEulerFlips=*/true);

SetControlGlobalTransform 内部先把世界变换换算成控制值，再进入统一的写入路径：

// ControlRig/Private/ControlRig.cpp（节选）
FRigControlValue Value = GetControlValueFromGlobalTransform(
    InControlName, GlobalTransform, TransformType);

SetControlValue(
    InControlName, Value, bNotify, Context,
    bSetupUndo, bPrintPythonCommands, bFixEulerFlips);

最终写入的是控制元素当前值。非 Additive 的 Control Rig 会直接走下面的写入；Additive rig 会先把值缓存到 ControlValues，在 backward solve 后再应用：

// ControlRig/Private/ControlRig.cpp（节选，非 Additive 分支）
DynamicHierarchy->SetControlValue(
    ControlElement,
    InValue,
    ERigControlValueType::Current,
    bSetupUndo,
    false,
    bPrintPythonCommands,
    bFixEulerFlips);

运行时 UMG 滑块通常通过 UControlRigComponent 进入同一条路径：

// UFaceControlPanelWidget.cpp（示例）
// 成员：UPROPERTY(EditAnywhere, Category="Face")
//       TObjectPtr<UControlRigComponent> FaceRig;
void UFaceControlPanelWidget::OnJawOpenChanged(float Value)
{
    if (!FaceRig)
    {
        return;
    }

    FaceRig->SetControlFloat(
        TEXT("CTRL_JawOpen"),
        FMath::Clamp(Value, 0.f, 1.f));
}

SetControlFloat 内部调用 UControlRig::SetControlValue<float>，随后进入同一个 SetControlValueImpl。如果控制点类型是 Transform，则改用 SetControlTransform(..., EControlRigComponentSpace::RigSpace)。

2. 修改了什么值

• 修改的是 FRigControlElement 的 FRigControlValue，写入位置为 ERigControlValueType::Current；值类型由控制本身决定，可能是 float、bool、int、Vector2D 或 Transform。构造模式下还会同步更新控制偏移的 Initial 与 Current 变换。
• 拖动控制点时，GetControlValueFromGlobalTransform 会先把世界空间变换换算到控制空间，ApplyLimits 再套用最小/最大值，最后写入 Current。
• 它修改的不是骨骼 Transform，也不是 Morph Target 权重。骨骼变换是在 Control Rig 求值后由 rig 图写入 hierarchy 的结果；Morph Target 只有在 rig 图或曲线额外驱动时才会变化。
• bNotify=true 时 OnControlModified 会广播，编辑器据此触发 auto-key、Sequencer 关键帧与约束更新。

3. 与 Live Link 的差异

flowchart TB
  subgraph PANEL["面板路径"]
    direction LR
    P1["滑块 / 控制点"] --> P2["SetControlFloat / SetControlGlobalTransform"]
    P2 --> P3["FRigControlValue::Current"]
    P3 --> P4["Control Rig Evaluate"]
  end
  subgraph LL["Live Link 路径"]
    direction LR
    L1["面捕设备"] --> L2["Source / Subject"]
    L2 --> L3["Client 评估帧"]
    L3 --> L4["Live Link Pose"]
    L4 --> L5["Retarget / BuildCurveData"]
    L5 --> L6["AnimBP / Control Rig"]
  end
  P4 --> B["面部骨骼"]
  L6 --> B

4. 变量关系与 Morph Target 的影响

Live Link 的数据是上游输入，必须先经过 Client 评估、Retarget 与 AnimBP 映射，才会成为 Control Rig 控制值或 Morph Target 权重；面板滑块是下游直接写入，绕过这些中间变量。二者最终可以落到同一个 Control Rig 控制或同一个 MorphTargetCurves 条目，但写入的变量层级不同：Live Link 先改帧数据与曲线，面板直接改控制值或权重。

如果 Live Link 曲线名与 Morph Target 一致，曲线会经 BuildCurveData 写入 FBlendedCurve，再由 USkeletalMeshComponent::ApplyAnimationCurvesToComponent 调用 AppendActiveMorphTargets，最终落到 MorphTargetWeights；如果曲线映射到 Control Rig 控制，则先变成控制值，再由 Control Rig 求值骨骼。

BlendShape / Morph Target 的权重变化，默认影响范围如下：

骨骼变换与 Morph Target 权重共同作用：骨骼决定整体姿态，Morph 提供局部顶点偏移，二者在顶点处理阶段合成；Morph 不会反向改写骨骼或控制值。

流程上的关键变化是：面板路径从 UI 直接进入 Control Rig，跳过 Source、Subject、Client 与 Retarget；Live Link 路径在到达 Control Rig 前，还要经过静态数据登记、评估帧生成与曲线/姿态重定向。面板修改的是控制值，适合手动摆 pose、单实例调试与 Sequencer 关键帧；Live Link 修改的是帧数据，适合表演驱动、多角色分发与录制。

4.2 三条实时路径

上述实时路径由 MetaHuman Animator 的实时管线承载[1][2]。

Live Link Face 的工程注意事项[3]：

• Android 端目前为 Beta 版本，需确认 Live Link Face 在 Google Play 的区域可用性与目标机型的兼容性。
• 应用必须在前台运行，否则引擎无法发现设备。
• 移动设备与 PC 应处于同一网络，并放行防火墙；优先使用有线或专用 AP。
• 应用中的 Subject 名必须与引擎中选择的名称一致。
• 必要时在应用中指定目标 IP，避免自动发现失败。
• 长时间录制需关注设备发热与降频。

4.3 离线路径：MetaHuman Animator

MetaHuman Animator 是用于从表演数据生成动画的工具集，支持实时、离线深度与离线单目/音频三类输入[1]。本节讨论后两类，实时路径见 4.2 节：

1. 实时输入：单目摄像头、移动设备（Live Link Face）、音频源。
2. 离线深度输入：iPhone TrueDepth 或立体头戴相机（HMC）采集的深度数据。
3. 离线单目或音频输入：普通视频或纯音频。

离线深度解算不仅使用二维纹理，还使用几何深度信息，因此能够进行更稳定的身份对齐、头部姿态估计与面部形变求解，质量上限高于实时单目方案[12]。其代价是采集流程更复杂、处理时间更长，并对拍摄规范提出更高要求[11]。

离线产线与实时产线的核心差异在于可迭代性：单条 take 不满意时可重拍、重解算或清理；实时直播不具备该条件。因此两者在采集规范、设备配置与人员安排上应分别设计。

4.4 采集规范

面捕质量的上限在很大程度上由采集现场决定：

4.5 连接角色

实时面捕接入 MetaHuman 的流程可归纳为四步：

1. 启用插件：启用 Live Link 与 MetaHuman Live Link。
2. 建立 Subject：在 Live Link 窗口添加对应 Source，并确认 Subject 出现在列表中。
3. 连接角色：在关卡中 MetaHuman 角色蓝图的 Details 面板勾选 Use Live Link 并选择 Subject；或在 MetaHuman Creator 的 Preview Settings 中将 Animation Controller 设为 LiveLink 并选择 Subject，进行预览。
4. 确认消费端：检查面部 AnimBP 是否启用、Live Link Pose 是否读取同一 Subject、混合权重是否被其他节点覆盖。

Subject 出现在 Live Link 列表仅表示数据已到达；角色产生动画才表示数据被消费端正确使用。

4.6 面部后处理

实时面捕的常见问题表现为表情正确但缺乏真实感，而非缺少表情数据：

MetaHuman 的面部通常由 Control Rig 承担中间层：曲线先驱动控制点，再由控制点驱动骨骼与形态目标，后处理再修正眼睑、眼球与舌头。该结构便于修正，但链路较长，问题排查需逐段进行。

4.7 质量边界

选型应同时考虑质量上限与交付稳定性，而非仅比较峰值质量。以离线流程产出的高质量资产可用于直播，但流程必须按实时产线设计；实时面捕可用于影视预演，但不应直接作为最终镜头。

4.8 面捕传递表情系数，动捕传递骨骼数据

第 4 章的各个小节，实际是同一条链路的不同环节：数据以什么形态产生、怎么传、交给谁消费、会在哪里失真。把它们串起来会发现一条分界——面捕传的是角色无关的表情系数，动捕（第 5 章 动捕：光学、惯性与重定向）传的是角色相关的骨骼数据。

为什么采集后要先算表情系数，再转换成 Morph Target

UE使用的追踪算法原生输出的就是系数。消费级摄像头与深度传感器通常只能直接观测到「眉抬起了多少、嘴角拉向哪边」这类相对变化，给不出目标角色某根骨骼绕某个轴的旋转角——这个换算依赖目标 rig 的骨骼结构，只能在接收端完成。系数因此成为天然的中间层：

• 它与角色无关，同一份数据可以映射到不同面部资产，这正是 4.1 中「同一段数据在不同资产上表现不同」却又「能通用」的原因；
• 它可以在接收端走两条路径中的任意一条：直接落到 MorphTargetWeights 驱动顶点，或经 Control Rig 控制值驱动骨骼（见 4.0 的骨骼路径与顶点路径）；
• 4.6 列出的过冲、左右不对称、舌齿穿模等问题，本质都是曲线层的问题，在这里做增益、限幅、平滑、镜像，比改骨骼或改模型容易得多。

Morph Target 之所以成为常见落点，是因为它逐顶点表达局部形变、开销可控、可由同名曲线直接驱动；但它不是唯一去向——MetaHuman 的面部让曲线先驱动 Control Rig，再由骨骼与校正形态共同完成表情，Morph 更多承担局部修正。代价是映射有损：系数空间与目标角色的表情空间并不重合，眼、舌、齿等缺乏对应系数的部位需要额外交付通道或后处理补足。

为什么面捕不直接传骨骼

根本原因是层级不同：骨骼旋转是角色相关的最终姿态，面部骨骼的数量、命名、层级与绑定方式在不同 rig 之间差异极大；表情系数是角色无关的中间表示，可以直接作为传输契约。下面几项都是这一点的推论：

对照：动捕为什么传骨骼

动捕的源与目标同构：光学与惯性系统解算出的本来就是骨骼 Transform，且身体骨架有相对统一的语义（髋、脊柱、四肢、手脚），跨角色时只需处理比例与关节朝向，这正是第 5 章重定向要解决的问题。面部没有这种统一约定——不同角色的面部骨骼从几十根到数百根不等，命名与绑定各异，而且大量细微形变（皮肤滑移、皱纹、嘴唇贴合）本就不适合用骨骼表达。因此面捕把角色无关的系数放在链路上游，把「翻译成哪种 rig」留到接收端；动捕则直接传骨骼，再用重定向适配目标骨架。

两条链路的差异最终会回落到第 4 章开头的现象上：面捕的表达力受映射与补全的限制，动捕的精度受解算与重定向的限制。认清这一点，选型时才不会把「面捕数据质量」与「角色绑定质量」混为一谈。

第 5 章 动捕：光学、惯性与重定向

5.1 动捕源类型

无论采用哪种源，进入引擎的均为一套源骨架的 Transform。MetaHuman 使用另一套身体骨架，不能直接复制旋转，必须进行重定向[7]。此外，重定向之后通常还需通过关节与足部 IK 抑制漂移、保持脚底接触。

5.2 重定向链路

flowchart LR
  A["源骨架
动捕设备 / 软件"] --> B["Live Link Subject
Animation Role"]
  B --> C["IK Retargeter
链映射 + Retarget Pose"]
  C --> D["MetaHuman 身体骨架"]
  D --> E["身体 AnimBP
状态机 / 分层 / IK"]
  E --> F["Control Rig 后处理
脚底 / 骨盆 / 手"]
  F --> G["最终 pose"]

重定向需解决三类问题：

1. 比例：源演员与 MetaHuman 的臂长、腿长与脊柱长度不同。
2. 朝向：源骨架的 T-pose 或 A-pose、轴向与旋转顺序可能不同。
3. 约束：脚底需贴地、手部需贴合目标、膝关节不能反折。

5.3 Retarget Pose 与链设置

IK Retargeter 的核心并非一键映射，其流程是先对齐基准姿势，再定义链：

推荐的调整顺序：

1. 对齐站姿：在 Retarget Pose 下使源骨架与目标骨架呈现同一姿势。
2. 对齐大关节：确认肩、肘、髋、膝的方向正确。
3. 检查末端：确认脚底贴地、手部姿态自然。
4. 修正细节：处理 twist 骨、手指与脊柱分段。

5.4 根运动与脚底

脚底滑动是动捕虚拟人真实感下降的主要原因之一，通常有三类来源：

实时直播中，脚底问题会被镜头放大。条件允许时，应优先选择包含脚底接触信息的动捕方案，或在 Control Rig 中增加脚部 IK 与锁定。

5.5 手指、道具与多人捕捉

• 手指：手套数据通常作为独立 Subject，重定向至 MetaHuman 手部骨骼；若身体动捕不包含手指数据，手部将保持默认 pose。
• 道具：道具 Transform 可使用 Transform Role，或通过父子约束与 Attach 绑定至手骨；道具与手部的偏移应在校准阶段测量。
• 多人：每位演员对应一个 Subject；应优先采用统一命名规范（如 Actor01_Body、Actor01_Face），而非在蓝图中硬编码。

5.6 面部、身体与声音合流

三条流合流时，时间基准与角色映射最为关键：

flowchart LR
  F["Face Subject"] --> FB["面部 AnimBP"]
  B["Body Subject"] --> BB["身体 AnimBP"]
  A["Audio"] --> AU["音频组件 / 口型
（可选，可旁路）"]
  FB --> MH["MetaHuman 角色"]
  BB --> MH
  AU --> MH
  TC["Timecode / 同步信号"] -.-> F
  TC -.-> B
  TC -.-> A

实施建议：

• 面部、身体与音频分别使用独立数据流，避免合并为单条流。
• 使用 Timecode 或统一时钟对齐；无时间码时，至少通过打板或拍手完成一次人工对齐。
• 录制时应同时记录三条流，以便后期重新对齐与替换。
• 演员名、Subject 名与角色蓝图的映射关系应写入文档或数据资产。
• 在实时直播中，UE 的音频管线可能引入额外延迟，因此常将音频交由直播软件、调音台或采集设备直接输出，作为最终直播声轨，并与画面统一对齐。
• 是否使用 UE 音频组件，应依据同步方案与延迟预算确定。

5.7 选型参考

第 6 章 与动画模块集成：AnimBP、Control Rig、Sequencer

6.1 Live Link 在动画蓝图中的位置

面部与身体的接入方式不同，但整体结构相似[8]：

常见的身体 AnimBP 结构如下：

flowchart LR
  LSM["Locomotion State Machine"] --> LBP["Layered Blend Per Bone"]
  LLP["Live Link Pose（Body Subject）"] --> LBP
  LBP --> SLOT["Slot（Montage）"]
  SLOT --> PP["Post Process AnimBP（Control Rig：Foot IK / Pelvis）"]
  PP --> OUT["Output Pose"]

关键环节在于混合规则：

• Layered Blend Per Bone：按骨骼分层，例如下半身使用 locomotion、上半身使用动捕数据；需注意根骨与脊柱的混合点。
• Slot：使 Montage 与 Notify 能够覆盖实时数据，用于挥手、招手与剧情动作。
• Aim Offset：使头部或眼球看向目标，同时保留动捕的基础姿态。
• Inertialization：在状态切换时使用惯性化过渡，避免跳变。

常用节点及其边界：

6.1.1 关键函数与线程

3.5 节从数据对象与客户端角度描述了链路；本节从动画更新线程与函数调用角度描述同一链路的执行顺序。要理解 Live Link 与动画系统的联动，需要先区分动画更新（Update）与动画求值（Evaluate）。UAnimInstance::UpdateAnimation 是每帧动画更新的入口，负责触发蓝图与 C++ 的更新逻辑、准备变量和状态；它并不生成最终 pose。Live Link Pose 节点是在 AnimGraph 求值阶段才把数据转换为 pose 与曲线的。

关键区别：Live Link 不会主动调用 UpdateAnimation，也不会把 pose 写进某个蓝图变量。它是被消费的数据源：Live Link Pose 节点在 AnimGraph 求值时，主动向 Live Link Client 请求该 Subject 的评估帧。

因此，即使 AnimBP 的 Event Graph 为空，只要 AnimGraph 中接入了有效的 Live Link Pose 节点，角色仍会随 Subject 更新；反过来，只在 UpdateAnimation 中读取曲线，并不会自动把数据接到最终 pose。

NativeUpdateAnimation 的官方说明也强调：适合在这一步“收集数据”，把主要计算放到 NativeThreadSafeUpdateAnimation[21][22]。这与 Live Link 的接入方式一致：游戏线程负责选择 Subject、准备参数和处理输入，动画线程负责把评估帧转换为 pose。

6.1.2 Live Link Pose 的执行时序

以启用多线程动画更新为例，单帧内的执行顺序如下：

1. 初始化与缓存骨骼：节点初始化时创建并初始化 Retarget Asset；缓存骨骼阶段确定目标骨架的骨骼索引。Live Link 的 StaticData（BoneNames、PropertyNames）为骨骼与曲线的名称映射提供依据。
2. 游戏线程更新：UpdateAnimation 触发 NativeUpdateAnimation 与 Blueprint Update Animation。蓝图在这里计算状态、切换参数，必要时通过 Live Link Blueprint 节点读取一份当前快照用于逻辑或调试。
3. 线程安全更新：NativeThreadSafeUpdateAnimation / Blueprint Thread Safe Update Animation 在 Worker 线程执行，计算可以由动画线程安全读取的变量。此阶段不应直接操作 Live Link 的蓝图接口。
4. 节点更新：AnimGraph 中的节点执行 Update_AnyThread，推进时间与内部状态。Live Link Pose 在这一阶段通常只做轻量准备，不生成最终 pose。
5. 节点求值：FAnimNode_LiveLinkPose::Evaluate_AnyThread 向 Live Link Client 请求该 Subject 的评估帧[23]；Client 按 Subject 设置完成插值、时间偏移与丢帧处理后返回 FLiveLinkSubjectFrameData。
6. 重定向与写回：节点调用 Retarget Asset 的 BuildPoseFromAnimationData 与 BuildCurveData，把源数据写入 FCompactPose 与 FBlendedCurve，组成 FPoseContext[24]。
7. 混合与后处理：后续的 Layered Blend Per Bone、Slot、Aim Offset、Control Rig 等节点继续修改 pose 与曲线。
8. 输出与录制：最终 pose 应用到 SkeletalMeshComponent；Take Recorder / Sequencer 可以录制评估后的结果，而不是原始的 Live Link 数据流。

sequenceDiagram
  participant GT as 游戏线程 UAnimInstance
  participant WT as Worker AnimGraph
  participant LL as Live Link Client
  participant LN as Live Link Pose
  participant RA as Retarget Asset
  participant SM as SkeletalMeshComponent
  GT->>GT: UpdateAnimation / Blueprint Update Animation
  GT->>WT: 提交动画更新任务
  WT->>WT: NativeThreadSafeUpdateAnimation（可选）
  WT->>LN: Update_AnyThread
  WT->>LN: Evaluate_AnyThread
  LN->>LL: 请求评估帧（Subject / Role / 时间偏移）
  LL-->>LN: FLiveLinkSubjectFrameData
  LN->>RA: BuildPoseFromAnimationData / BuildCurveData
  RA-->>LN: FCompactPose + FBlendedCurve
  LN-->>WT: FPoseContext
  WT->>WT: 分层混合 / Control Rig 后处理
  WT-->>GT: 最终 Pose
  GT->>SM: 应用 Pose 并渲染

如果关闭多线程动画更新，上述 Worker 阶段会回到游戏线程执行，函数职责与数据顺序不变，只是线程位置不同。调试时可以用 stat anim 观察动画求值开销，并结合 Live Link 窗口确认 Subject 是否持续更新。

6.1.3 蓝图节点与使用边界

上述节点的职责划分，与 FAnimNode_LiveLinkPose 的求值位置及 ULiveLinkRetargetAsset 的 pose/curve 构建接口一致[23][24]；Live Link Blueprint 库则提供手动评估与数据读取入口[25]。

使用边界可以归纳为三条：

• 产生 pose 用 Live Link Pose：它是 AnimGraph 节点，负责把评估帧写入 PoseContext；不要试图在 UpdateAnimation 中手动拼一个 pose。
• 读取数据用 Live Link Blueprint 库：EvaluateLiveLinkFrame、GetCurves 等节点适合在游戏线程做逻辑判断、UI 或调试；它们返回的是数据快照，不是角色的最终动画。
• 线程安全更新只处理线程安全数据：Blueprint Thread Safe Update Animation 中不要调用非线程安全的 Live Link Blueprint 节点；需要的数据应在 Blueprint Update Animation 中准备好。

一个典型的分工如下：

flowchart TB
  subgraph EG["Event Graph：Blueprint Update Animation"]
    A["读取输入与状态"] --> B["设置 AnimBP 变量"]
    B --> C["可选：Evaluate Live Link Frame"]
  end
  subgraph AG["AnimGraph"]
    D["Live Link Pose"] --> E["Layered Blend / Slot / Aim Offset"]
    E --> F["Control Rig 后处理"]
    F --> G["Output Pose"]
  end
  B -.->|"变量与参数"| D
  C -.->|"逻辑 / 调试数据"| D

Subject 名、Retarget Asset 与骨骼映射属于节点的结构性配置，应在动画图或初始化阶段确定。运行中频繁更换这些配置可能触发重初始化或缓存失效，并带来额外性能开销；如果确实需要切换，应在切换后确认新 Subject 的静态数据已就绪，并预留一帧以上的稳定时间。

6.2 面部与身体的协同

MetaHuman 的面部与身体通常是两个骨骼网格、两个 AnimBP。协同位置如下：

面部与身体不宜在 AnimBP 内强耦合。在角色蓝图或 Sequencer 层合流更便于替换、调试与复用。

6.3 Control Rig

Control Rig 在虚拟人管线中通常承担三类任务[6]：

1. 后处理：脚部 IK、骨盆修正、手部贴合物件、脊柱微调。
2. 程序化动画：呼吸、眨眼、眼球微动与姿态限制。
3. 手动修正：在 Sequencer 中通过 Control Rig 轨道修改关键帧。

MetaHuman 的身体通常包含一个 Post Process AnimBP，其中使用 Control Rig 完成脚底与姿态修正；面部也有独立的 Control Rig 结构。使用时需注意：

• 后处理每帧求值，节点越多开销越高；直播场景应控制复杂度。
• Control Rig 的修正会覆盖上游结果，调参前需确认骨骼的实际修改来源。
• 若仅录制最终 pose，后处理逻辑不会被保存；需要可回放性时，应录制动画或保留 rig 参数。

6.4 Sequencer 与 Take Recorder

实时表演需经过录制才能成为可回放、可剪辑、可交付的内容[9]：

录制时的工程规范：

• 每条 take 使用统一命名，包含日期、演员与镜头号。
• 面部、身体与音频同时录制，并保留原始 Subject 数据。
• 录制前确认 Timecode 与帧率，避免回放时无法对齐。
• 录制完成后立即抽帧检查脚底、手部、眼部、口型与头发穿插。

6.5 运行时与交付

Live Link 适用于编辑器与制作阶段，不应作为默认运行方案：

录制或烘焙后的资产应在目标运行场景中回放一致；实时直播链路则应保留降级方案与备用素材。

6.6 主蓝图结构参考

该结构并非唯一实现，但将数据入口、逻辑、后处理与输出分离，便于逐层替换与排错。

第 7 章 工程落地：流水线、性能与验收

7.1 可交付流水线

7.2 资产与命名

• Subject 命名：采用 项目_演员_部位 结构，例如 Demo_A01_Face、Demo_A01_Body，避免使用默认名。
• Take 命名：包含日期、镜头与条数，例如 20261110_SH010_T03。
• 重定向资产：一个源骨架对应一个 Retargeter，命名中包含源类型，避免混用。
• 版本管理：MetaHuman 资产、Groom、动画与 Level Sequence 均使用 LFS；二进制资产不依赖“另存为”管理版本。

7.3 性能预算

上述指标因项目而异，不宜直接套用。有效做法是先建立基线：分别测试空场景、单角色、开启与关闭面捕、开启与关闭毛发，再确定优化优先级。

工程建议：在开发与制作阶段，应尽量减少 AnimBP 中对动捕数据的处理逻辑。更可取的做法是在预处理阶段或 C++ 中完成数据清洗、重定向与修正，AnimBP 仅将处理后的结果连接至 Output Pose，以降低图表复杂度与运行时求值开销。

第 8 章 常见问题与排查

排查应按“数据源到画面”的顺序进行，避免在错误层级反复调整参数。

第 9 章 最小实施路径与参数对照

9.1 实时面捕最小路径

1. 在 UE 5.6 项目中启用 Live Link 与 MetaHuman Live Link 插件并重启编辑器。
2. 准备一个已装配的 MetaHuman 角色，并将其放入关卡。
3. 在移动设备安装 Live Link Face，与 PC 连接同一网络，并在应用中填写 Subject 名。
4. 在引擎中打开 Window → Virtual Production → Live Link，添加 Live Link Face Source，确认 Subject 出现。
5. 选中角色蓝图，在 Details 的 Live Link 区域勾选 Use Live Link 并选择 Subject。
6. 面对镜头做出表情，确认面部与头部均产生动画；若无动画，按第 8 章顺序排查。
7. 需要留存时，使用 Take Recorder 或 Live Link Hub 录制 take，并回放检查。

9.2 离线面捕最小路径

1. 按采集规范录制一条包含深度信息的视频（iPhone TrueDepth 或 HMC）。
2. 在引擎中打开 MetaHuman Animator，导入素材并建立或选择身份。
3. 解算得到表演资产与动画，检查中性帧、极端表情与头部姿态。
4. 将动画应用于目标 MetaHuman，必要时执行重定向与后处理修正。
5. 进入 Sequencer 完成剪辑、渲染或烘焙。

9.3 身体动捕最小路径

1. 由动捕软件输出 Live Link，或通过 Live Link Hub 中转，确认 Subject 出现。
2. 创建或选择 IK Retargeter，源骨架选择动捕骨架，目标选择 MetaHuman 身体骨架。
3. 调整 Retarget Pose，使源与目标站姿一致，并补全链映射。
4. 在身体 AnimBP 中使用 Live Link Pose 读取 Subject，接入分层与后处理。
5. 检查脚底、根运动与手部姿态，必要时通过 Control Rig 修正。
6. 录制并烘焙。

9.4 参数生效位置

总结

虚拟人管线并非单一资产或单一插件的产物，而是覆盖资产、传输、解算、驱动与交付的系统工程。其构成包括：以 MetaHuman 为资产与绑定基础，以 Live Link 为实时数据总线，以 MetaHuman Animator 与 IK Retargeter 完成解算与重定向，以 AnimBP 与 Control Rig 完成驱动，以 Sequencer 与烘焙完成交付。其核心价值在于将面部、身体、声音与镜头纳入统一的数据结构、命名规范与时间基准，使跨设备、跨角色的集成具备可复用性与可排错性。

实际落地时，应先确定目标平台与实时/离线产线，再选择装配管线、采集方案与数据留存方式；静态数据结构、Subject 命名、Retarget Pose 与 Timecode 应作为前置工程约束，而非事后修补项。随着实时渲染、移动端面捕与离线解算能力的提升，该管线已应用于虚拟偶像、虚拟主播、影视预演与互动内容等场景，但其质量与稳定性仍取决于采集规范、数据治理与性能预算的协同设计。

第 10 章 附录与参考

10.1 模块与插件

10.2 关键 API 与概念

10.4 参考

正文中的引擎行为以 Epic 官方文档为准；项目取舍部分来自实际管线经验，不代表官方规范。

[1] Epic Games, MetaHuman Animator in Unreal Engine, Epic Games Documentation. https://dev.epicgames.com/documentation/metahuman/metahuman-animator-in-unreal-engine

[2] Epic Games, Real-Time Animation for MetaHumans in Unreal Engine, Epic Games Documentation. https://dev.epicgames.com/documentation/metahuman/realtime-animation-for-metahumans-in-unreal-engine

[3] Epic Games, Live Link Face Application for MetaHuman Animator in Unreal Engine, Epic Games Documentation. https://dev.epicgames.com/documentation/metahuman/live-link-face-application-for-metahuman-animator-in-unreal-engine

[4] Epic Games, Live Link Hub in Unreal Engine, Epic Games Documentation. https://dev.epicgames.com/documentation/en-us/unreal-engine/live-link-hub-in-unreal-engine

[5] Epic Games, Live Link in Unreal Engine, Epic Games Documentation. https://dev.epicgames.com/documentation/en-us/unreal-engine/live-link-in-unreal-engine

[6] Epic Games, Control Rig in Unreal Engine, Epic Games Documentation. https://dev.epicgames.com/documentation/en-us/unreal-engine/control-rig-in-unreal-engine

[7] Epic Games, IK Rig in Unreal Engine, Epic Games Documentation. https://dev.epicgames.com/documentation/en-us/unreal-engine/ik-rig-in-unreal-engine

[8] Epic Games, Animation Blueprints in Unreal Engine, Epic Games Documentation. https://dev.epicgames.com/documentation/en-us/unreal-engine/animation-blueprints-in-unreal-engine

[9] Epic Games, Take Recorder in Unreal Engine, Epic Games Documentation. https://dev.epicgames.com/documentation/en-us/unreal-engine/take-recorder-in-unreal-engine

[10] Epic Games, MetaHuman Assembly, Epic Games Documentation. https://dev.epicgames.com/documentation/metahuman/assembly

[11] Epic Games, MetaHuman Animator Video Capture Guidelines, Epic Games Documentation. https://dev.epicgames.com/documentation/metahuman/metahuman-animator-video-capture-guidelines-in-unreal-engine

[12] Epic Games, Animation from Depth Data, Epic Games Documentation. https://dev.epicgames.com/documentation/metahuman/animation-from-depth-data

[13] Epic Games, MetaHuman Creator in Unreal Engine, Epic Games Documentation. https://dev.epicgames.com/documentation/metahuman/metahuman-creator-in-unreal-engine

[14] Epic Games, Live Link Plugin Development in Unreal Engine, Epic Games Documentation. https://dev.epicgames.com/documentation/en-us/unreal-engine/live-link-plugin-development-in-unreal-engine

[15] Epic Games, FLiveLinkClient::PushSubjectStaticData_AnyThread, Unreal Engine 5.6 API Documentation. https://dev.epicgames.com/documentation/unreal-engine/API/Plugins/LiveLink/FLiveLinkClient/PushSubjectStaticData_AnyThread

[16] Epic Games, FLiveLinkBaseStaticData, Unreal Engine 5.6 API Documentation. https://dev.epicgames.com/documentation/unreal-engine/API/Runtime/LiveLinkInterface/FLiveLinkBaseStaticData

[17] Epic Games, FLiveLinkBaseFrameData, Unreal Engine 5.6 API Documentation. https://dev.epicgames.com/documentation/unreal-engine/API/Runtime/LiveLinkInterface/FLiveLinkBaseFrameData

[18] Epic Games, ULiveLinkFaceSourceDefaults, Unreal Engine 5.6 API Documentation. https://dev.epicgames.com/documentation/unreal-engine/API/Plugins/LiveLinkFaceSource/ULiveLinkFaceSourceDefaults

[19] Epic Games, Meet PLAVE: the K-Pop band powered by Unreal Engine, Unreal Engine Spotlight. https://www.unrealengine.com/en-US/spotlights/introducing-plave-the-unreal-engine-powered-animated-korean-boy-band

[20] Reuters, Virtual band PLAVE mixes K-pop and technology to charm fans, China Daily Asia, May 1, 2025. https://www.chinadailyasia.com/hk/article/610818

[21] Epic Games, UAnimInstance::NativeUpdateAnimation, Unreal Engine 5.6 API Documentation. https://dev.epicgames.com/documentation/unreal-engine/API/Runtime/Engine/UAnimInstance/NativeUpdateAnimation

[22] Epic Games, UAnimInstance::NativeThreadSafeUpdateAnimation, Unreal Engine 5.6 API Documentation. https://dev.epicgames.com/documentation/unreal-engine/API/Runtime/Engine/UAnimInstance/NativeThreadSafeUpdateAnimation

[23] Epic Games, FAnimNode_LiveLinkPose, Unreal Engine 5.6 API Documentation. https://dev.epicgames.com/documentation/unreal-engine/API/Runtime/LiveLinkAnimationCore/FAnimNode_LiveLinkPose

[24] Epic Games, ULiveLinkRetargetAsset, Unreal Engine 5.6 API Documentation. https://dev.epicgames.com/documentation/unreal-engine/API/Runtime/LiveLinkAnimationCore/ULiveLinkRetargetAsset

[25] Epic Games, ULiveLinkBlueprintLibrary, Unreal Engine 5.6 API Documentation. https://dev.epicgames.com/documentation/unreal-engine/API/Plugins/LiveLink/ULiveLinkBlueprintLibrary

[26] Epic Games, FBX Morph Target Pipeline in Unreal Engine, Epic Games Documentation. https://dev.epicgames.com/documentation/en-us/unreal-engine/fbx-morph-target-pipeline-in-unreal-engine

[27] Epic Games, Morph Target Previewer, Epic Games Documentation. https://dev.epicgames.com/documentation/en-us/unreal-engine/morph-target-previewer

[28] Epic Games, Animation Curves in Unreal Engine, Epic Games Documentation. https://dev.epicgames.com/documentation/en-us/unreal-engine/animation-curves-in-unreal-engine

[29] Autodesk, Create Deformers > Blend Shape, Maya User Guide. https://download.autodesk.com/us/Maya/2009help/files/Create_Deformers__Blend_Shape.htm

说明：文中界面名称与工作流以 UE 5.6 为准；不同小版本、不同装配管线（UE Cine、UE Optimized、UEFN Export、DCC Export）可能在菜单与参数上存在差异。示例结构与命名属于工程建议，并非唯一实现。