GLB / GLTF / VRM 运行时动画转 AnimationClip

Unity 官方的模型动画导入只发生在编辑器里。要在运行时加载外部 GLB / GLTF / VRM 文件并驱动角色，就得自己在运行时把动画数据翻译成 AnimationClip。

技术问题

虚拟人产品经常需要在应用运行期间加载外部模型资源：用户上传的模型、后台下发的角色资产、第三方格式的动画文件。这些资源以 GLB、GLTF、VRM 等格式存在，内部带有动画数据，但 Unity 引擎原生只认编辑器导入生成的资产，运行时拿到这些文件后，动画部分无法直接给 Animator / Animation 组件使用。

要让外部动画在引擎内播放、混合、复用，必须有一条运行时转换链路：解析文件里的动画数据，转换成 Unity 的 AnimationClip。

现有方案不足

• 编辑器管线不可用于运行时：Unity 标准导入流程在编辑器期完成，打包后的应用无法对新下载的模型文件走同样的导入。
• 格式差异需要显式处理：GLB 是 GLTF 的二进制封装，VRM 又是建立在 GLTF 之上的虚拟人扩展格式，三类输入的读取入口和动画数据组织方式不同，不能用同一段解析代码直接通吃。
• 骨骼对齐不是免费的：文件内的骨骼命名、层级和 Unity 场景内角色的骨骼结构未必一致，直接搬曲线会播到错误的节点上。

核心思路

把转换拆成「读取 → 映射 → 重建」三段：

flowchart LR
    A["运行时输入<br>GLB / GLTF / VRM"] --> B["解析文件结构<br>提取动画数据"]
    B --> C["骨骼层级映射<br>对齐场景角色"]
    C --> D["按采样数据<br>重建动画曲线"]
    D --> E["生成 AnimationClip"]
    E --> F["Animator / Animation<br>播放与复用"]

• 读取：按格式区分入口。GLTF 按文本结构解析，GLB 先解二进制封装再走同一套逻辑，VRM 在 GLTF 基础上额外处理虚拟人扩展数据。
• 映射：建立文件内骨骼节点与场景中角色骨骼的对应关系，处理命名和层级差异，保证动画落到正确的节点上。
• 重建：按文件中的时间采样数据重建 Unity 动画曲线，组装为 AnimationClip，供 Animator / Animation 组件直接播放。

三段解耦的好处是格式差异被限制在「读取」一段内：新增一种输入格式只需要补一个解析入口，映射和重建逻辑不变。

应用场景

• 运行时加载外部虚拟人模型并播放其自带动画。
• 跨引擎动画资产复用：GLB / GLTF / VRM 作为中间格式，动画统一转成 AnimationClip 进入 Unity 动画体系。
• 用户自定义角色内容：应用运行时接收外部模型文件，即时驱动。

关联案例

• Unity 到 Three.js 迁移：跨引擎动画表达的另一端，处理 Unity 与 Web 端动画数据的互译。
• ARKit 与 VRM 桥接：VRM 格式模型在驱动链路中的实际使用方式。