Near-realtime prototype: UE5 MetaHuman face & lip-sync driven by emotion vectors (current A2F latency ~0.5-1s, target sub-200ms).
在体系里属于 Evie Runtime · Embodiment 子模块 · 上游接 Evie Runtime · Cognition (evie-agent emotion → blend shape) 与 Offline Model Adaptation (TTS audio) · 下游被 用户 (UE viewport / 桌面浮窗 / 未来 VR 头显) 引用 (见 架构图) · 最近验证: 2026-06
01 / demo 展示
当前 exploring 阶段, 3 段 MetaHuman + emotion → blend shape 链路 prototype. 点 play 看每段.
02 / 在系统里的位置
Embodiment 是虚拟人最贴近用户感官的一层 — 它把 Cognition 层产出的语义/情绪信号, 还原成一张能看、能眨眼、能微微前倾的脸. 没有这一层, 整个体系就停留在"对话框里的字"而不是"在场的实体".
ue-realtime 在数据流上承接两条上游: 一条是 evie-agent 输出的 emotion vector 与对话状态, 另一条是 TTS 的音频流 (Offline Model Adaptation). 它的下游是真实用户 — 现在是 UE viewport, 未来是桌面浮窗、可能延伸到 VR 头显形态.
传输层 QoS 选型: 文本对话走 TCP (可靠性优先, 丢字不可接受); 表情数据走 UDP 语义 (延迟优先, 丢一帧表情不影响体验, 但卡顿 200ms 用户立刻感知). 现有 LiveLink 已经使用 UDP 传输 blend shape 数据. 未来云端渲染方向评估 WebTransport (HTTP/3 + QUIC, 应用层可靠传输 on UDP) 和 WebRTC (浏览器原生 P2P 低延迟), 而非简单说"用 QUIC".
03 / 想解决什么
文字对话是有天花板的. 虚拟人愿景的"最终态"不是一个聊天窗口, 而是一个能看你、能露表情、能 nod / shake / lean in 的 entity. 这意味着 LLM → emotion vector → MetaHuman blend shape 这条链路必须实时 (sub-100ms 是理想数), 必须可控 (情绪强度、过渡曲线可调), 必须躲开"恐怖谷" (静止帧再真也会因为微表情错位垮掉).
如果没有这一层, Evie 会卡在"一个很会说话的 LLM" — 这恰恰是当前 AI 产品最拥挤的赛道. ue-realtime 把 Evie 从 chat surface 带到 embodied surface.
04 / 现状 + 已知 limit
状态: exploring. 链路已经走通最小可行原型, 但离"可看的产品形态"还有距离.
A已落地
UE5.4 MetaHuman 基础渲染跑通; UE MCP 工具集已能通过 PowerShell 控制 MetaHuman 的表情 / 说话 / 场景切换; Audio2Face (NVIDIA Omniverse) 接入实验; prototype LLM → emotion → MetaHuman face blend shape 链路已经能端到端跑一遍.
B探索中
A2F latency 优化 (当前 ~0.5-1s, 远未到实时); motion library 设计 (idle / nod / lean in 等几个基础动作还在规划); lip sync 调试 (中英文音素对齐还有 artifact).
C待解决
real-time emotion → expression 仍有恐怖谷区间, 微表情过渡不够柔; 没有自建 motion capture 数据集, 现在依赖 MetaHuman 默认动画; 桌面浮窗形态 (UE5 viewport 嵌 PWA? 独立 OBS 推流? 浮窗 overlay?) 未定方案.
05 / 下一里程碑
A拆分 emotion 映射与口型链路
当前两条信号挤在 Audio2Face 同一通道, 优化先解耦. 情绪走 emotion vector → blendshape 权重表的查表方式; 口型继续走 audio → A2F 推理. 解耦后可独立测量两段链路延迟.
B表情控制链路延迟优化至 sub-200ms
当前 ~0.5-1s 主要消耗在 Omniverse 推理. 解耦后情绪通道走查表 + 插值平滑, 不再依赖 GPU 推理; 口型通道继续评估 A2F latency 或替代方案.
C传输协议评估
WebTransport (HTTP/3) vs WebRTC (P2P) — 云端方向需要浏览器兼容的协议. 当前 LiveLink UDP 已验证本地可行.
D最小 motion library
5 动作 (idle / nod / shake / lean in / blink), 让 MetaHuman 不再只有表情.
06 / 迭代日志
以下是 ARKit52 路线从选型到 FACS 签名锁定的关键迭代节点. 每条记录的结构: 遇到什么问题 → 用什么思路解决. 不列全部尝试, 只列有工程决策意义的节点.
公开数据集真值重建. 问题: 数据集原 label 脏, sad 实际是哭喊脸, surprise 含遮眼图. 解决: 弃原 label, 用检测忠实性证实 (瞪眼通道高的全真瞪眼), 签名检索 → 人工复核 → clean exemplars 52 维标量向量做真值.
检测引擎冗余. 问题: 单一检测引擎对 FACS 关键 AU (颊提肌 / 皱鼻肌) 无信号永远输出 0, disgust / happy 精度崩. 解决: 换支持完整通道的检测引擎, 关键 AU 全部活, 多通道投影标准 52 字典.
FACS 签名实证锁定. 问题: 学术教科书签名在自采真数据上失效 — disgust 标定的皱鼻 AU 在真数据中全是怒脸, sad 也不是 AU1+15 而是 AU15+14. 解决: 正通道 + 负约束加权 (score = 正均值 - 0.4 × 负均值), 死通道绕过, 逐参数对比表定型六情绪.
真值库本地自采. 问题: 现有公开数据集要么系数范围与行业标准不兼容, 要么 gated, 要么说话张嘴淹没情绪信号, 全部不可用. 解决: 桌面端摄像头本地自采符合行业标准的标量参数, 自动录制 + 模拟移动端实时通道, 全流程自动化.
情绪语义判定. 问题: 参数对得上 ≠ 语义对, 相近情绪 (快哭 / 委屈 / 害怕) 参数差极小但情感不同. 解决: 盲喂实际参数不给目标, LLM 输出情绪类别 + 强度 + 依据, 人工判一致性而非打数值分.
三层验证表. 问题: 通用人脸检测在非真人脸 (动漫脸) 上严重失准, 张嘴 1.0 实测仅 0.28. 解决: 直读模型实际驱动值作客观保底, 检测值仅在真人脸场景标注采用, 检测改手动触发以解耦表情逻辑.
本地 TTS 口型同步. 问题: TTS 推理返回的音素时序对齐被官方脚本丢弃. 解决: 复刻推理路径保留音素对齐, 主元音映射韵母, 实时驱动嘴形 + 平滑过渡.
3D demo 第一版. 问题: 在线模型源被代理墙截断, 资产命名大小写混用导致绑定失败. 解决: 换离线模型 + 全资产本地化, 大小写无关兼容匹配, 验证表情驱动确实生效.
表情全链路闭环. 问题: 滑块调好的表情无自动验证, LLM 情绪→参数翻译准确度难评估. 解决: 加双向 API 服务, 前端实时显示 12 通道 JSON, 盲分辨情绪与目标表情并排验证 (不套打分模板).
量化确定性验证. 问题: 怀疑候选方案是温度采样输出, 同情绪每次参数不同会让 LLM 寻址失效. 解决: 同输入连跑确定性测试, 像素差 0, 滑块到向量映射确定性证实, 破除幻觉.
真值源路线选型. 问题: 一条候选路线输出的 63 维隐式向量无语义, LLM 寻址不了; 另一条参考方案官方 repo 无代码无权重, 不可复现. 解决: 锁定 ARKit52 blendshape 字典作真值源 (LLM 可读、0-1 标量、MetaHuman 工业标准兼容), 否决 2D 隐式路线.
以上节点涉及真值源选型、量化确定性、表情签名构建、检测引擎冗余与数据集清洗. 完整迭代远不止于此.
体系 / 模块