제작·변경 작업과 의존성
2026-10-02 작성, 2026-10-03 Sunnyvale 분할 결과 반영. 실제 스파이크의 변경 경로를 기준으로 정리했다. 아래는 작업 항목과 결합 범위이며 작업 시간·인건비·호스팅 비용을 측정한 견적은 아니다. 엔진 선택을 확정할 근거로 비용 숫자를 만들지 않는다.
변경별 작업
| 변경 | 공통 데이터·도구 작업 | 엔진 코드 작업과 주의점 |
|---|---|---|
| 기존 자산 교체 | 파일 교체, assets.json의 경로·타입·점 수·크기·해시 갱신, 월드 좌표·회전·스케일 확인, 충돌 정합 검수 |
기존 SOG/GLB 계약에 맞으면 어댑터 변경 없이 사용 가능. 새 포맷·해독 옵션은 양쪽 로더를 수정해야 함 |
| 현재 시험 장면 재분할 | make-spatial-chunks.py 실행 → 매니페스트 갱신 → pnpm check; 콘텐츠 좌표·구역 소유권 확인 |
가까운 구역 선택 정책은 공통. 실제 자원 생성·해제는 각 엔진 구현 |
| 원거리 저해상도 생성·수정 | make-spatial-lod.py 실행 → 매니페스트 갱신 → 검사; 축소율·동일 좌표·표시 품질·합산 예산 검토. 메타데이터가 있으면 재분할 때 함께 재생성 |
교체 상태는 공통, 표시·해제는 엔진별. 페이드나 엔진 고유 LOD를 적용하려면 별도 구현·비교 필요 |
| Sunnyvale 화면·충돌 재분할 | make-sunnyvale-stream.py로 18개 생성, 메타데이터·매니페스트 갱신, 원본 충돌면 유지 검사; CPU 실행 80.325초 |
세 구성에서 시각·충돌 공동 로딩 구현 완료. 후속 변경으로 BVH/Rapier도 유지 형상을 재사용하고 구역별 추가·제거한다. 시대 전환은 전체 제어기 교체. 사람의 수정·검수 시간은 미측정 |
| Sunnyvale 시대·설명 결합 시험 | shared/source/sunnyvale-era.author.json 수정 → pnpm authoring:compile → 검사. 촬영 배경·분할 자산 재사용, 황색 벽과 설명만 시대별 가상 변경 |
세 구성 데스크톱에서 전환·겹침 안전 이동·실패 복구 확인. 실제 역사 자료와 시대별 바닥 제작·iPhone 재검증은 남음 |
| 다른 공간·구역 추가 | 분할 경계·SOG·크기·점 수·좌표·구역 예산 정의, spawn과 콘텐츠 소유권 설정 | 현재 생성기는 Hall의 5개와 Sunnyvale의 6개 X 구역에 맞춘 별도 구현이다. 임의 다각형·2D 격자·고도별 구역에는 생성기와 공통 검증·이동 허용 정책의 변경이 필요 |
| 과거 건물 추가 | 시각 GLB, 해당 시대 충돌 GLB와 transitionBounds, 겹침 때 안전 spawn, 시대별 오브젝트·설명 데이터 추가 |
기존 시대 교체 계약 안에서는 데이터 작업. 회전된 복잡한 건물의 정밀 겹침 판정은 별도 구현 가능성이 있음 |
| 장소 설명 추가·수정 | content.json 설명·표현 종류·확신 수준·출처·이미지, world/*.json 핫스팟 위치·시대·거리·소유 구역 설정 |
현재 패널 종류 안에서는 공통 UI 변경 불필요. 영상·오디오·퀴즈 등 새 상호작용은 UI·입력·수명 정책을 함께 구현 |
| 경사·계단·정밀 보행 수정 | 실제 보행 메시를 만들고 촬영 영상과 정합 검수 | BVH/Rapier/Ammo의 캐릭터 제어는 서로 다른 코드. 같은 충돌 파일만으로 모든 이동 결과가 같아지지는 않음 |
Hall 분할 생성기는 기존 핫스팟을 보존하지만 다른 월드 설정은 기본 Hall 월드에서 다시 만든다. Sunnyvale 분할 생성기는 해당 장소 기본 월드로 현재 시대 시험을 만든다. 후속 시대 결합 생성기는 별도 작성 원본의 가상 벽·설명을 이 분할 월드에 추가한다. 작성 원본과 산출물을 분리하고 다른 콘텐츠 보존·삭제 항목 정리·생성 결과 불일치 검사를 구현했다. 이 분리는 Sunnyvale 시대 결합 시험에 적용되며 기존 분할 생성기 전체를 범용화한 것은 아니다. 경계를 바꾼 뒤 콘텐츠 소유권이 자동 재배치되지는 않는다. 이 과정을 범용 제작 도구로 부르기에는 수동 작업이 남아 있다.
런타임·제작 도구
| 구성 | 현재 고정 버전·역할 | 변경 시 영향 |
|---|---|---|
| PlayCanvas | Engine 2.22.6, Ammo 보행 | 앱·자산 수명과 물리 연결이 엔진에 결합됨. 이 스파이크는 Engine 코드 방식이며 호스팅 Editor 의존 없음 |
| Three.js | 0.186.1 + Spark 2.2.0 | 시각 렌더러·SOG 로더는 Spark 계약에 결합됨 |
| Three.js 보행 | three-mesh-bvh 0.9.15 또는 Rapier3D compat 0.21.0 | 제어기 교체 가능하지만 계단·접지·복구·시대 전환·자원 해제까지 통합해야 함 |
| 공통 오프라인 변환 | splat-transform 3.7.0, Python 생성기 | 자산 준비 때 실행. 이번 분할은 CPU 인코딩이며 브라우저 런타임에 이 도구를 포함하지 않음 |
| 개발·릴리스 | Node.js 24, pnpm 10, Vite 8.3.1, TypeScript 7.0.2 | 잠금 파일과 자산 해시·릴리스 식별자로 시험 조건 기록 |
공통 데이터는 JSON·SOG·GLB로 유지한다. 핫스팟·설명과 스트리밍 정책은 공유하지만 엔진의 불투명한 자원 핸들은 공유하지 않는다. PlayCanvas Editor 제작 과정이나 엔진 고유 LOD 제작 과정을 비교한 것은 아니다.
실제 구현에서 드러난 비용
시대 교체·분할·콘텐츠를 붙이는 과정에서 두 엔진 모두 자산 해제와 늦은 비동기 결과 정리가 필요했다. PlayCanvas는 같은 URL의 컨테이너 자원을 공유하는 경우 소유·해제 순서를 관리해야 했고, Three.js는 Splat 및 물리 제어기를 각각 정리해야 했다. 공통 상태 관리와 엔진별 자원 처리를 나눈 덕분에 실패·재시도 정책과 콘텐츠 소유권을 공유할 수 있었다.
예산을 너무 작게 잡으면 경계에서 이동이 영구적으로 막힐 수 있어 설정 검증을 추가했다. 생성기가 다시 만든 월드에서 작성한 핫스팟을 지우지 않도록 보존 처리도 추가했다. 이 두 항목은 제작자가 데이터만 고치는 경우에도 검사와 생성 도구가 필요하다는 근거다.
현재 배포 산출물은 양쪽 앱에 공용 자산 전체를 복사한다. 선택 로딩은 실행 시 요청량을 줄이며 배포 저장 용량까지 자동으로 줄이지 않는다. 월드·콘텐츠·매니페스트는 작은 JSON 전체를 읽고 설명 이미지는 패널을 열 때 요청한다. Hall 시험에서는 공통 충돌을 상주시킨다. Sunnyvale에는 화면·충돌을 함께 분할·로딩하는 파이프라인을 추가했다. 원본 충돌면 보존은 확인했지만 시대별 충돌 제작과 임의 장소를 위한 범용 편집 과정은 남아 있다.
비용 판단에 아직 필요한 근거
실제 장소 한 구역의 제작·수정 시간, 원거리 LOD 생성·검수 시간, 충돌 메시 제작 시간, 모바일 안전 자산 예산, 서버 저장·전송 단가와 이용량이 필요하다. 현재 작은 시험의 프레임 수와 논리적 상주 점 수만으로 전체 프로젝트 비용을 계산할 수 없다.
원거리 표현 생성과 실패·재시도는 원거리 시험에서, 분할과 시대 교체의 결합은 데스크톱과 iPhone에서 확인했다. 선명도 변화·경계 검수와 실제 메모리 확인은 남아 있다. Sunnyvale의 화면·충돌 공동 분할과 CPU 변환·런타임 교체 비용은 후속 결과에 기록했다. 가상 시대·설명 결합과 Three.js 구역 충돌 재사용도 데스크톱에서 확인했다. 보행 메시 조사와 작성·검수 절차를 추가했다. 계단 직진과 정지는 확인했지만 벤치 부근 왕복은 세 구성 모두 실패한다. 다음은 실제 바닥·이동 금지 경계를 확인한 메시 보정과 실제 자료 제작에서 사람의 수정·검수 시간 기록이다. 모바일 안전 예산·호스팅 견적과 일부 구역만 다시 만드는 증분 제작 비용도 남아 있다.