图形学×具身 · 游戏角色的动作引擎，装进了真机器人：英伟达把两个行业接在同一根管子上

游戏引擎里的角色动画和机器人身上的运动控制，几十年来是两套工种。一边是动画师手调的状态机，角色跑步、跳跃、坐下各归各的动画片段，切换靠条件判断；另一边是机器人工程师写的运动学求解器，关节角度、力矩、平衡控制，公式林立。10 月 31 日英伟达公布的 MotionBricks 把这两套东西压成了一个模型：15,000 fps 的吞吐、2 毫秒延迟，既给游戏角色生成动作，也给真实的宇树 G1 人形机器人做全身控制，跑在一块 Jetson Orin 上。这篇工作入选 SIGGRAPH 2026，代码已开源，并已成为英伟达人形机器人计划 GR00T 的运动生成层。

一套积木，两种身体

MotionBricks 的核心设计叫 Smart Primitives（智能基元）：把"跳跃""坐下""拿起物体"这类动作技能做成模块化的积木块，像拼乐高一样组合出新动作，且不需要重训模型。模型在超过 35 万个动作片段上训练，输入是最近几帧姿态加一个目标姿态，输出是流畅的中间动作序列。

传统动画状态机的死穴是切换：状态机的分支是写死的，角色做"边跑边捡东西"这种没预录过的组合动作就会露馅。生成式路线的好处在这里显出来——动作是逐帧生成的，任何组合都是"新的一句话"，而不是"没写过的分支"。

为什么 15,000 fps 是关键数字

游戏引擎请求动作的频率是以帧计的，机器人控制回路是以毫秒计的。运动生成模型要在两个行业同时落地，推理速度就是入场券：跟不上控制回路频率的模型，再聪明也只能待在离线渲染管线里。MotionBricks 把单次生成压到 2 毫秒、吞吐拉到每秒一万五千帧，生成速度快过游戏引擎请求动作的速度。这个数字意味着它第一次跨过了实时性这道双行业的共同门槛。

sim-to-real 的一次正面示范

机器人侧的演示值得单独拆开说：同一个模型，不换权重，直接在真宇树 G1 上做全身控制。机器人学习圈的老大难问题是 sim-to-real gap——仿真里训练的策略搬到物理世界就水土不服。动作生成模型如果只见过虚拟角色的运动学，到真机上关节柔性、传感器噪声全都对不上号。这次演示传递的信息是：训练数据覆盖得足够宽（35 万片段），模型学到的运动先验可以覆盖虚拟与物理两种身体。

对具身行业，这补上了 GR00T 技术栈里"大脑决定做什么，谁来决定怎么动"的中间层。VLA 大模型负责理解指令、规划任务，MotionBricks 这类运动生成层负责把规划翻译成关节能执行的连续动作。分层各司其职，比一个模型包打天下的路线更近现实。

开源里的留一手

代码放上了 GitHub，预训练模型挂上了 Hugging Face，但底层动作数据的许可证限定"仅限内部评估"。想拿它商用，引擎能搭，训练数据不能带走。这是英伟达在具身栈上的一贯姿态：框架开放换生态，数据资产攥手里筑壁垒。想跟进的团队要么自己攒动作数据，要么等社区数据集长起来。

两个行业的同一个下半场

游戏行业看 MotionBricks，看到的是手调动画树的黄昏：角色动作从"美术资产"变成"模型生成"，美术的工作重心会从逐帧修曲线转向调教数据与风格。机器人行业看到的是运动控制的中间层开始标准化：谁家的运动生成模型又快又稳，谁就占据 GR00T 这类基础模型栈里的位置。

一条冷静的注脚：真机演示是英伟达自报口径，第三方复现数据还没有；动作的精细度、长时序稳定性、复杂地形下的表现，都还是待检验项。但这根把游戏引擎和机器人接在同一根管子上的连接件，方向已经立住了。

信源与限定：RoboHorizon 11 月报道（Mate Benyovszky）；embodiedaifrontier 10 月 31 日简报。15,000 fps、2 ms、35 万动作片段、SIGGRAPH 2026 入选、Jetson Orin 上驱动宇树 G1 等均为英伟达自报与媒体转述，论文见 arXiv；数据许可"仅限内部评估"出自 RoboHorizon 报道；第三方独立复现尚未见。

#图形学 #具身智能 #游戏引擎