Genesis World：Solver 与 Coupler

Rigidrigid solver

↘

Scenecoupler per substep

↗

Soft / fluidMPM / SPH / FEM

→

统一接口state + render

1. 先更新对 Genesis 的认识

2024 年的项目已演化并更名为 Genesis World。当前开源主干不是“一个生成式世界模型”，而是 conventional physics + rendering + simulation API。编译底座已从早期资料常写的 Taichi 演化为 Quadrants，照片级渲染主路线是 Nyx。理解当前系统应以新仓库与版本文档为准。

层	核心职责	关键概念
Simulation Interface	资产、entity、controller、sensor、并行环境与 GUI	Scene、Entity、scene.step()
Physics	刚体、软体、颗粒、流体和跨物理耦合	solvers + coupler + per-solver state
Render	实时、批量与照片级 camera sensing	Rasterizer、BatchRenderer、Nyx
Compiler	把 Python kernel 降到多种硬件后端	Quadrants、autodiff、GPU graph、fastcache

2. Entity 如何决定 physics solver

一个 entity 可以理解为三部分：Morph 描述几何、pose 与导入来源，Material 描述物理模型，Surface 描述视觉外观。Material 决定实体被路由到哪个 solver：

Scene
└── Simulator
    ├── RigidSolver   ← rigid robot / URDF / MJCF
    ├── MPMSolver     ← granular / elastoplastic / viscous material
    ├── FEMSolver     ← elastic / plastic deformable solid
    ├── PBDSolver     ← cloth / soft body / particles
    ├── SPHSolver     ← liquid
    ├── SFSolver      ← Eulerian smoke / gas
    ├── ToolSolver    ← kinematic one-way tool interaction
    └── Coupler       ← interactions across active solvers

没有对应实体的 solver 不激活、不分配主要运行状态。scene.build() 是 authoring/runtime 边界：它冻结场景结构、分配 device arrays，并为实际配置编译需要的 kernel。USD/MJCF/URDF 是 importer 输入，不像 Isaac Sim 那样持续充当整个运行时的 scene truth。

3. Coupler 是“统一多物理”的关键

刚体夹爪抓 MPM 软物体、布料落在 rigid table 上、液体推动 rigid wheel，都跨越了 solver 边界。Genesis 用 scene-level coupler 处理这些界面：

• LegacyCoupler：通用旧路径，文档标记为将弃用。
• SAPCoupler：Semi-Analytic Primal contact formulation，适合特定 rigid–deformable 组合。
• IPCCoupler：Incremental Potential Contact，强调无穿透的稳健接触，但通常更昂贵。

“多个 solver 能放在同一 scene”不代表任意 solver × material 组合都同样成熟。双向力、摩擦、守恒、梯度和性能仍需按组合验证。

4. 一次 scene.step()

control step dt
  ├─ substep 1: solvers prepare → coupler resolves → solvers finish
  ├─ substep 2: solvers prepare → coupler resolves → solvers finish
  └─ ...
then publish state / sensors / render

SimOptions 给出全局 dt、substeps、gravity 与 differentiable mode；某个 solver 也可覆盖自己的时间参数。substeps 越多通常更稳但更慢，且不同 solver 的内部稳定条件并不相同。

RigidSolver 内部使用 generalized qpos/qvel：先做 forward kinematics 与 mass matrix/无约束加速度，再经 broad/narrow phase 生成接触，把 contact、joint limit 与 equality constraint 转成约束修正，最后 semi-implicit integration。它的一个 constraint solver 选项名为 Newton，这里只指牛顿数值迭代，绝不是 Newton Physics 引擎。

5. 并行环境为什么写起来简单

场景定义不变，在 scene.build(n_envs=B) 时打开 batch dimension。之后 state getter/setter 前面多一个 B 维，相同 kernel 同时推进多个环境：

scene.build(n_envs=4096)
qpos = robot.get_qpos()       # [4096, n_q]
robot.control_dofs_position(target_qpos)
scene.step()

同构 batch 最容易跑满 GPU；Genesis 也支持 subset reset/control、heterogeneous environments、batch rendering 和多 GPU 多进程。多 GPU 典型是一进程绑定一张卡再配 PyTorch DDP，并不是一个 physics world 自动横跨所有 GPU。

6. 渲染路径与 sensor 思维

把 Nyx 作为 per-camera sensor 而非 scene-wide renderer，允许控制相机走快速路径、只对保留的数据帧走照片级路径。不过 Nyx 是独立 package，其公开安装状态应按当时文档核对。

7. 可微分物理的正确边界

开启 SimOptions(requires_grad=True) 后，Genesis 记录 substep 中间状态，state getter 返回与 scene 关联的 tensor，loss 可以反传到控制或参数。v1.3 release 继续扩展 differentiable rigid-body simulation。

但“平台支持 autodiff”不代表全部 solver、coupler、collision 和 sensor 操作都有可靠梯度。当前文档仍把 ToolSolver 描述为 rigid tool → soft body 的临时单向可微路径；长 horizon 显存随时间增长，接触变化仍不光滑。实际支持应以安装版本和具体 solver/coupler 测试为准。

8. 什么时候 Genesis 特别有吸引力

• 任务同时涉及刚体与 cloth、soft body、颗粒、液体或 smoke。
• 希望用同一 Python API 面向 NVIDIA/AMD GPU、Apple Metal 或 CPU 后端。
• 想快速构建大量 batched env，又不需要 Omniverse 完整工业栈。
• 研究 differentiable simulation、材料参数拟合或 rigid-soft manipulation。

9. 四个 Genesis 量级计算

自测

1. Genesis 怎样决定一个 entity 由哪个 solver 推进？

由 entity 的 Material 类型路由到对应 solver；scene 只激活实际需要的 solver。

2. Coupler 与 solver 的职责有什么不同？

solver 推进自己物理域内的状态；coupler 处理不同 solver 所属实体之间的接触和交换。

3. 为什么 Nyx 设计成 camera sensor 有意义？

同一场景可以让快速控制相机与照片级数据相机采用不同路径，避免所有 camera 都承担同样成本。