Visual Human Contact Refine Plan¶

日期：2026-04-24

Historical/provisional design record

本页保存 2026-04 的问题分析与候选 implementation roadmap，不是当前论文 experiment contract，也不表示未勾选项仍是正式承诺。当前状态与 formal gate 以 Paper Readiness、 Reconstruction metric review 和 Project Guide 为准。

本文整理当前 oven b009_0001 case 中“visual reconstruction 的 human contact 不准”问题、为什么 phys_refine 很难兜底、相关工作怎么处理遮挡与 contact 不准、以及下一阶段应如何实现 visual-side human/contact refine。

1. 结论先行¶

当前 pipeline 的主要瓶颈已经不是 object articulation，而是：

object 侧已经基本恢复正确
motion onset ≈ 39
peak articulation ≈ 59.57°
主体轨迹先增后减
但 human 侧仍然几乎直接沿用 preprocess 阶段的 GVHMR + hand refiner 结果
对 oven 这种第三视角、全身 motion、强遮挡的 case，这会导致 active hand 长时间“脱空”
phys_refine 收到的是错误的 human/contact prior，因此很难通过后端物理优化补救

因此，下一步最高优先级不应继续单独调 phys_refine，而应先在 track_refine 之后加入一层：

visual_human_contact_refine

它的目标不是让 visual 直接物理正确，而是先把：

active hand 的接触位置
active arm chain 的时序
人与门把/门边的几何关系

拉回到视觉上合理的范围，然后再把结果送给 phys_refine。

2. 当前问题为什么是结构性的¶

2.1 recon 导出的 human 其实没有被 object-conditioned refine¶

当前 result.pt 的 human 状态来自 preprocess motion，而不是 object 优化后再回头修过的人体：

target 对应实现：pipeline/reconstruction/optimization/solver/trainer.py（旧只读 checkout 的 line 195 审计）

在 build_result() 里：

object 使用优化后的 object_state
但 human 直接写入 context["smpl_incam"]["body_pose"]
left_hand_pose / right_hand_pose 也直接来自 context["smpl_incam"]

也就是说当前 visual pipeline 近似是：

GVHMR / DynHaMR
    ↓
object global_opt / joint_search / track_refine
    ↓
直接导出 result.pt

而不是：

GVHMR / DynHaMR
    ↓
object 优化
    ↓
根据 object state 再修 human
    ↓
导出 result.pt

2.2 preprocess hand refine 只 merge MANO，不解决 object-conditioned contact¶

target 对应实现：pipeline/reconstruction/preprocess/human/gvhmr.py（旧只读 checkout 的 line 720 审计）

现有 hand refine 的作用是：

用 HaMeR / DynHaMR 结果 merge 到 SMPL-X hand pose
提高手部自身姿态细节

但它并不会：

根据 object articulation 修 wrist / elbow / shoulder
根据 handle 位置把手拉回接触区
显式处理 object occlusion 下的观测缺失

所以这一步只能改善 hand pose prior，不能解决 left hand far from oven handle 这种 interaction-aware 几何错误。

2.3 现有 physics human refine 虽然能拉近手，但已经太晚¶

当前 phys_refine 里其实已经有一套 human active-chain refine：

target 对应实现：pipeline/physics/refine/human_dof.py（旧只读 checkout 的 line 69 审计）

它会根据 contact targets 去修：

human_root_transl_world
human_body_pose
human_left_hand_pose
human_right_hand_pose

但是它发生在 physics 阶段，并且只能在错误 visual prior 之上补救。

对于当前 oven case，现成结果已经说明它“能拉近，但不够”：

旧只读证据：ArtHOI4D/output/bench_d3dhoi_oven_ours_b009_0001_track3d/recon/output/track3d/summary.json
motion_onset_frame = 39
hinge_max_deg = 59.5668
旧只读证据：ArtHOI4D/output/bench_d3dhoi_oven_ours_b009_0001_track3d/phys_refine/physics_fit.json
human_refine.left.mean_dist_before = 0.2919
human_refine.left.mean_dist_after = 0.0729
human_refine.right.mean_dist_before = 0.3887
human_refine.right.mean_dist_after = 0.0460
mean_root_delta_xy = 0.2
max_root_delta_xy = 0.2
contact_ratio = 0.0
rmse_to_recon = 0.4165
max_abs_diff_to_recon = 0.9700

这些数值说明了三个问题：

physics human refine 已经把 root XY 拉到了上限 0.2m
手部虽然被拉近了 target，但仍没有形成稳定真实接触，contact_ratio = 0
object rollout 与 visual articulation target 仍然偏差很大

也就是说，它现在更像是在“补救一个坏的输入”，而不是“在一个好输入上做物理修正”。

2.4 当前 interaction 还被错误地当成双手问题¶

从同一个 physics_fit.json 可以看到：

enabled_hands = ["left", "right"]
左右手都在 113 帧 active

但这个 case 的主导 interaction 是左手拉 oven 门。右手和身体反而是遮挡源之一。

这进一步说明：

active hand detection 现在还不够保守
如果 visual 阶段不先把“谁在接触、接触哪里”做清楚，physics 阶段会收到过于宽松、甚至错误的双手监督

3. 当前相关工作的启发¶

下面只列和这个问题最相关的工作，不做无关综述。

3.1 ArtHOI¶

论文：ArtHOI: Articulated Human-Object Interaction Synthesis by 4D Reconstruction from Video Priors
https://arxiv.org/abs/2603.04338
https://arthoi.github.io/
旧只读本地代码审计：models/ArtHOI/src/train.py line 195

对我们最重要的结论：

human 和 articulated object 在 monocular 下联合优化很不稳定
因此它采用 decoupled reconstruction
先恢复 object articulation
再根据 object state 合成人体 motion

本地代码里也能看到同样思路：

先用 object motion 得到 contact_mask
再构造 contact_time_region
然后在 human stage 里使用：
human_3dkpt
foot_sliding
collision

这和我们现在最缺的一层完全一致：object-conditioned human refine。

3.2 CARI4D¶

论文：CARI4D: Category Agnostic 4D Reconstruction of Human-Object Interaction
https://arxiv.org/abs/2512.11988
https://nvlabs.github.io/CARI4D/
旧只读本地代码审计：learning/training/opt_refineout.py line 487

对我们最重要的结论：

contact 不准时，不能只靠 foundation model 的初值
需要额外 refinement，把：
j2d
contact
silhouette
penetration
temporal smoothness

联合起来优化

这说明 contact 不应被当作单独 post-process 标签，而应成为 visual refinement 的主约束之一。

3.3 GVHMR¶

论文：World-Grounded Human Motion Recovery via Gravity-View Coordinates
https://arxiv.org/abs/2409.06662
https://zju3dv.github.io/gvhmr/

它对我们更像是：

一个很好的 human motion initialization
但不是 contact-aware HOI solver

GVHMR 的长处是 world-grounded human motion，本来就不是“物体交互对齐”。因此拿它直接当最终 HOI human state，本身就是超出它设计目标的。

3.4 MoRo¶

论文：Masked Modeling for Human Motion Recovery Under Occlusions
https://arxiv.org/abs/2601.16079
https://openreview.net/forum?id=bKPBJHONz6

对我们最重要的启发：

强遮挡下，纯回归式 monocular human motion 很脆弱
masked modeling / generative prior 对 occlusion 更鲁棒

对当前任务的直接含义是：

对于 oven 这类重遮挡 case，不应盲信 preprocess 的 deterministic human pose
visual refine 里必须显式引入 visibility-aware weighting，而不是把每一帧的 hand reprojection 一视同仁

3.5 PromptHMR¶

论文：PromptHMR: Promptable Human Mesh Recovery
https://arxiv.org/abs/2504.06397
https://is.mpg.de/ps/publications/phmr-2025

对我们最重要的启发：

困难场景下，human pose recovery 可以利用额外 side information
这种 side information 可以是：
spatial prompt
semantic prompt
interaction label

对应到我们的任务里，object/contact 本身就应该成为 human refine 的 prompt 或 side information。

3.6 OccNeRF¶

论文：Rendering Humans from Object-Occluded Monocular Videos
https://arxiv.org/abs/2308.04622
https://cs.stanford.edu/~xtiange/projects/occnerf/

对我们最重要的启发：

处理 object-occluded human 时，visibility prior 必须显式建模
否则 occluded region 会被 naive regression 带偏

虽然 OccNeRF 是 human rendering，不是 HOI motion reconstruction，但对我们非常 relevant：

当前 left hand 正是被 body/right-hand/object 多重遮挡影响
因此 visual human refine 必须显式区分 visible / occluded frames

3.7 THO¶

论文 / 项目：End-to-End Spatial-Temporal Transformer for Real-time 4D HOI Reconstruction
https://nianheng.github.io/THO-project/

对我们最重要的启发：

4D HOI reconstruction 要显式建模：
human-object contact
continuous interaction dynamics
temporal coherence

即使我们不采用它的网络结构，至少也应把：

contact prior
temporal prior
interaction-aware refinement

作为 visual stage 的核心组成，而不是事后补丁。

3.8 4DHOISolver / Open4DHOI¶

论文：Efficient and Scalable Monocular Human-Object Interaction Motion Reconstruction
https://arxiv.org/abs/2512.00960
https://wenboran2002.github.io/open4dhoi/

对我们最重要的结论：

精确 contact 预测在 monocular HOI 中仍然是未解决问题
他们甚至需要 sparse human-in-the-loop contact annotation 才能把问题约束住

这对我们是一个很重要的现实提醒：

不要把“仅凭 preprocess human motion 自动恢复精确 hand contact”当作默认成立
我们更合理的目标是：
先做 coarse-but-correct 的 visual contact refine
再让 physics 去补细节和接触力

4. 我们应该新增什么模块¶

建议新增：

visual_human_contact_refine

插入位置：

global_opt / joint_search / track_refine
    ↓
visual_human_contact_refine
    ↓
trainer.save_result()

这一步只改 human，不再改已经稳定下来的 object articulation。

5. 这个模块的最小可用设计¶

5.1 输入¶

object articulation result
当前 track_refine 输出的 joint_values
当前 object world pose
human initialization
GVHMR 的 body_pose / root_orient / root_transl
DynHaMR/HaMeR merge 后的 hand pose
contact prior
D3D-HOI asset 的 contact_vertices
object motion onset / interaction window
hand visibility / 2D keypoint confidence / mask overlap

5.2 只优化哪些自由度¶

第一版不要动全身，只优化 active chain：

root XY，小范围 Z
spine / clavicle 小范围补偿
active-side shoulder
active-side elbow
active-side wrist
active-side hand global orient

先不要：

改腿
改另一侧手臂
改大范围 torso

否则很容易把整个人拖坏。

5.3 active hand 应该怎么定¶

当前 phys_refine 里双手同时 active 明显过宽。

建议在 visual refine 里先做更保守的 active-hand selection：

对每一帧计算左右手到 object contact region 的距离
结合速度方向和接触窗口内的一致性
加上 visibility 置信度
得到主导手 active_hand

对 oven case，预期应优先判成 left。

5.4 contact target 应该怎么建¶

contact target 不应该是单个点，而应是逐帧的 soft region：

优先取 asset 自带 contact_vertices
根据 object articulation 和 link pose，把它们变到世界坐标
再做局部采样 / top-k 邻域，形成 soft target region
输出：
target_world_points[t, k, 3]
target_valid[t, k]
target_weight[t, k]

这样可以避免“强行把 hand 拉到一个错误点上”。

5.5 loss 设计¶

建议第一版只做这些：

`L_contact_pull`¶

interaction window 内，把 active wrist / palm / fingertips 拉向 object target region。

`L_j2d_visible`¶

只对可见且高置信的 body / wrist / hand keypoint 做 2D reprojection。

`L_prior`¶

限制不要偏离原始 GVHMR / DynHaMR 太远。

`L_temporal`¶

对 active chain 的速度 / 加速度做平滑。

`L_penetration`¶

前臂 / 手掌与 oven 门之间的 coarse penetration penalty。

`L_no_contact_motion`¶

非 interaction window 不要被 contact target 吸过去。

5.6 visibility-aware weighting¶

这是第一版成败关键。

每帧权重不应固定，而应由以下信号综合决定：

keypoint 2D confidence
hand refiner 是否成功
human/object mask overlap
当前 frame 是否被 object / body 遮挡
reprojection residual 是否异常

推荐规则：

可见帧：以 L_j2d_visible + L_contact_pull 为主
重遮挡帧：降低 L_j2d_visible，提高 L_prior + L_temporal + L_contact_pull(soft)

6. 为什么优先复用现有 human_refine，而不是从零写¶

当前 repo 已经有可复用的 active-chain human refine 实现：

pipeline/physics/refine/human_dof.py
pipeline/physics/refine/human_refine.py

推荐做法不是完全重写，而是：

把它的“局部 human chain 优化”能力前移到 visual stage
只替换 target 构造方式与 loss 组合

从：

physics rollout → contact target → human refine

改成：

visual object state → contact target → human refine

这样可以：

复用已有 SMPL-X FK / active chain solver
避免在 physics 阶段之前完全没有 human correction
降低实现成本