统一的洞见
这整个层建立在一个洞见之上：你的 CAD 装配求解器和你的物理引擎，本质上是同一类东西。启用约束求解器后，配合关系的满足就成为一个实时的动力学节点——零部件位置输入，新的姿态输出——与流体节点或刚体节点在种类上并无不同。因此不存在一个你需要「导出」进去的「仿真模式」。打开实时动力学，整张图就会在你编辑的同时持续运行：拧动一颗螺栓，装配会重新求解；打开一个水龙头，水槽就会被注满；加热一个面，热量就会扩散开来。
每个被启用的求解器族，都会在文档的操作图上派生出一个节点，其输入输出都与设计自身的特征相连。删除这个节点，物理效果就消失了；设计本身不受影响。
每个族群都有一个四档梯度——关闭 · 动画 · 仿真 · 开启。约束默认始终开启（建模时配合关系保持满足）；碰撞默认在播放时才开启。
开启实时动力学后，求解器会在建模过程中就持续步进，而不只是在播放时才运行。设计与测试不再是两个阶段，而是同一个连续的过程。
求解器注册表
四个族群是世界步进器原生支持的；其余的通过同一个求解器接口自行注册，因此新增一种物理效果是一次插件式接入，而不是一次分叉。每个族群都会把自己的输出合并进同一份、每步一帧的状态数据中。
基于 Rapier 的刚体：凸包与三角网格接触、关节、可驱动的机构、连续碰撞检测。确定性、纯 CPU 计算，在浏览器和云端表现完全一致。
把装配求解器本身当作物理：完整的六自由度最小努力配合求解，与刚体步进相结合，使装配关系与动力学永不冲突。
基于位置的布料，与实体在世界空间中的精确三角网格发生碰撞——它会挂在真实的边缘上，而不是一个近似的球体上。
基于位置的、带压力的流体，从文档中的源头发射，并与所接触的一切进行双向耦合。
基于形状匹配的可变形体，会在真实几何体上挤压变形，并记住自己的静止形状。
体素级别的扩散与反应——加热一个面，看着它在整个体积中蔓延。
来自源头的电场与磁场叠加，同时以标量数据和原始矢量场两种形式输出。
对一个分子特征中的原子进行速度-Verlet 积分——同一套文档语法，只是尺度截然不同。
基于位置的粒子系统，用于沙粒、碎屑等一切颗粒状物体。
有意思的地方
「多物理场」这个说法很容易挂在嘴边，通常实际上只是「几个互不理睬的求解器」。而我们的求解器共享两条纽带，使各个族群真正发生相互作用。首先，每个求解器看到的都是同一批实时碰撞体——精确的三角网格会在每一步都根据刚体当前的姿态重新烘焙。其次，牛顿第三定律被贯穿整个世界：当一个可变形体、粒子或流体求解器对某个物体施力时，它会在接触点将大小相等、方向相反的冲量施加回那个刚体上，因此偏心的负载会产生真实的扭矩。倾倒的流体会掀翻一个轻盒子。沙子会压垮天平的托盘。布料会拽动它勾住的东西。接触冲量还会传递给一个模态合成器，因此碰撞是「有声音」的——冲量决定响度，材质决定音色。
一个端到端的用例
这个场景中的一切都不是针对另一个引擎写的脚本。它就是一份启用了五个求解器节点的文档，全部合并进同一份、每步一帧的状态数据中。
状态，而非像素
后端流式传输的是二进制状态帧——刚体姿态、可变形体点云、场网格——而不是渲染好的图像。你的视口对待权威的后端帧，与对待自己本地预览的方式完全一致，这意味着你是在把一个实时云端仿真当作可交互的 3D来环绕、拾取和重新取景，而绝不是在看一段录像。引擎在两端是同一套代码：编辑器内的预览与无头的云端容器运行的是同一份实现，因此你编辑时看到的，就是它在规模化运行时的样子。
快照与分叉
一份快照会把实时世界重新序列化回世界启动时所用的同一种规格格式——加载一份快照是一个不动点，而不是第二条代码路径。细节很关键：刚体会捕获其实时的线速度与角速度（在下落途中创建的快照，恢复后必须继续下落，而不是从静止重新开始），可变形体则会带上它完整的实时点云，因为一旦布料已经垂坠成形，静止形状就没有意义了。你可以把任意一份快照分叉为一个私有世界；Matrix 每天都会公开发布一份。
机器人
在 CommandAGI 的世界里，机器人就是一份带有关节结构的普通文档：刚性连杆、可驱动关节、控制范围。上传一个 URDF，它就会直接成为这样一份文档——没有导入到某个享有特权的「机器人系统」中。巡视车、通用机械臂、SO-101、类人机器人、四足机器人、无人机：说的都是装配求解器早已具备的同一套语法，这也是为什么同一套逆运动学与关节目标接口，既能驱动一个仿真中的机械臂，也能——更进一步——驱动一个真实的机械臂。这个故事在机器人页面继续展开。