BlendShape 基本表情转换特殊表情

移动端面捕 SDK 只给基础表情通道，不给喜怒哀乐——那就用已有的 52 个基础 BlendShape，自己把特殊表情推导出来。

技术问题

移动端 Zstar 小电视需要驱动喜怒哀乐这类特殊表情。但移动端用的商汤面捕引擎只输出 52 个基础 BlendShape 通道——挑眉、眨眼、张嘴这个粒度，没有「开心」「生气」这种语义化的整体表情。

模型的特殊表情通道已经做好了，上游却没有数据可喂。换引擎不现实，加 SDK 又要付出包体积和授权成本。

现有方案不足

• 依赖引擎直接输出：PC 端方案可以拿到更丰富的解算结果，移动端 SDK 能力受限，直接输出特殊表情不可得。
• 美术逐表情手调：特殊表情靠离线动画或手动触发，失去面捕的实时性和自然度。
• 引入第二个 SDK：移动端算力和包体积预算都不允许再叠加一个识别引擎。

核心思路

特殊表情不是凭空出现的面部状态——笑是嘴角上扬、眯眼等多个基础表情通道的特定组合。既然基础通道已经在手里，就可以把特殊表情建模成基础通道的组合映射，一层推导解决问题。

flowchart LR
    A["商汤面捕引擎<br>52 个基础 BS"] --> B["分区域聚合<br>眼部 / 嘴部 / 眉部"]
    B --> C["组合判别<br>基础通道组合模式"]
    C --> D["特殊表情权重<br>喜 / 怒 / 哀 / 乐"]
    D --> E["平滑处理"]
    E --> F["模型特殊表情通道"]

关键实现

组合而非单通道

单一基础通道无法表达特殊表情——「喜」需要嘴部和眼部通道联动判别。推导按面部区域先聚合基础通道，再在区域间做组合判别，输出各特殊表情的 0-1 权重。

与协议层的关系

推导结果不是直接写死到某个模型上，而是填入 CompatibleFaceData 的 Effect 层。模型有没有特殊表情通道、通道叫什么名字，由驱动层按协议取数时决定，推导算法本身不感知具体模型。这样同一套推导同时服务 PC 端和移动端的模型。

移动端约束

整条推导链路是纯数值计算：输入 52 个浮点，输出若干个浮点。没有额外的模型推理、没有新的原生依赖，移动端每帧开销可以忽略。

应用场景

• 移动端虚拟形象：Zstar 小电视等场景下驱动带特殊表情通道的模型。
• 表情玩法扩展：任何只输出基础通道的面捕引擎，都能经此获得特殊表情能力。
• 协议增强：作为 CompatibleFaceData Effect 层的数据来源之一。

关联案例

• BlendShape 推导工程实现：推导链路的代码侧落地。
• CompatibleFaceBlendShape 协议：特殊表情数据的承载协议。
• 基于 Mediapipe 的面部捕捉算法：另一条特征点到 BS 的解算链路。