4-way depth 정성 비교 viser 툴 — RoboCasa & DROID pointcloud viewer

TL;DR

RoboCasa viewer: GT 카메라(K, pose)로 4개 모델 depth를 unproject → viser 3D pointcloud. cam-tint(exo1=빨강·exo2=초록·wrist=파랑)로 multiview 정합 즉시 확인. login-0:8788
DROID viewer: GT depth 없으므로 모델별 자체 좌표계로 world-frame points 추출. 2-cam(exo/wrist). login-0:8789. 좌표계/scale은 모델간 비교 불가, 형태·표면 노이즈만 비교.
Any4D 버그 이슈 미반영 확인: 정량 eval에서 수정한 native 경로(pts3d_cam[...,2])를 RoboCasa viser에도 동일하게 사용, scale align 후 합리적 reconstruction 확인.

모델 비교

pointclouds (RoboCasa)

43 MB

npz 캐시

도메인 뷰어

1 배경 / 목적

정량 eval(48 clips, 32 frames, 4-way)에서 VGGT-Ω AbsRel 0.296 > VGGT 0.386 ≫ Any4D 0.699 ≈ DA3 0.776 순위를 얻었다 (260625-backbone_rgb_eval_4way.html). 하지만 AbsRel 같은 pixel-level metric만으로는 "어느 모델의 geometry가 3D-consistent reward로 쓰기에 더 적합한가"를 직관적으로 판단하기 어렵다.

알고 싶은 것: 정량 2위인 VGGT와 1위 VGGT-Ω의 pointcloud가 실제로 눈에 띄게 다른가? Any4D/DA3의 실패 모드는 어떤 형태인가 — scale 문제인가, surface 노이즈인가, outlier인가?

또한 실제 RL fine-tuning 도메인인 DROID(로봇 wrist-view 실제 데이터)에서 각 모델의 자체 예측 geometry가 어떤 품질인지도 확인이 필요하다. DROID는 GT depth/intrinsics가 없어 정량 비교는 불가능하지만, 정성 관찰로 reward path 신뢰도를 점검할 수 있다.

2 작업 내용

RoboCasa viewer — `tmp/viser_compute.py` + `scripts/viser_compare.py`

viser_compute.py: held-out clip 1개의 선택된 timestep에서 GT 카메라(K_native, cam→world pose)로 GT depth + 4모델 depth를 unproject하여 카메라별 pointcloud(xyz+rgb) npz 저장.
모델 depth는 eval_backbones_rgb.py와 동일한 per-clip median-ratio scale align으로 GT scale에 맞춤. cam convention(raw vs. OpenGL→OpenCV flip)은 GT cam0↔cam1 NN residual(3.49 cm vs. 93 cm)로 자동 판정 → raw 선택.

파일: tmp/viser_compute.py 입력: EgoW/VGGRPO/data/robocasa_holdout/{task}/demo_{N} (RGB + GT depth + cam_configs) 카메라: exo1(agentview_left), exo2(agentview_right), wrist(eye_in_hand) 출력: tmp/viser_pcd.npz — 15 pointcloud × 3 source(GT/pred/pred) × 5 timestep 재사용: viz_robocasa_alignment.py:117 unproject 로직

viser_compare.py: npz를 viser 서버로 렌더링. 핵심 인터랙션:

source 토글: GT / Any4D / DA3 / VGGT / VGGT-Ω 중 선택적 on/off
camera 토글: exo1 / exo2 / wrist 개별 on/off
timestep 드롭다운: 저장된 N개 timestep 전환
color 모드: rgb(원본 색상) vs. camera(exo1=빨강·exo2=초록·wrist=파랑) — camera tint로 3-view 정합 한눈에 확인
point size 슬라이더

서버: login-0:8788 (SSH 터널로 브라우저 접속) 테스트 clip: CoffeePressButton/demo_2998 convention: raw (GT cam정합 3.49 cm) scale factors: Any4D 0.56 / DA3 1.18 / VGGT 1.23 / VGGT-Ω 1.22 총 pointcloud: 15개 (5 src × 3 timestep 대표), ~249k pts/cloud → 43 MB npz

DROID viewer — `tmp/viser_droid_compute.py`

DROID는 GT depth 없음(~/Dataset/droid_full_processed: RGB exo+wrist, euler 6DOF pose, proprio만). 대신 각 모델의 자체 좌표계 world-frame points를 추출:

VGGT: world_points 직접 사용
Any4D: pts3d
DA3: depth + intrinsics + extrinsics(w2c) → unproject
VGGT-Ω: depth + encoding_to_camera(pose_enc) → unproject

conf/거리 robust mask 적용. viser_compare.py의 cam-tint를 이름고정에서 인덱스 팔레트로 일반화(2-cam/3-cam 공용).

파일: tmp/viser_droid_compute.py 테스트 ep: AUTOLab+44bb9c36+... (droid_full_processed) 카메라: exo(exterior), wrist(gripper_d435) 서버: login-0:8789 (RoboCasa 8788과 동시 운영) per-view 점 수: VGGT ~90k / Any4D ~90–150k / DA3 ~84k / VGGT-Ω ~153k

DROID 주의: 모델별 좌표계·scale이 임의 — 절대 위치 비교 불가. 형태(평면 평탄도, 물체 경계), exo↔wrist 정합(cam-tint 모드), 표면 노이즈를 정성 기준으로 삼는다.

3 결과

RoboCasa — viser 서버 기동 확인

모델	scale (median-ratio)	per-cloud 점 수	상태
GT	—	~249k	기준
Any4D	0.56	~249k	✅ (native 경로 수정 후)
DA3	1.18	~249k	✅
VGGT	1.23	~249k	✅
VGGT-Ω	1.22	~249k	✅

정합 확인 포인트: camera tint 모드에서 3색 점군이 한 장면으로 겹치는 정도 — 좋은 모델일수록 카운터 평면이 단일 평면으로 수렴. VGGT 계열이 outlier·스트레칭 최소 예상 (정량 순위와 일치 여부 확인 중).

DROID — 4모델 EXIT 0 확인

모델	world-frame source	per-view 점 수 (avg)	비고
Any4D	`pts3d`	~90–150k	temporal native
DA3	depth+extrinsics unproject	~84k
VGGT	`world_points`	~90k	multiview static
VGGT-Ω	depth+pose_enc unproject	~153k	가장 밀도 높음

DROID 좌표계 주의: 4개 모델 모두 자기 좌표계. 절대 위치 비교 불가. wrist view depth 품질(reward 도메인)이 RoboCasa 정량 순위(VGGT-Ω>VGGT≫Any4D≈DA3)와 일관되는지가 핵심 관찰 목표.

4 Takeaway

정성 인프라가 reward path 결정의 보완 근거를 제공

정량 eval(AbsRel, δ)만으로는 "이 모델을 reward로 쓸 때 geometry가 안정적인가"를 확신하기 어렵다. viser 툴은 두 가지 보완 근거를 제공한다:

RoboCasa (GT 비교): scale-align 후 실제로 GT pointcloud와 얼마나 잘 겹치는지, 물체 경계/평면 노이즈 정도 — 정량 순위가 정성으로도 납득되는지 검증.
DROID (in-domain): RL fine-tuning 실제 도메인에서 wrist view depth 품질. RoboCasa(시뮬)와 다른 패턴이 보일 수 있음 — 실 도메인 generalization 힌트.

두 viewer가 모두 EXIT 0 확인됐고, 다른 clip/ep으로 즉시 교체 가능한 --clip_rank N / --ep_rank N 인자를 갖추고 있어 반복 관찰 비용이 낮다.

5 Next Steps

RoboCasa 정성 관찰 완료

CoffeePressButton/demo_2998 외 다른 task clip들도 viser_compute.py --clip_rank N으로 재생성 후 8788 재시작. camera tint 모드에서 VGGT-Ω/VGGT vs. Any4D/DA3의 정합 차이가 눈에 띄게 다른지 — 정량 순위(4배 AbsRel 차이)가 정성으로도 납득되는지 확인.

DROID in-domain 관찰

viser_droid_compute.py --ep_rank N으로 다양한 episode 시각화. 특히 wrist view(reward backbone이 실제로 보게 될 도메인) depth 품질이 VGGT-Ω>VGGT 순위와 일관되는지 확인. 불일치 시 RoboCasa→DROID domain gap이 reward 설계에 영향.

reward path 확정 → RL sub-plan 착수

정성 관찰이 정량 순위를 지지하면 VGGT-Ω를 direct-RGB reward backbone 1순위로 확정. Phase 4 RL fine-tuning sub-plan(claude/260510/plan-vggrpo_phase2_rl.md) Task 1(FF submodule)부터 착수. VGGT-Ω weight는 이미 공유 NAS HF 캐시에 있어 worker 재다운로드 불필요.