원거리 저해상도 표현과 근거리 교체
2026-10-03. 공간 분할 시험에 먼 구역의 저해상도 표현을 추가했다. Three.js와 PlayCanvas에 같은 자산·선택 정책을 적용했다. 데스크톱에서 로딩 지연·실패 중에도 해당 구역의 표현이 유지되고, 정밀 자산이 준비되면 교체되는 것을 확인했다. 교체 순간 선명도가 달라지는 현상은 남아 있다. 화면 품질 전체나 엔진 우열을 통과 판정한 결과는 아니다.
자산과 재현
900,000점 Hall 마스터를 기존 정밀 자산과 같은 다섯 X 구역으로 나눴다. scripts/make-spatial-lod.py가 구역별로 splat-transform 3.7.0 --gpu cpu --filter-harmonics 0 --decimate-adaptive 10%를 적용하고 SOG로 인코딩한다. 원본의 일부 점을 무작위로 고르는 대신 적응형 축소를 사용한다. 두 표현의 위치·회전·스케일과 구역 범위는 일치한다. 점 수·크기·해시는 저해상도 메타데이터에 기록한다.
| 구역 | 저해상도 Gaussian 수 | SOG 크기(B) |
|---|---|---|
| 0 | 6,997 | 108,184 |
| 1 | 23,174 | 332,038 |
| 2 | 26,798 | 382,854 |
| 3 | 21,538 | 307,934 |
| 4 | 11,494 | 167,662 |
| 합계 | 90,001 | 1,298,672 |
python3 scripts/make-spatial-lod.py
python3 scripts/update-asset-manifest.py
pnpm check
make-spatial-chunks.py로 정밀 자산을 다시 만들 때도 저해상도 메타데이터가 있으면 저해상도 자산을 함께 재생성한다. 생성 중 임시 PLY는 종료 후 삭제한다. 현재 생성기는 Hall의 다섯 구역 전용이며 범용 제작 도구는 아니다.
표시·로딩 정책
- 저해상도 다섯 구역을 먼저 순차 준비하고 계속 상주시킨다. 그다음 시작점 주변의 정밀 구역을 준비한다.
- 정밀 구역이 준비되기 전에는 그 구역의 저해상도만 표시한다. 준비되면 같은 프레임의 상태 변경에서 저해상도를 숨기고 정밀 자산을 표시한다. 해제 때는 반대로 처리한다.
- 두 표현의 알파를 동시에 섞는 페이드는 사용하지 않는다. 구역별 표시 상태가 겹치지 않게 하지만 선명도 변화가 눈에 띌 수 있다. Gaussian 타원체가 구역 경계를 넘는 문제는 별도로 남는다.
- 정밀 자산의 로딩 지연·실패 중에는 저해상도가 유지된다. 저해상도 표시만으로 이동이나 콘텐츠 소유권을 허용하지 않는다. 필요한 정밀 구역이 준비되지 않으면 경계에서 이동을 기다린다.
- 정밀 로딩 실패는 자동 반복 요청하지 않는다.
구역 로딩 재시도로 복구한다. 최초 저해상도 준비 실패는 오류와다시 시도를 표시하며 부분 준비 자산을 정리한다. - 공통 충돌 메시 24삼각형은 계속 유지한다. 복잡한 충돌 메시의 구역별 교체를 검증한 것은 아니다.
크기와 예산
시작 시 정밀 구역 0·1의 3,991,817 B에 저해상도 전체 1,298,672 B를 더해 5,290,489 B의 SOG가 필요하다. 기존 단일 SOG 11,543,748 B보다 약 54.2% 작다. 앞 단계의 65.4% 절감은 먼 구역을 표시하지 않았을 때의 값이다. HTML·JS·물리·충돌·JSON까지 포함한 페이지 전송량은 아니며 브라우저 캐시 때문에 실제 전송 바이트와도 다를 수 있다.
| 항목 | 점 수 |
|---|---|
| 시작 시 상주: 저해상도 전체 + 정밀 0·1 | 391,703 |
| 시작 시 표시: 정밀 0·1 + 저해상도 2·3·4 | 361,532 |
| 정밀 자산 예약 상한 | 750,000 |
| 저해상도 포함 예약 상한 설정 | 850,000 |
| 두 앱 왕복 경로에서 관찰한 최대 예약 | 589,715 |
숨긴 저해상도도 상주 예산에 포함한다. 준비 중 정밀 자산도 예약에 포함하며 최대 정밀 구역 수는 3개다. 이 수치는 논리적 Gaussian 수이고 프로세스 RAM·GPU 바이트 측정은 아니다. 전체 저해상도를 항상 상주시키므로 장소 크기가 계속 늘어나는 프로젝트의 최종 구조로 일반화할 수 없다.
브라우저 검증
Playwright MCP의 별도 headed Chromium에서 앱을 하나씩 열고 종료했다. 릴리스 local-4d5905679d2e-dbfe2d878e01. 이번 원거리 표현 시험은 Three.js BVH와 PlayCanvas Ammo에서 실행했다. Rapier는 이전 공간 분할 시험을 통과했지만 이번 브라우저 경로는 반복하지 않았다.
| 확인 | Three.js BVH | PlayCanvas Ammo |
|---|---|---|
| 시작 시 저해상도 5개 + 정밀 0·1 | 통과 | 통과 |
| 구역 2 응답 지연 중 저해상도 유지·경계 정지 | 통과 | 통과 |
| 응답 후 정밀 교체·이동 재개 | 통과 | 통과 |
| 끝 구역 왕복·예산 준수·낙하 복구 0회 | 통과 | 통과 |
| 정밀 요청 실패 후 수동 재시도 | 통과 | 통과 |
| 최초 저해상도 요청 실패 후 시작 재시도 | 통과 | 통과 |
| 충돌 면 보기에서 시각 자산 모두 숨김 | 통과 | 통과 |
전체 current.sog 요청은 없었다. 상태 기록의 모든 표본에서 정밀 준비 구역과 저해상도 표시 구역은 겹치지 않았으며 합집합은 다섯 구역이었다. 정상·실패 경로에서 수집한 페이지 JS 예외는 0개다. 실패를 주입한 요청의 네트워크 오류와 엔진 로더 오류 로그는 예상된 결과다. 프레임 시간이나 성능 순위는 이번 시험에서 비교하지 않았다.
- 정상·지연: Three.js JSON, PlayCanvas JSON, 실행 경로 (원본 저장소 파일)
- 실패·재시도: Three.js JSON, PlayCanvas JSON, 실행 경로 (원본 저장소 파일)
- 같은 카메라의 교체 전후: Three.js 저해상도 / 정밀, PlayCanvas 저해상도 / 정밀
스크린샷에서 건물·창문·난간·풀의 선명도 변화가 보인다. 구역 전체가 사라지는 공백이나 뚜렷한 이중 표현은 관찰되지 않았지만 모든 시점의 경계를 픽셀 단위로 검증한 것은 아니다. 원본의 검은 배경과 촬영 누락도 남아 있다. 엔진 고유 LOD 제작 기능을 비교한 결과가 아니다.
pnpm check는 자산 20개의 크기·해시, 자동 검사 58개, 공통·앱 타입 검사와 두 앱 빌드·배포 목록 검증을 통과했다. 자동 검사에는 저해상도 부분 준비 실패의 정리, 종료 후 늦은 결과 해제, 정밀 표시 실패 때 저해상도 복원과 중복 해제 방지가 포함된다.
다음 확인과 직접 사용
공간 분할과 시대 전환의 결합은 후속 시험에서 확인했다. 다음은 iPhone에서 분할 장면의 준비·이동이다. 품질 교체가 허용 가능한지, 실제 장소의 복잡한 충돌과 콘텐츠를 어떻게 구역에 배치할지는 추가 검수가 필요하다. 이번 결과만으로 엔진을 확정하지 않는다.
./dev.sh --preview both 후 구역별 로딩 · 분할 시험을 선택한다. Three.js, PlayCanvas. D/A로 구역을 왕복하며 먼 건물 유지, 선명도 변화, 상단의 표시·상주 점 수를 확인할 수 있다.