같은 프롬프트, 같은 파이프라인(AdaptOrch + PI 기반 OMK)인데 Three.js 결과물은 천차만별이네.
Same prompt, same pipeline (AdaptOrch + PI based OMK), but wildly different Three.js pelicans.
핵심 요약
동일한 파이프라인에서 모델만 바꿔 Three.js 코드를 생성한 결과, 모델 간 공간 추론 능력과 성능 차이가 극명하게 드러남.
- 모델 성능 비교 — Pixel Canary와 Space Bunny 모델의 Three.js 코드 생성 능력 차이 검증함.
- 공간 추론 격차 — 유닛 테스트 통과율은 같아도 실제 3D 공간 이해도와 애니메이션 구현력은 큰 차이를 보임.
- 도구 체인 혼란 — OMK, AdaptOrch 등 생소한 용어와 도구 사용으로 인해 커뮤니티 내에서 설명 요구가 빗발침.
- 스텔스 모델 — 최근 공개된 익명 모델들의 성능이 기존 모델들과 비교해 확연히 다른 양상을 보임.

AdaptOrch랑 PI 기반 OMK 디베이트 토폴로지 써서, 외부 에셋 하나도 안 쓰고 똑같은 프롬프트로 Three.js 펠리컨 벤치마크 돌려봤음.
둘 다 기술적으로는 14/14 검증 통과했고 문법도 깔끔하고 런타임 에러도 없었는데, 실제 생성 속도랑 결과물 퀄리티는 진짜 하늘과 땅 차이더라.
pixel canary는 놀라울 정도로 느리고, 솔직히 2년 전 모델 쓰는 느낌임. 3D 공간 개념도 제대로 못 잡은 엉성한 뼈대 하나 만드는 데 달팽이 기어가는 속도로 뽑아내네.
반면에 spacebunny에 AdaptOrch 붙인 건 진짜 미출시 GPT 6 Astra 하이 티어 모델 쓰는 기분임. 씬 계층 구조 완벽하게 잡고, 크랭크랑 페달 애니메이션 리깅도 제대로 하고, 환경 구성도 깔끔하게 끝냄.
유닛 테스트 통과율이 공간 추론 능력에는 아무 의미 없다는 걸 뼈저리게 느끼게 해주네.
혹시 프로시저럴 Three.js 작업할 때 멀티턴 디베이트 셋업 테스트하는 사람 또 있음? 코드 컴파일 되는 거랑 실제 공간 정합성 사이에서 이렇게 큰 격차 느끼는 중인지 궁금함.
WT pixel canary


