物理追踪 / InterMimic 调研，2026-04-28

本文档是 video-to-physically-plausible articulated HOI tracking 调研的持久工作日志。它会增量更新，目的是让后续工作可以在不依赖聊天上下文的情况下继续恢复。

项目目标与需求

本项目的目标不是单纯把一段现成视频做物理 replay，也不是只复现 InterMimic/PhysHOI 的 tracking policy。目标是建立一条 scalable pipeline：从 video prior / videogen 得到大量可控视频，重建出 articulated human-object interaction 的 4D reference，再通过物理控制把这些 reference 转成 simulation-ready 的人-可动部件物体交互数据。

换句话说，最终系统需要同时证明两件事：

1. 重建阶段足够强：能从视频中恢复 human motion、object root pose、articulated joint、moving part、contact/visibility/camera 等关键状态。
2. 物理阶段足够可执行：humanoid 不是逐帧 teleport，而是通过 PD/action-space control 与 passive articulated object 接触，并在物理仿真中产生合理的 object articulation，例如把 oven door 打开。

当前 open-oven 是压力测试，不是最终任务定义。它暴露的是 articulated HOI 中最关键的闭环问题：视频重建出的 reference 可能“看起来合理”，但只有当人体控制、接触几何、关节轴/limit、摩擦、质量和 PD/action residual 一起成立时，物体才会在 Isaac 中被真实推/拉开。

本次调研需要回答的问题：

• 当前仓库里到底是在做 replay、teacher tracking、PPO training，还是 action-space overfit？
• 哪些失败来自 reconstruction/reference/asset/contact mismatch，哪些失败来自 control/optimization？
• 如果目标是 per-video scalable data generation，是否应该为每条视频跑完整 PPO？
• 有没有更快的 single-sequence overfit 方案，可以直接利用本仓已有 resAction、object joint sidecar 和 articulated reward/diagnostic hooks？
• 参考仓里哪些设计可以迁移，哪些只是反例或只适合作 diagnostics？

明确的非目标：

• 不把 dynamic_replay 当成最终方法；它只能作为 preflight diagnostics 和 visualization。
• 不把每条视频长时间 PPO training 当成默认 scalable 路径。
• 不直接复制 PhysHOI/InterMimic 的乘法 reward 作为核心优化目标。
• 不把纯 kinematic SMPL/contact alignment 当成能打开 articulated object 的 manipulation controller。

工作约定

• 控制命令输出规模；优先使用 rg、定向 sed 和短摘要。
• 每完成一段有意义的代码阅读或论文阅读后，先更新本文档，再继续下一步。
• 区分已确认的代码事实和假设。
• 不覆盖用户无关改动。当前 worktree 已经是 dirty 状态。

用户目标

建立一条快速、稳健的路径，把视频重建结果转成物理上合理的 articulated human-object interaction。当前压力测试案例是 overfit 一条 open oven 轨迹。现有基于 InterMimic 的路径看起来太慢，而且不一定能稳定复现轨迹。需要定位瓶颈，并判断 OmniGrasp、HOI-FHLI、MaskedManipulator、EmbodMocap、ProtoMotions、PhysHOI 或 ArtHOI 风格系统中的哪些想法/代码可以迁移到本仓的物理实现里。

用户的重要澄清：replay 只作为调试/可视化路径。最终目标是 PD control / action-space tracking。因此 replay 产物应主要用来诊断 reference/contact/asset 问题，但提出的方法应优化或学习能在物理中产生该轨迹的控制，而不是依赖逐帧 teleport replay。

当前仓库状态

• 工作目录：/DATA/intern/hoi4d/projects/zhanbaiting/ArtHOI4D。
• worktree 里已有很多修改、删除、重命名；除非本次调研中实际触碰，否则都视为用户已有改动。
• 当前存在的相关 submodule 包括：
• InterMimic
• Omnigrasp
• PhysHOI
• ProtoMotions
• EmbodMocap
• hoifhli_release
• ArtHOI
• ArtHOI-4D-Reconstruction
• MimicKit（本次调研中加入；轻量 motion-imitation 框架，用来与 ProtoMotions/InterMimic 对比）
• 以及若干 reconstruction/body/segmentation 依赖。

目前已确认的本地事实

• 当前 pipeline 在 pipeline/physics 下有物理 refinement 层。
• Isaac/InterMimic bridge 主要位于 pipeline/physics/simulators/isaac。
• 之前观察到的默认 physics refinement config 使用 optimizer_backend: noop；这意味着主路径如果不显式切换 backend，可能运行的是 replay/check 路径，而不是实际 policy overfit。
• 之前观察到的当前 phase1a/open-oven 路径更接近 replay，而不是完整 InterMimic policy learning：
• dynamic_replay 每帧写入 human root/reference，并通过 PD target 驱动 human DOF。
• 在观察到的路径里，articulated object 是 passive 的。
• 因此，如果成功需要 policy 发现能打开烤箱的有力接触，这条 replay 路径在构造上就不够。
• 完整 InterMimic trainer 代码本地存在，但看起来使用 PPO 风格的长训练，不是项目想要的 fast single-trajectory overfit 路径。
• 搜索现有输出时发现了 replay 产物，例如 mimic_isaac_replay/import_check.json 和 manifest.json，但没有看到明确的 intermimic_trainer_run.json 或 open-oven 案例的 trained inference 产物。

早期瓶颈假设

主要瓶颈很可能不只是 “InterMimic 难复现”。当前 pipeline 似乎混合了两个不同目标：

1. 对重建 motion 做快速物理验证/replay，只用于调试。
2. 为最终系统做 PD-control/action-space tracking，使人体能主动产生 contact force 去推动 articulated object。

现有 replay 路径可以验证或暴露 mismatch，但不能作为最终答案。最终答案应通过 PD targets/actions 驱动人体关节，并让 articulated object 通过接触被动运动。PPO trainer 原理上可以学习主动控制，但对 per-video scale-up 来说太慢。

待验证的可复用设计方向

• 在 PPO 之前或替代 PPO 增加一个短时域 single-trajectory optimizer：
• 在已知轨迹上优化 residual actions / PD targets / contact assistance；
• 使用重建出的 object joint trajectory 作为 supervised target；
• 除非必要，否则避免学习泛化 policy。
• 先用 replay diagnostics 对失败类型分类：
• reference/object mismatch；
• contact timing mismatch；
• handle geometry 不可达；
• torque/friction 不足；
• reset/termination 过早杀死 episode；
• policy/training 太慢。
• 如果需要 learned prior，优先从 ProtoMotions/MaskedMimic 一类系统引入 pretrained motion/control prior 或 residual-action interface，而不是为每个视频训练新的 PPO policy。

参考仓对比：当前结论

• OmniGrasp/PHC：
• submodules/Omnigrasp/phc/env/tasks/humanoid_im.py:1075-1084 使用了和本 fork 相同的 residual PD action 思路：当 _res_action 启用时，pd_tar = ref_dof_pos + pd_action_scale * action，然后把 target clamp 到当前 simulated DOF position 周围。
• 这和本地 pipeline/physics/simulators/isaac/env/omomo_task.py 里的 resAction 路径匹配。它可以确认“围绕 reference 做 residual action”是正确 action interface，但不是一个需要直接迁移的新算法。
• PhysHOI / InterMimic：
• submodules/PhysHOI/physhoi/env/tasks/physhoi.py:1316-1454 计算 body、object、interaction-graph 和 contact-graph reward，最后用 reward = rb*ro*rig*rcg。
• 上游 InterMimic 也有相同的乘法 reward 形态（rb * ro * rig * rcg）。对于困难的 articulated-object contact，这种形式很脆弱，因为任意一个 object/contact 项变差都可能让整体信号塌掉。
• PhysHOI 的 reward components 仍然可以作为 diagnostics 使用，但直接复制 reward 不太可能解决单条 open-oven overfit 问题。
• MimicKit：
• submodules/MimicKit/mimickit/run.py:33-44 清晰分离了 env construction 和 agent construction；envs/env_builder.py 与 engines/engine_builder.py 把 task logic 和 simulator backend 分开。
• submodules/MimicKit/mimickit/envs/sim_env.py:77-89 有紧凑的 step 生命周期：apply action、step physics、再 update obs/info/reward/done。这是本地 overfit runner 可以借鉴的结构。
• submodules/MimicKit/mimickit/envs/deepmimic_env.py:63-74 和 :502-559 实现了显式 tracking-error diagnostics（root_pos_err、root_rot_err、body_pos_err、body_rot_err、velocity errors）。这比算法本身更值得移植。
• submodules/MimicKit/mimickit/envs/deepmimic_env.py:787-846 对 pose/velocity/root/keypoint 项使用 additive weighted reward，避免了 InterMimic/PhysHOI 里的 all-or-nothing 乘法形式。

已确认路径更新

• 当前 worktree 中，physics method config 已移到 configs/methods/physics/：
• configs/methods/physics/phys_refine.yaml
• configs/methods/physics/phys_refine_arthoi4d_full.yaml
• configs/methods/physics/phys_refine_smoke.yaml
• experiment config 仍包含 configs/exp/d3dhoi/oven_phys_refine.json。
• 当前 worktree 中确认存在的 Isaac runner 文件包括：
• pipeline/physics/simulators/isaac/backend.py
• pipeline/physics/simulators/isaac/rollout.py
• pipeline/physics/simulators/isaac/exporter.py
• pipeline/physics/simulators/isaac/intermimic/trainer_optimizer.py
• pipeline/physics/simulators/isaac/intermimic/tracker_optimizer.py
• pipeline/physics/simulators/isaac/intermimic/runners/step.py
• pipeline/physics/simulators/isaac/intermimic/runners/teacher.py
• pipeline/physics/simulators/isaac/intermimic/runners/trainer.py

额外已确认本地事实

• pipeline/physics/config.py 中 dataclass 默认值为 optimizer_backend="noop" 和 sim_rollout_mode="passive_rollout"，随后对 passive object 的 Isaac 默认值解析为 dynamic_replay。
• configs/methods/physics/phys_refine.yaml 和 configs/methods/physics/phys_refine_arthoi4d_full.yaml 当前都设置了 phase1a.optimizer_backend: "noop" 和 sim_rollout_mode: "dynamic_replay"。
• pipeline/physics/runtime/registry.py 只支持 noop、intermimic_tracker 和 intermimic_trainer。
• pipeline/physics/simulators/isaac/intermimic/runners/trainer.py 使用 num_envs 和 max_iterations，注释也说明上游默认是真正的 InterMimic PPO training setup。这对 per-video 使用来说很可能太慢。

代码阅读笔记：本地 pipeline

• pipeline/physics/main.py:110-131：run_physics_pipeline 构建 simulator、import case、运行 simulator rollout，然后根据 phase1a.optimizer_backend 构建 optimizer。若 optimizer_backend="noop"，唯一物理结果就是 pre-optimizer rollout。
• pipeline/physics/simulators/isaac/backend.py:22-49：Isaac rollout dispatch 有三种模式：
• kinematic_replay：human 和 object 都被 teleport，没有物理 object tracking。
• passive_rollout：object passive，human DOF 仍被 replay。
• dynamic_replay：object passive，human DOF 使用 PD target，但 root 仍每帧 teleport。
• pipeline/physics/simulators/isaac/intermimic/runners/step.py:272-281：subprocess diagnostics 使用同样语义；dynamic_replay 只是在有限意义上是 “human/object physics”：human DOF 由 PD 驱动，object 是 passive。
• configs/methods/physics/phys_refine.yaml:34-46 和 configs/methods/physics/phys_refine_arthoi4d_full.yaml:16-28：当前 method config 明确以 optimizer_backend: "noop" 运行 Isaac dynamic_replay。
• configs/exp/d3dhoi/oven_phys_refine.json:1-24：open-oven physics experiment 指向 configs/methods/physics/phys_refine.yaml，所以除非其他地方 override，否则继承 noop。

代码阅读笔记：InterMimic trainer/tracker

• pipeline/physics/simulators/isaac/intermimic/tracker_optimizer.py:78-91：intermimic_tracker 要求 passive_object=True 和 passive object dynamics；它拒绝 kinematic replay。
• pipeline/physics/simulators/isaac/intermimic/tracker_optimizer.py:332-357：tracker 通过 teacher/inference subprocess 运行，num_envs=1，并注明 teacher tracker 不使用 play_dataset_step；object 是 passive dynamic actor。
• pipeline/physics/simulators/isaac/intermimic/trainer_optimizer.py:83-127：trainer plan 创建 trainer/rl_train_dir，写入 intermimic_trainer_run.json，然后先运行 RL training 再运行 inference。
• pipeline/physics/simulators/isaac/intermimic/trainer_optimizer.py:223-239：InterMimicTrainerOptimizer 默认 num_envs=1024、max_iterations=10000，写 plan、阻塞训练、再运行 trained inference。这不是轻量 per-video optimizer。
• pipeline/physics/simulators/isaac/intermimic/runners/trainer.py:65-81：training runner 默认选择上游 omomo_train_new.yaml，除非 INTERMIMIC_USE_TEST_CFG=1。
• pipeline/physics/simulators/isaac/intermimic/runners/trainer.py:204-215：max_iterations 被解释为 teacher checkpoint epoch 之后的 additional epochs，而不是短轨迹 optimizer budget。
• pipeline/physics/simulators/isaac/intermimic/runners/trainer.py:232-245：已经有 reset debugging、articulated reward disabling、residual action 和 zero mu initialization 的环境开关。这些是有用的 debug lever，但不改变 PPO training cost 这个根本问题。
• submodules/InterMimic/isaacgym/src/intermimic/data/cfg/omomo_train_new.yaml:3-18：上游训练使用 numEnvs: 4096、episodeLength: 300、stateInit: Hybrid、rolloutLength: 300。
• submodules/InterMimic/isaacgym/src/intermimic/data/cfg/omomo_train_new.yaml:30-32：默认启用 early termination。
• submodules/InterMimic/isaacgym/src/intermimic/data/cfg/train/rlg/omomo.yaml:51-74：PPO 设置为 learning_rate: 2e-5、max_epochs: 100000、horizon_length: 32、minibatch_size: 16384，并依赖 teacher checkpoint path。
• submodules/InterMimic/isaacgym/src/intermimic/env/tasks/intermimic.py:890-899：reward 是乘法形式：rew = rb * ro * rig * rcg；reset 组合了 human/object kinematic mismatch、interaction graph mismatch 和 contact reset。
• submodules/InterMimic/isaacgym/src/intermimic/env/tasks/intermimic.py:970-1045：human reset 和 object reset 都会在 mean point/keypoint error > 0.5 时触发。对于困难 articulated contact，这会在早期发散后杀死 exploration。
• submodules/InterMimic/isaacgym/src/intermimic/env/tasks/intermimic.py:1114-1188：play_dataset_step 会把 object root、human root/DOF teleport 到 reference，然后 simulates once。这是 dataset/replay/debug 路径，不是 learned contact control。

代码阅读笔记：PD control 路径

• 最终系统不应依赖 play_dataset_step replay，除 diagnostics 外。
• pipeline/physics/simulators/isaac/env/humanoid_base.py:399-408：正常 InterMimic control path 调用 pre_physics_step(actions)，把 actions 映射为 PD targets，并调用 set_dof_position_target_tensor。
• pipeline/physics/simulators/isaac/env/humanoid_base.py:464-466：上游 absolute PD action mode 是 pd_tar = pd_action_offset + pd_action_scale * action。
• pipeline/physics/simulators/isaac/env/omomo_task.py:621-645：本仓 fork 增加了 resAction；启用时 pd_tar = ref_dof_pos + pd_action_scale * action，然后将 target clamp 到当前 sim DOF ± pi/2。对 fast single-trajectory overfit 来说，这是正确 action interface，因为 policy/optimizer 只需要在重建 reference 周围优化 residual。
• pipeline/physics/simulators/isaac/env/omomo_task.py:647-684：articulated target cases 在发送 humanoid PD targets/actions 时 pad K 个 object DOF；object DOF 保持 drive-mode none/passive。
• pipeline/physics/simulators/isaac/env/omomo_task.py:1252-1285：articulated rewards 包含 joint qpos reward rj；moving-part pose reward rmp 作为 diagnostic 计算，但不再乘进 total reward。Total reward 是 rb * ro * rj * rig * rcg。
• pipeline/physics/simulators/isaac/env/omomo_task.py:1582-1611：compute_obj_joint_reward 直接根据 sidecar reference 跟踪 passive articulated target DOF，权重 key jq 默认 5.0。
• pipeline/physics/simulators/isaac/env/omomo_task.py:1671-1711：compute_obj_movingpart_reward 针对 K=1 计算 moving-part world-pose reward 作为 diagnostic。这对 open-oven 调试很有用，因为 root pose 可能固定，而 root/object-point rewards 可能漏掉 hinge motion。
• pipeline/physics/simulators/isaac/env/omomo_task.py:1713-1825：play_dataset_step 有 phase1a_dynamic_human 模式，使用 reference DOF 作为 PD targets，但仍 teleport human root。这仍然是 replay/open-loop tracking，不是最终的 policy/control overfit。

用户澄清后的更新瓶颈

最终缺失的不是“让 replay 更好”。本仓已经有正确的 PD action interface（resAction）和 articulated reward hooks（rj、diagnostic rmp）。缺失的 scalable 方法是一个短的 single-trajectory action/PD-residual optimizer，直接使用该 interface，而不是为每个视频启动长 PPO training。

具体设计目标：

• 输入：重建 reference motion，加 object joint sidecar。
• 变量：一段短时域 humanoid residual actions 或 PD residual targets，第一版最好只优化 upper body / hands。
• 仿真：object/hinge passive，humanoid DOF 由 PD 驱动，reset 后不逐帧 DOF teleport。
• 目标：监督式跟踪 human body/key joints、object joint qpos、moving-part pose、contact schedule、action magnitude/smoothness。
• 输出：物理执行后的 rollout，加 residual-action trace；以后可选 distill 到 policy，但 per-video reconstruction 不需要。

流程备注

• git -C submodules/InterMimic status 当前会因为 Git dubious ownership guard 失败。如果需要 submodule status，先运行 git config --global --add safe.directory /DATA/intern/hoi4d/projects/zhanbaiting/ArtHOI4D/submodules/InterMimic。

已完成本地阅读

• configs/methods/physics/phys_refine.yaml
• configs/methods/physics/phys_refine_arthoi4d_full.yaml
• configs/exp/d3dhoi/oven_phys_refine.json
• pipeline/physics/config.py
• pipeline/physics/main.py
• pipeline/physics/runtime/registry.py
• pipeline/physics/simulators/isaac/backend.py
• pipeline/physics/simulators/isaac/intermimic/trainer_optimizer.py
• pipeline/physics/simulators/isaac/intermimic/tracker_optimizer.py
• pipeline/physics/simulators/isaac/intermimic/runners/step.py
• pipeline/physics/simulators/isaac/intermimic/runners/trainer.py
• output/*oven*/*phys* 和 output/*oven*/mimic_isaac_replay 下的相关输出文件
• submodules/Omnigrasp/phc/env/tasks/humanoid_im.py
• submodules/PhysHOI/physhoi/env/tasks/physhoi.py
• submodules/MimicKit/mimickit/run.py
• submodules/MimicKit/mimickit/envs/*
• submodules/MimicKit/mimickit/engines/*
• submodules/EmbodMocap/docs/embod_mocap.md
• submodules/EmbodMocap/embod_mocap/config*.yaml
• submodules/EmbodMocap/embod_mocap/processor/optim_motion.py
• submodules/EmbodMocap/embod_mocap/processor/align_contact.py

已完成参考阅读更新

• ProtoMotions / MaskedMimic：已读。结论是可借鉴模块化 control/obs/reward/evaluator、fixed-motion evaluation、action smoothing 和 predicted motion export，不建议直接迁移成 per-video HOI policy trainer。
• HOI-FHLI：已读。结论是它有 hand-object relative tracking reward 和 contactable-link 设计可借鉴，但物体主要是 free rigid objects，训练是 PPO/AMP 风格长训练，不解决 articulated object 被动关节控制。
• ArtHOI / ArtHOI-4D-Reconstruction：已读。结论是它们强化了 video-prior 4D articulated HOI reconstruction 这个 paper framing，但没有提供 physics-executable control。我们的贡献应该落在 reconstruction-to-simulation-ready data，而不是只做重建或只做物理 replay。

外部来源备注

• MaskedManipulator 项目页的 code button 指向 NVlabs/ProtoMotions，目前没有独立的 MaskedManipulator repo 可 clone。
• submodules/MimicKit 是从 https://github.com/xbpeng/MimicKit.git clone 的，用作轻量 motion imitation 参考。

EmbodMocap 笔记

• EmbodMocap 是 reconstruction/optimization pipeline，不是 physics-control pipeline。
• 它的 pipeline 有显式 single-sequence stages：
• docs quick start 先跑 scene/preprocess，然后 steps 6-15，最后可选 step 16 contact alignment（submodules/EmbodMocap/docs/embod_mocap.md:80-104）。
• Step 15 optim_motion 输出 optim_params.npz；step 16 align_contact 可选输出 aligned SMPL/camera artifacts（submodules/EmbodMocap/docs/embod_mocap.md:287-300）。
• config_fast.yaml 降低 voxel size、JPEG quality、COLMAP frames、keyframe counts、depth/mask workload 和 VGGT samples，以便更快迭代。这是 physics “debug/fast” mode 可借鉴的模式，不是控制算法。
• submodules/EmbodMocap/embod_mocap/processor/optim_motion.py:205-391 实现了对 SMPL 参数的分阶段 Adam 优化：
• 每个 stage 选择 active parameters（global_orient、body_pose、betas、transl）；
• loss 是 additive：reprojection、3D keypoint、joint/vertex smoothness、pose/transl smoothness、regularization、acceleration terms；
• :722-740 处的具体 schedule 是先对 global orientation/translation 做 200 iterations，再对 full pose/shape/translation 做 300 iterations。
• EmbodMocap 的优化模式直接相关：single-sequence variables、staged active parameter sets、additive losses，以及把 final scalar loss 显式保存到输出中（optim_total_loss at optim_motion.py:821-826）。
• 它不能直接满足我们的最终目标，因为：
• 它优化的是 kinematic SMPL/camera/world alignment，不是 Isaac residual actions 或 PD targets；
• 它没有 passive articulated-object dynamics、torque/contact feasibility，也没有 policy/action trace；
• contact alignment 是 global pose registration，不是能产生力的 manipulation controller。
• submodules/EmbodMocap/embod_mocap/processor/align_contact.py:233-297 只通过 annotated contact frames 优化 z-axis rotation 和 xy translation，把 contact pelvis xy 匹配到 scene contact xy。
• align_contact.py:300-394 包含一个 z-translation optimizer，使用 contact height 加 reprojection loss，但调用路径在 :511-577 被注释掉了。
• 可迁移点：
• staged optimizer config；
• additive loss logging；
• 一个 contact-alignment diagnostic pass，用来回答“human/reference 是否真的放在 handle 附近？”；
• 一个保留 core outputs、降低 reconstruction/diagnostic 成本的 fast profile。
• 不适合直接迁移的点：
• SMPLify parameter optimization 本身；
• pelvis-to-contact alignment 作为 manipulation controller；
• 认为仅靠 contact labels 就能在物理中打开 articulated object 的假设。

ProtoMotions / MaskedMimic 笔记

• ProtoMotions 是 GPU-accelerated humanoid simulation/learning framework。README 明确强调 large-scale motion learning、multi-GPU training、retargeting、sim2sim 和 generative policies。它的目标是大规模训练 tracking/generative humanoid policies，不是 per-video articulated HOI overfit。
• submodules/ProtoMotions/protomotions/envs/control/mimic_control.py:104-170 的 MimicControl.populate_context 把当前 reference state 和 future reference poses 都放进 typed context。这一点值得借鉴：我们的 overfit runner 也应该把 current ref、future ref、object joint target、moving-part target、contact schedule 作为同一份 context，而不是散落在 task 内部。
• submodules/ProtoMotions/examples/experiments/mimic/mlp.py:81-99 的 mimic reward 是多项 component 加权组合，包括 action smoothness、tracking、power 和 contact match。这里的形式比 InterMimic/PhysHOI 乘法链更适合我们的单序列调试，因为每一项可以单独看。
• submodules/ProtoMotions/protomotions/agents/evaluators/mimic_evaluator.py:132-165 在 evaluation 中支持 EMA action smoothing；:305-438 可以把 rollout 后的 predicted states/actions/contacts 打包成 MotionLib-compatible 输出。这对我们有两个启发：
• residual action trace 必须作为一等输出保存；
• 评估时要测 action smoothness，不然 CEM/MPPI 很容易产生抖动动作。
• submodules/ProtoMotions/protomotions/envs/terminations/tracking.py 提供了 mean/max body position/orientation error kernels，可作为本地 diagnostics 模板。
• 不建议直接迁移 ProtoMotions 的完整训练栈：
• 它面向大规模 humanoid motion tracker，不包含我们需要的 articulated object passive joint、handle contact、moving-part pose 和 object qpos supervision；
• 它的 pretrained model skeleton/robot format 与本仓 OMOMO/SMPL-X/InterMimic fork 不一定一致；
• 为每条生成视频跑泛化 policy training 与项目的 scalable data-generation 目标不匹配。
• 可迁移的是设计层：
• typed context / componentized reward；
• fixed-motion evaluation；
• action smoothing metrics；
• predicted rollout export；
• failed-motion sampling/diagnostics 思路。

HOI-FHLI 笔记

• HOI-FHLI 的主任务是从 human-level instructions 生成 human-object interaction motion。它有一个 physics_tracking 子目录，确实做 IsaacGym tracking，但它不是 articulated-object manipulation。
• submodules/hoifhli_release/physics_tracking/config_tracking.py:1-80 显示训练配置使用 TrackingHumanoid，episode_length=500，并设置 max_epochs=1000000。这仍是长 PPO 训练路径，不是 fast overfit。
• submodules/hoifhli_release/physics_tracking/env.py:1148-1213 的 reward 是 additive mixture：orientation、position、hand/object relative term 和 acceleration penalty，而不是乘法链。它特别重视 wrist/finger 相对 object 的几何关系，这对 open-oven handle 接触目标有参考价值。
• config_tracking.py:52-74 对 wrist/finger 和 foot acceleration/contact 设了不同权重。这个思想可以迁移为本仓的 body/action mask：open-oven 第一版重点优化 shoulder/elbow/wrist/hand，对 pelvis/lower body 只做稳定约束。
• 局限：
• config_tracking_seq1_cube.py 加的是多个 largebox_*.urdf，对象是 free rigid boxes，不是 revolute/prismatic articulated object；
• reward 跟踪的是 object rigid-body pose，没有 object joint qpos / moving-part hinge target；
• PPO/AMP 训练预算很大，不适合 per-video scale-up。
• 可迁移点：
• hand-object relative pose reward；
• contactable links / bad contact termination；
• hand/finger 权重设计；
• acceleration penalty 和 smoothness penalty。
• 不可迁移点：
• 对 free rigid boxes 的 object tracking 设计；
• 长 PPO training loop；
• 把 generated motion 直接当 expert motion 训练 tracking policy 的整体路径。

ArtHOI / ArtHOI-4D 笔记

• submodules/ArtHOI/README.md:1-3 标题是 “Articulated Human-Object Interaction Synthesis by 4D Reconstruction from Video Priors”；:41 的 TL;DR 是 zero-shot synthesis of realistic human interactions with articulated objects。这个 framing 对我们的 paper 很重要：ArtHOI 把“视频先验 + 4D 重建 + 合成交互”作为主线，而不是把重点放在物理化。
• submodules/ArtHOI/README.md:104-124 的 custom data 输入包含 images、human/object masks、CoTracker、HMR4D/GVHMR 等 priors。这和本仓 videogen/recon 的设计非常接近。
• submodules/ArtHOI/src/train.py:306-425 的 stage1 主要优化 object dynamics/appearance：object mask、2D tracks、object axis 等；:427-480 的 stage2 优化 human：human smooth、3D keypoints、foot sliding、collision。它是 differentiable visual/kinematic reconstruction，不是 physics-control。
• submodules/ArtHOI/src/models/objectgs.py 当前公开代码的 object Gaussian articulation 更像 dynamic/static Gaussian part transform，N_joints=1，没有 Isaac/MuJoCo articulated dynamics、joint limit、contact force 或 action trace。
• submodules/ArtHOI-4D-Reconstruction/README.md:1-12 说明另一个 ArtHOI 方向是 monocular 4D reconstruction of hand-articulated-object interactions，并且代码仍是 coming soon。它更能证明 reconstruction 问题本身重要，但不能给本项目的 physics execution 方案。
• 对本项目的定位启发：
• 不能把题目写成只做 Fast Physicalization，因为 video/videogen/recon 是核心贡献之一；
• 也不能写成只做 Reconstructing ... from Videos，因为最终目标是 simulation-ready physics data；
• 更准确的主线是：从 video priors / generated videos 产生 articulated HOI reference，再通过 test-time physics adaptation 变成可执行数据。

本仓接口核对

• README.md:3-14 已经写明本仓是完整流程：生成/重建 4D HOI，做物理一致性修正，并导出 Isaac Gym / InterMimic 风格 mimic；这里的 mimic 不是简单 replay，而是 tracking policy 通过真实物理交互复现目标轨迹。
• README.md:20-27 的四阶段是 videogen -> recon -> phys_refine -> mimic。因此 paper 目标不能被压缩成“物理化一个已有视频”；它包含 scalable video prior/data generation 和 reconstruction。
• pipeline/reconstruction/optimization/run.py:812-855 的 final result.pt 明确输出 object.pose、object.joint_values、object.scale 以及 human SMPL-X 参数；:1005-1006 说明这是后续阶段消费的最终 schema。单序列 overfit 的输入应该直接吃这些字段，而不是另造 reference 格式。
• pipeline/physics/simulators/isaac/rollout.py:414-447 当前 dynamic_human=True 仍然是“root 每帧 teleport，DOF 走 PD target”的半物理 replay；dual-rigid 路径还不支持 dynamic human。这证明当前 phase1a 还不是最终 action-space tracking。
• pipeline/physics/simulators/isaac/intermimic/runners/step.py:185-196 已经把 human/object drive semantics 记录到 diagnostics；:200-214 能读出 articulated target 的真实 joint qpos。这是很好的 diagnostics 基础。
• 当前桥接层已有 articulated dual-rigid / moving-part proxy 逻辑，但文档注释也说明第一版只能处理 single active joint。这与 open-oven 压力测试匹配，但不能宣称已经解决任意多关节 articulated object。

最终 RL / Optimization 方案，v1

最合理的第一版不应叫“为每条视频训练 PPO policy”。更准确的是：test-time single-sequence residual action optimization。它是 action-space optimization，可被写成 test-time RL / black-box trajectory optimization，但工程上先用 CEM/MPPI 比 PPO 更合适。

核心假设

• 输入 reference 来自本仓 result.pt：
• human root/body/hands；
• object root pose；
• object articulated joint_values；
• moving-part pose，可由 articulated FK 或现有 proxy 逻辑得到；
• hand/object contact schedule 或 handle proximity；
• camera/world/support metadata。
• 仿真对象：
• humanoid 由 PD/action-space control 驱动；
• articulated object 是 passive dynamics；
• object root 对 articulated case 应该固定或按 asset 语义处理，door/part 通过 hinge/prismatic joint 被 contact 推动。
• 优化变量：
• 每帧 residual PD action a_t；
• action interface 使用现有 resAction 思想：pd_target_t = q_ref_t + scale * a_t；
• 第一版只开放 upper body、arms、wrists、hands，lower body/root 只做稳定与 tracking 约束；
• 不直接优化 object joint；object joint 必须由接触和 passive dynamics 产生。

为什么不是直接 PPO

• InterMimic trainer 默认是长 horizon、大 env 数、长 epoch 的 PPO 风格训练；本地默认甚至是 max_iterations=10000 量级。这不适合对每条 videogen/recon 序列做 scale-up。
• 目标不是得到一个泛化 policy，而是把一条已知 reference 变成可执行物理 rollout。这个问题更接近 shooting / trajectory optimization。
• 对 open-oven，真正需要探索的是短时间窗里手如何接触 handle 并推动 hinge。CEM/MPPI 可以用几十到几百个 env 并行评估 residual action sequence，直接按 object joint/moving-part error 排序，比 PPO 的 credit assignment 更直接。

推荐 schedule

1. Preflight replay diagnostics
2. 跑 kinematic/passive/dynamic replay，只分类问题，不当最终方法；
3. 检查 wrist/hand 是否到 handle 附近；
4. 检查 reference object joint axis、limit、初始 qpos、moving-part FK 是否合理；

5. 检查 passive object 的 mass/friction/collider 是否允许被推开。

6. Short-horizon residual search

7. 以 16-32 帧为窗口；
8. 每个窗口初始化 action mean 为 0，std 小值；
9. 用 CEM/MPPI 采样 N=64~512 条 action sequence；
10. 并行 rollout，按 additive loss 排名；
11. top-k 更新 action mean/std；

12. 下一个窗口 warm-start 前一个窗口末端状态和 action tail。

13. Full-sequence polish

14. 把滑窗得到的 residual action trace 拼起来；
15. 全序列或长窗口再跑少量 CEM/MPPI iterations；

16. 重点压 action smoothness、contact stability、object joint final error。

17. 可选 PPO fine-tune

18. 只有当 CEM/MPPI 能稳定找到接触但动作仍抖或长期 rollout 漂移时再启用；
19. PPO 不从零开始，而是用 CEM trace 做 behavior cloning / mean-action initialization；
20. 训练目标仍是单序列，不作为默认 scalable 路径。

Loss 设计

必须使用 additive loss，而不是 rb * ro * rig * rcg 乘法 reward。

• L_human_body：root/body/key joints tracking，root 先作为强 tracking 项，不靠逐帧 teleport 当最终方法。
• L_hand：wrist/finger/hand keypoints tracking，权重大于躯干。
• L_obj_joint：object joint_values 与 reference 的 qpos error，open-oven 重点看 hinge angle。
• L_moving_part：door/panel moving-part world pose error；它比 whole-object root 更能反映 articulation 是否成功。
• L_contact：reference contact frames 内手到 handle/contact region 的距离；非 contact frames 用弱 no-contact / penetration penalty。
• L_action：residual action L2，避免偏离 reference 太多。
• L_smooth：action rate / acceleration penalty，防止黑盒搜索产生高频抖动。
• L_safety：fall、bad ground contact、penetration、过大 contact force 或 joint-limit violation。

诊断上每一项都要逐帧输出。最终报告至少应有：

• body tracking error；
• wrist/hand-to-handle distance；
• object joint qpos error；
• moving-part pose error；
• contact success frames；
• action magnitude/smoothness；
• failure reason classification。

root 与 replay 边界

• Debug 阶段可以允许 root/window-start reset，甚至允许 root kinematic anchor，用来隔离手和物体接触问题。
• 论文最终指标不能依赖逐帧 root teleport。最终 rollout 应从初始状态出发，通过 residual PD actions 执行；如果需要窗口 reset，只能作为 ablation/debug 或 local adaptation trick 明确说明。
• 如果完全 free-root 导致 humanoid 长时漂移，可以采用“两级结果”：
• diagnostic-controlled：root 受控，用来验证 reference/contact/asset；
• physics-executable：root 不逐帧 teleport，用来作为主结果。

成功判据

对 open-oven，不能只看 render 像不像。至少要同时满足：

• human hands 在正确时间接触 handle/door region；
• passive hinge qpos 随 contact 变化，而不是从 reference 直接写入；
• final hinge angle 接近 reconstructed/reference target；
• moving-part pose 与 reference 接近；
• action trace 平滑且 residual magnitude 不异常；
• 没有明显穿透、摔倒或错误 ground contact。

下一步只读分析建议

• 继续精读 pipeline/physics/simulators/isaac/env/omomo_task.py 的 normal pre_physics_step 与 play_dataset_step 差别，明确怎样从 replay 路径切到真正 action rollout。
• 核对 articulated asset 在 Isaac 里的 joint axis、limit、drive mode、collider 和 mass/friction 是否和 MuJoCo/reconstruction reference 一致。
• 为 open-oven 写一份 failure taxonomy 表：reference error、asset error、contact geometry error、control error、optimizer error。