AI / Animation / Robotics
MotionBricks 在做什么
MotionBricks 把角色动作生成从“写一张巨大状态机”改成“给关键帧约束，让模型补齐中间动作”。这让游戏、机器人和 AR 交互可以用更少动画资产覆盖更多动态场景。
适合：实时 NPC、机器人动作控制、AR 小人交互、动画编辑器。
关键判断：实时、多技能、可控、可接引擎，是它区别于普通 text-to-motion 的地方。
主要风险：物理真实、骨架重定向、端侧部署和新物体 primitive 设计。
1. 背景：先把问题讲清楚
动作系统到底在控制什么
一帧角色动作不是一张图，而是一组结构化数据：根节点位置、身体关节姿态、速度和接触状态。动画系统每一帧都要生成这些数，才会让角色看起来像是在走、跑、爬、坐下或拿东西。
frame_1: root + pose + velocity + contacts frame_2: root + pose + velocity + contacts ...
传统动画图为什么越来越难维护
主流游戏引擎用 Animation Graph 驱动动作。角色状态越多，状态转移越多，手写规则会快速爆炸。换句话说，这不是单纯美术资产问题，也是软件工程里的状态机维护问题。
2. 旧方案为什么不够好
文生动作不等于可控动作
文本可以表达“一个人开心地走路并挥手”，但很难表达“0.5 秒后左手必须碰到墙沿，脚不能滑，玩家中途按键要能取消”。工业系统需要约束、连续性和毫秒级响应。
慢模型进不了运行时
游戏和机器人控制通常只有 16 到 33 毫秒预算。生成模型如果需要数百毫秒甚至几秒，只适合离线内容创作，不能进入实时交互。
3. 论文方法怎么解
把生成改写成关键帧补全
MotionBricks 的核心抽象是 in-betweening：给定当前关键帧和目标关键帧，让模型生成自然过渡。游戏事件、物体位置、目标速度和交互点都可以被翻译成关键帧约束。
current pose -> contact keyframe -> target pose
model fills natural motion between themSmart Primitives 是业务意图适配器
Smart Locomotion 处理移动，Smart Object 处理物体交互。它们的共同职责不是生成动作，而是把业务意图翻译成模型能理解的关键帧约束。
coarse-to-fine 管线降低延迟
底层 backbone 先把动作压成离散 token，再预测根轨迹、姿态 token，最后解码成连续动作。这条路线避开了重型多步 diffusion，更适合低延迟运行时。
4. 能力边界与局限
- 公开能力仍依赖高质量动捕数据，没覆盖到的风格或技能会下降。
- 它不是物理仿真。脚滑、穿模、重心和碰撞仍需要引擎或控制器兜底。
- 新物体交互仍要设计 intent keyframes，不能完全自动化。
- 从默认骨架迁移到自家游戏角色，需要 retarget 管线和验证。
5. 相关方案对比
7. 怎么用起来
高质量 PC Demo
用 UE5 + Python inference server 接一个角色，先验证动作 buffer 到渲染链路。
手机 AR 原型
用 AR Foundation 检测平面和锚点，把真实世界几何转成目标关键帧，让虚拟角色走、跳、爬。
端侧产品化
先云端跑 teacher，再考虑蒸馏、量化、ONNX/CoreML/NNAPI。端侧不是第一轮验证目标。
8. 最小可行闭环
- 跑通官方 demo，确认输入输出格式。
- 写 inference server，输入 context frames + keyframes，输出 future pose buffer。
- 客户端播放动作，先只做 locomotion。
- 接 AR 平面检测，点击目标点让角色走过去。
- 加入一个 Smart Object，例如桌面边缘 climb。
9. 这一轮结论
这篇论文适合作为可跟进方向，而不是立即当作完整产品方案。第一步应该做 runtime spike，验证模型输出、角色重定向和客户端播放链路。
术语表
- Root
- 角色骨架核心点，通常决定整体位置、朝向和移动。
- Pose
- 身体各关节的位置和旋转。
- In-betweening
- 给定关键帧，生成中间过渡动作。
- Smart Primitive
- 把业务意图翻译成关键帧约束的适配器。
- Retarget
- 把一种骨架上的动作映射到另一种角色骨架。