any4d_tail_forward+dense.value[:,3](LGM 전용)가 native depth 아님 → pts3d_cam[...,2]로 교체, AbsRel 1.77→0.27 (6.6×)scripts/viser_compare.py)VGGRPO Phase 4 (RL fine-tuning)에서 reward path를 설계할 때, depth backbone을 무엇으로 쓸지 결정이 필요하다. 기존 방향은 LGM fine-tune 후 연결이었으나, 2026-05-12에 "LGM 제거, direct-RGB backbone에 decoded 3-cam 입력"으로 방향을 전환했다. 후보 backbone은 4개: Any4D(4D/temporal, DINOv2 기반), DA3(multi-view, cross-view attention), VGGT(Facebook, 1B), VGGT-Ω(facebookresearch/vggt-omega, CVPR 2026).
목표: "A 방식" — 4개 모델을 동일 조건(LGM/connector/LoRA/VAE latent 전부 제거, RAW RGB 입력)으로 held-out RoboCasa 3-cam(24 task × 2 demo = 48 clips, 32 frames × 3 cam = 96 views/clip)에서 동일 depth metric으로 비교.
scripts/eval_backbones_rgb.py)
eval_lgm_3way.py의 harness (build_gt, depth_metrics_one per-clip median-ratio scale align,
select_holdout_indices, aggregation/markdown)를 재사용. VAE/connector/LoRA 경로는 모두 제거하고
각 모델의 native RGB inference API만 호출.
build_gt의 [cam*T+t] 순서·(294,518) 해상도로 정렬 후 metric.
모델별 native API 요약:
초기 smoke에서 Any4D AbsRel = 1.63으로 비정상적으로 높았다. tmp/diag_any4d.py로
두 경로를 나란히 비교:
any4d_tail_forward + pred["dense"].value[:,3] → AbsRel 1.77loss_of_one_batch_multi_view() + pred["pts3d_cam"][...,2] → AbsRel 0.27any4d_tail_forward+dense.value[:,3]는 LGM connector+LoRA로 fine-tune해서
쓰던 LGM 학습 전용 wrapper였고, off-the-shelf native depth API가 아니었다.
디버깅 중 추가 버그: (1) 직접 model(views)를 autocast로 감싸면 dtype mismatch → 정식 wrapper가 amp 처리.
(2) wrapper는 no_grad 미적용 → .detach() 필요.
facebook/VGGT-Omega는 Meta gated 모델. 머신 기본 계정 dongjin630은 미승인이라 keh0t0 계정으로 승인 후
login 노드에서 weight(vggt_omega_1b_512.pt, 4.58GB)를 공유 NAS HF 캐시(/home/nas_main/.cache/huggingface/hub/)에 다운로드.
build_vggt_omega를 cache-first로 개선: local_files_only=True 먼저 → 실패 시 HF_TOKEN 인증 → 둘 다 실패 시 graceful skip.
한 번 캐시되면 worker는 HF_TOKEN 없이 캐시에서 로드.
tmp/viser_compute.py: 1 clip의 몇 timestep에서 GT+4모델 depth를 GT 카메라(K_native, cam→world pose)로
unproject → 카메라별(exo1/exo2/wrist) pointcloud(xyz+rgb) npz 저장.
scripts/viser_compare.py: npz 로드 → viser 서버. source 토글, camera 토글, timestep 드롭다운, color 모드(rgb/camera별 색상), point size 제어.
cam convention 자동선택(GT cam0↔cam1 NN residual로 raw vs opengl→opencv flip 판정).
| 경로 | AbsRel ↓ | RMSE ↓ | δ<1.25 ↑ | scale |
|---|---|---|---|---|
OLD (dense.value[:,3]) | 1.7674 | 0.4974 | 0.267 | 0.48 |
NATIVE (pts3d_cam[...,2]) | 0.2678 | 0.1570 | 0.746 | 0.54 |
held-out: 24 task × 2 demo = 48 clips, 32 frames × 3 cam = 96 views/clip. per-clip median-ratio scale align 후 집계.
| Model | AbsRel ↓ | RMSE ↓ | δ<1.25 ↑ | δ<1.25² ↑ | δ<1.25³ ↑ | scale |
|---|---|---|---|---|---|---|
| VGGT-Ω | 0.2964 | 0.1680 | 0.7474 | 0.8729 | 0.9198 | 1.36 |
| VGGT | 0.3855 | 0.1884 | 0.7109 | 0.8295 | 0.8845 | 1.40 |
| Any4D | 0.6992 | 0.3506 | 0.6174 | 0.7710 | 0.8351 | 0.59 |
| DA3 | 0.7760 | 0.3239 | 0.5957 | 0.7554 | 0.8299 | 1.31 |
| Model | Smoke AbsRel | Full AbsRel | 순위 변화 |
|---|---|---|---|
| VGGT | 0.141 | 0.386 | 1위 → 2위 |
| VGGT-Ω | 0.185 | 0.296 | 2위 → 1위 |
| Any4D | 0.322 | 0.699 | 3위 = 3위 |
| DA3 | 0.294 | 0.776 | — |
이번 실험으로 VGGRPO Phase 4 RL reward path의 backbone 후보에 대한 정량적 근거가 마련됐다. VGGT-Ω가 1순위, VGGT가 2순위. Any4D/DA3는 RoboCasa에서 VGGT 계열에 비해 2배 이상 나쁜 depth error를 보여 reward 신호 품질이 낮을 가능성이 크다.
Any4D 1.77 → 0.27 버그 수정이 특히 중요한 교훈이다. 기존 실험에서 Any4D를 연결할 때 쓴 API(any4d_tail_forward)가 fine-tune용 wrapper였고, off-the-shelf inference와는 전혀 달랐다. 이를 모르고 "Any4D는 성능이 나쁘다"고 결론냈다면 잘못된 판단을 내렸을 것이다.
Viser 3D 시각화 도구는 정성 검증 수단으로 재사용 가능 — 추후 reward backbone이 바뀌거나 새 clip에서 확인할 때 viser_compute.py --clip_rank N 한 줄로 pointcloud를 재생성할 수 있다.
Phase 4 Sub-plan #1(FF submodule 통합)에서 reward function을 설계할 때 VGGT-Ω(또는 VGGT)를 직접 RGB backbone으로 사용.
VGGT-Ω weight는 NAS 캐시(/home/nas_main/.cache/huggingface/hub/models--facebook--VGGT-Omega/)에 있어 worker에서 HF_TOKEN 불필요.
tmp/eval_backbones_rgb/eval_metrics.json에 48 clips 전체 raw metric이 있음.
task별로 깨지는 케이스가 있는지 확인하면 reward 신호 안정성 예측에 도움.
VGGT-Ω는 256-token text-align 변형 및 frame subsampling 옵션이 있음. 현재 eval은 기본 설정(512 resolution, 3 cam을 timestep별 set으로). 더 많은 frame이나 다른 설정에서 성능 변화 확인.
RoboCasa simulation 분포가 Any4D(DINOv2, real-world 4D)/DA3(real-world multi-view) 학습 데이터 분포와 달라서인지, 아니면 scale 처리 방식의 근본 차이인지 규명 안 됨. RL에서 Any4D/DA3를 완전히 배제하기 전에 fine-tune 후 재평가가 필요할 수 있음.