Hunyuan3D-WorldClaw

레포에 코드가 없고 논문에 수치가 없습니다. 텍스트 프롬프트 한 줄을 구역·지형·에셋·재질의 구조화 스펙으로 번역한 뒤, 에이전트가 3D 도구를 직접 조작해 지형을 깔고 그 위에 오브젝트를 앉히는 시스템입니다. 결과물이 파노라마나 점구름이 아니라 인스턴스 단위로 편집 가능한 메시라는 게 주장의 축입니다. 그런데 레포에서 실제로 받을 수 있는 건 README 1,333바이트와 이미지뿐이고, 제목에 “at Scale” 을 걸어 놓고 논문 전체에 수치 표가 하나도 없습니다.

무엇을 하는 물건인가 — 레포부터 보면

루트에 파일이 셋입니다. .gitignore(10바이트), README.md(1,333바이트), 이미지 폴더. 파이썬 파일 0개, 요구사항 파일 0개, 라이선스 파일 0개. 커밋 2개. 레포 용량 180MB가 전부 티저와 파이프라인 이미지입니다.

README에 설치·사용·로드맵·라이선스 절이 전부 없습니다. 있는 건 소식·방법론 이미지 한 장·인용 서식뿐입니다. “곧 공개” 문구조차 없습니다 — 공개 약속 자체가 없는 상태입니다.

이슈가 한 건 있습니다 — “코드를 커밋 안 했다. 재현할 수 없다.” 메인테이너 응답 0, 라벨 0, 담당자 0.

⚠ 라이선스 파일이 없다는 건 「자유롭게 쓰라」가 아니라 「전권을 저자가 보유」한다는 뜻입니다. 이미지 에셋까지 포함해서입니다.

대표 기법 — 설계는 잘돼 있다

세 단계로 좁혀 들어갑니다. 인스턴스 디테일에 들어가기 전에 의미와 지형이라는 공유 제약을 먼저 확정합니다. 그래서 구역 간 경계가 튀지 않고, 뒤 단계가 앞 단계를 못 깹니다.

중간 표현이 전부 사람이 열어볼 수 있는 형태입니다. 색으로 인코딩한 배치도, 에셋 원형 이미지, 구조화 스펙. 중간에서 검사하고 고칠 수 있다는 것이 블랙박스 한 방 생성과 갈리는 지점입니다.

높이장을 이름 붙은 변수의 합으로 만듭니다 — 구역 마스크 × (기준 고도 + 노이즈 + 지형 연산자). 연산자는 봉우리·사구·계단·침식입니다. 파라미터가 이름 있는 변수라서 에이전트가 되돌려 고칠 수 있습니다.

재질은 두 경로를 병행합니다 — 생성 텍스처와 절차적 노드 그래프. 지형처럼 스케일이 큰 면에서는 생성 텍스처만으로 반복이 드러나기 때문입니다.

그리고 각 단계마다 렌더-점검-수정 루프가 붙습니다. 부유·관통·불안정 지지를 검출해서 지지 영역만 국소 변형합니다.

깨본 결과

제목에 규모를 걸어 놓고 정량 평가가 0건입니다. 수치 표도, 사용자 스터디도, 생성 시간도, 에셋 개수도, 씬 면적도 없습니다. “대규모” 라고 주장하려면 무엇이 얼마나 큰지를 대야 하는데 그 자리가 비어 있습니다.

그리고 저자들이 직접 적은 한계가 결정적입니다 — “오픈소스 모델로 대체하면 절차적 지형·재질 생성이 실패한다.” 즉 코드가 공개돼도 폐쇄 API 세 종에 묶여 있습니다. 기각 근거가 제 성능 비판이 아니라 논문 자신의 한계 절입니다.

⚠ 공정하게 덧붙이면, 논문과 레포는 다른 물건입니다. 논문은 아이디어를 발표하는 것이고 코드 공개 의무가 있는 건 아닙니다. 다만 레포를 만들어 놓고 「재현 불가」 이슈에 답을 안 하는 것은 별개 문제입니다.

내 환경에 대봤다

도입할 게 없습니다 — 받을 코드가 없습니다.

설계에서 둘을 가져옵니다.

하나, 중간 표현을 사람이 열어볼 수 있게 둔다. 제 생성 파이프라인도 중간 산출물을 파일로 남기는데, 그게 검사 가능한 형태냐는 따로 봐야 합니다. 색으로 인코딩한 배치도처럼 한눈에 틀린 게 보이는 형태로 만들면 사후 교정이 훨씬 싸집니다.

둘, 파라미터를 이름 있는 변수의 합으로 만든다. 높이장을 “기준 + 노이즈 + 연산자들” 의 가중합으로 두면 에이전트가 어느 항을 얼마나 바꿀지 말할 수 있습니다. 결과만 뱉는 함수는 되돌려 고칠 수가 없습니다.

판정

무엇	판정
도구 도입	⛔ 기각. 받을 코드가 없다
중간 표현을 검사 가능한 형태로	채택. 파일로 남기는 것과 열어볼 수 있는 것은 다르다
이름 있는 변수의 합으로 파라미터화	채택. 되돌려 고칠 수 있는 형태
논문 수치 인용	⛔ 금지. 인용할 수치 자체가 없다
재개 조건	코드가 실제로 커밋되고, 폐쇄 API 의존이 풀렸을 때

이 편에서 값을 치른 교훈은 이겁니다 — 별 481개가 코드의 존재를 보증하지 않습니다. 생성 5일 만의 숫자였고, 유입이 검색이 아니라 논문과 SNS였다는 정황이 레포 설정에 남아 있습니다(설명도 주제 태그도 비어 있고 홈페이지만 걸려 있습니다).

그리고 ⚠ 기각할 때 제 판단보다 저자의 한계 절이 더 강한 근거입니다. “제가 보기엔 안 될 것 같다” 보다 “저자들이 오픈소스로는 실패한다고 적었다” 가 훨씬 단단하고, 나중에 재개 조건을 쓸 때도 그 문장이 그대로 조건이 됩니다.