优化warp动态物体采样

对比不同方法下采样动态物体的耗时：

  1. 每个环境的每个geom都创建一个mesh，在update_dynamic_mesh时对每个mesh都更新point和调用refit
    [WarpHeightQuery] Timing Statistics (after 200 queries):
  Total query time:     9.091 ms
  Update mesh:          8.739 ms (96.1%)
  Launch kernel:        0.084 ms (0.9%)
  Synchronize:          0.070 ms (0.8%)
  Post-process:         0.198 ms (2.2%)
  Throughput:           70398 rays/sec
  2. 每个环境的所有geom创建一个合并的mesh，在update_dynamic_mesh时对每个环境的合并mesh更新point和调用refit
    [WarpHeightQuery] Timing Statistics (after 300 queries):
  Total query time:     8.017 ms
  Update mesh:          7.648 ms (95.4%)
  Launch kernel:        0.120 ms (1.5%)
  Synchronize:          0.072 ms (0.9%)
  Post-process:         0.175 ms (2.2%)
  Throughput:           79832 rays/sec
  3. 所有环境的所有geom合并为一个mesh，在update_dynamic_mesh对合并的mesh更新point和调用refit
    [WarpHeightQuery] Timing Statistics (after 300 queries):
  Total query time:     3.949 ms
  Update mesh:          1.120 ms (28.4%)
  Launch kernel:        2.126 ms (53.8%)
  Synchronize:          0.532 ms (13.5%)
  Post-process:         0.170 ms (4.3%)
  Throughput:           162050 rays/sec
  4. 使用capture_launch的方法来调用kernel的计算，而不是每次都launch一个kernel
    [WarpHeightQuery] Timing Statistics (after 300 queries):
  Total query time:     1.309 ms
  Update mesh:          1.157 ms (88.4%)
  Launch kernel:        0.017 ms (1.3%)
  Synchronize:          0.000 ms (0.0%)
  Post-process:         0.133 ms (10.2%)
  Throughput:           489029 rays/sec
    这种性能下开启train.py, 4096个环境，每个环境添加1个box，一个ite耗时40s左右。 1024个环境，每个环境添加1个box，一个ite耗时3s左右。
  5. 修改了判断dynamic_mesh的bug，将terrain的mesh从dynamic_mesh中去除
    [WarpHeightQuery] Timing Statistics (after 300 queries):
  Total query time:     0.999 ms
  Update mesh:          0.831 ms (83.2%)
  Launch kernel:        0.017 ms (1.7%)
  Synchronize:          0.000 ms (0.0%)
  Post-process:         0.150 ms (15.0%)
  Throughput:           640487 rays/sec
    这种性能下开启train.py, 4096个环境，每个环境添加1个box，一个ite耗时20s左右。 1024个环境，每个环境添加1个box，一个ite耗时2.3s左右。
  1. kernel中使用的参数不能改变引用，只能改变这个参数的值。也就是可以使用self.a[:] = b[:]这种操作，但是不能使用self.a = b这种操作，因为会改变self.a的引用。
  2. opencode中使用tecent coding plan的Kimi K2.5模型，context达到40%以上之后回复会变得特别慢

20260526(优化动态越障任务)

修复了bug后，机器人现在可以在静态地形下追踪静态目标点。但是直接转到动态地形后效果不好，考虑添加课程学习。

构建动态障碍的课程学习机制：

  1. 障碍运动速度课程，以episode结束时机器人是否到达障碍上（距离误差<0.2m）为指标，初始运动速度为0,当成功的环境数高于80%时，提升障碍运动速度
  2. 障碍距平台距离课程，与第一条同样的指标，一开始障碍边缘距平台边缘0m，当成功的环境数高于80%时，增大边缘距离。
  3. 障碍运动幅度课程，与第一条同样的指标，这一条课程要以第二条为条件，因为障碍运动模式为正弦波，当障碍边缘与平台边缘距离为0时无法执行运动，而当障碍边缘与平台边缘距离增大时，正弦波的幅值需要相应增大，确保不会让障碍边缘与平台边缘相碰撞 直接使用考虑了动态物体的raycasting训练太慢了，使用workaround，AI提出了方案1和方案2，我觉得还可以借鉴Ziwen Zhuang在robot parkour中提出的虚拟障碍物的思路，需要看它的源代码。
方案 1: 状态注入方案 2: 虚拟高度叠加
观测维度570 (+9)561 (不变)
策略输入格式变化不变
实现复杂度低中
预估加速30-50%40-60%
部署兼容性需要外部传感器完全兼容
备注raycasting只考虑静态物体，给policy额外输入moving box的状态（相对位置、速度、边长）保持 height query 的 17×17 网格格式不变，但移除动态物体的 raycasting。改为用 AABB 包围盒判定每个 query point 是否落在障碍物内，如果是则直接用障碍物顶面高度替代地形高度。策略输入格式不变，障碍物在高度图中表现为一个"凸起"。
使用状态注入方案训练，不到10个iteration就报Invalid constraint forces causing 'nan'错误，可能是掉下去导致的？
使用虚拟高度叠加方案训练，速度得到了显著降低。

但是之前给box加gravity_compensation+设定非常大的rho(密度)后，训练中会报Invalid constraint forces causing 'nan'错误，将box改为fixed，同样也能修改其位置。fixed=True将box从仿真的计算中剔除了出去。