背景

UniLab 需要系统评估复杂地形场景下的资源占用、物理 step 效率和渲染路径正确性，为后续 terrain / batch rendering / backend 适配方案提供依据。该 issue 聚焦调研、基准设计和方案评估，不直接要求完成具体实现。

调研目标

1. 调研同类 RL / robot simulation 平台在复杂地形、批量环境、批渲染和资源管理上的实现方式。
2. 梳理复杂地形对 CPU 内存、显存、asset/materialization、physics step 和 rendering pipeline 的影响。
3. 对 UniLab 当前 MuJoCo / Motrix backend contract 下可行的复杂地形支持方案进行优缺点评估。
4. 明确批渲染正确性验证方法，避免性能优化破坏观测、深度图、相机视角或多环境隔离语义。

调研范围

1. 同类平台调研

调研 Isaac Gym / Isaac Lab、MuJoCo、Brax、Genesis、Legged Gym 等平台在以下方面的设计：

• heightfield / mesh terrain 的表达方式和加载路径。
• terrain 随机化、curriculum terrain、tile-based terrain 的组织方式。
• 多环境并行时 terrain 数据是否共享、复制或实例化。
• renderer 与 physics scene 的绑定方式。
• batch rendering 的接口、限制和典型瓶颈。

2. 方案调研

围绕 UniLab 可选方案形成对比：

• 静态共享 terrain asset：初始化阶段 materialize，多个 env 复用。
• per-env terrain instance：每个 env 拥有独立 terrain，用于强随机化或 curriculum。
• tile / patch based terrain：预生成 terrain tiles，运行时只组合引用。
• heightfield 优先方案：控制内存占用和物理碰撞成本。
• mesh terrain 优先方案：提升表达能力，但需要评估碰撞和显存代价。
• backend-specific terrain adapter：差异保留在 backend / 配置层，env 只依赖 SimBackend contract。

3. 显存与内存占用分析

需要设计可复现的 measurement plan，至少覆盖：

• terrain geometry / heightfield / mesh 本体占用。
• texture / material / renderer buffer 占用。
• camera 数量、分辨率、渲染 modality 对显存的影响。
• batch size / num_envs 增长时的显存曲线。
• terrain 共享 vs per-env 实例化的内存差异。
• CPU 内存、GPU 显存和 backend 内部缓存的拆分统计。

4. 物理 step 效率分析

需要形成 benchmark 维度：

• simple flat terrain vs complex heightfield vs mesh terrain。
• 不同 num_envs 下的 physics step throughput。
• collision complexity、contact 数量、solver 参数对 step time 的影响。
• terrain randomization 是否发生在 cold path，避免 step/reset 热路径解析 asset 或 XML。
• MuJoCo / Motrix backend 的差异与隔离边界。

5. 批渲染正确性

需要明确 correctness checks，至少包括：

• 多环境相机输出是否和 env index 一一对应。
• RGB / depth / segmentation 等 modality 的 shape、dtype、坐标系和 near/far 语义是否一致。
• batch rendering 与逐 env rendering 在固定 seed / 固定状态下是否可对齐。
• camera pose、terrain placement、robot placement 在 batched scene 中是否互不污染。
• reset / domain randomization 后渲染结果是否正确更新。

UniLab 约束

评估方案必须遵守现有架构原则：

• backend-specific 逻辑留在 backend / env adapter / config 层，不扩散到 training scripts。
• env 层只调用 SimBackend 中声明的方法；若需要新增 backend 能力，应先扩展 SimBackend contract。
• asset / XML / model metadata 只允许在 init / materialization / cache 等 cold path 处理。
• task / reward / backend 选择优先通过 Hydra + registry 表达。
• 评估结论必须基于仓库已有配置、注册、测试、benchmark 或新增的可复现实验结果。

产出物

• 同类平台调研摘要。
• UniLab 可选方案对比表，包括优点、缺点、风险、适用场景。
• 内存 / 显存 measurement plan 和建议指标。
• physics step benchmark plan 和建议指标。
• batch rendering correctness checklist。
• 推荐的短期方案与长期方案，并说明对 backend contract / config / tests 的影响。

验收标准

• 给出至少 3 个同类平台的对比分析。
• 明确复杂地形在 CPU 内存、显存、physics step、rendering correctness 上的主要风险。
• 给出 2 个以上 UniLab 可选技术方案，并说明何时选择。
• 明确哪些能力需要进入 SimBackend contract，哪些应留在 backend 实现或配置层。
• 给出可执行的 benchmark / correctness validation 设计，后续可拆分为实现 issue。