GLB 뷰어 & 압축기 — 온라인에서 .glb / .gltf 열기, 검사, 용량 줄이기

브라우저의 GLB 뷰어는 탭 안에서 파일을 디코딩하고 WebGL로 그립니다. 페이지에 .glb 또는 .gltf를 떨어뜨리면 데스크톱에서 몇백 밀리초 만에 모델이 화면에 나타납니다. 업로드 단계도, 설치 프로그램도, 계정도 없습니다. GLB는 하나의 바이너리 파일로 묶인 glTF 2.0 에셋입니다. 12바이트 헤더, 씬 그래프를 설명하는 JSON 청크, 그리고 정점 버퍼와 인덱스 버퍼, 보통은 내장 이미지까지 담는 BIN 청크로 이루어집니다.

같은 페이지가 게임 파이프라인의 검사 및 용량 축소 단계입니다. 내보낸 파일을 열고, 와이어프레임, 노멀, UV 아일랜드, 머티리얼 슬롯을 살펴보며 Blender나 Maya에서 나오는 과정에서 깨진 것이 없는지 확인한 다음, 파일을 압축하고 엔진용 사본을 다운로드합니다. 이 페이지에서는 각 검사 뷰가 무엇을 잡아내는지, 세 가지 압축 레버와 당겨야 할 순서, 그리고 브라우저 장면이 실제로 지켜야 하는 예산을 다룹니다.

여기에서 바로 .glb 열기

파일을 드롭 영역으로 끌어다 놓거나 파일 대화상자에서 선택하세요. 페이지는 File API를 통해 파일을 Blob URL과 ArrayBuffer로 읽고 같은 탭에서 파싱합니다. 그 과정에서 브라우저 네트워크 패널을 열어 보세요. 어떤 요청도 모델을 실어 나르지 않습니다. 아무것도 대기열에 들어가지 않고, 서버에 기록되지 않으며, 탭을 닫으면 사라집니다.

로컬 처리는 두 가지 면에서 중요합니다. 첫째는 프라이버시입니다. 아직 공개하지 않은 캐릭터, 비밀유지계약 아래의 의뢰 작업, 돈을 주고 산 스캔 에셋 등이 그렇습니다. 이런 파일을 제3자 변환기로 보내는 것은 성능 문제이기 전에 라이선스 문제입니다. 둘째는 지연 시간입니다. 40 MB GLB를 10 Mbps 업로드 연결로 보내면 변환이 시작되기도 전에 대략 30초를 기다려야 하고, 그 대기는 파일을 실제로 얼마나 자주 확인하는지를 바꿔 놓습니다. SSD에서 로컬로 읽으면 1초도 안 걸리고, 파싱 비용은 여러분 컴퓨터의 CPU 작업입니다.

지원 입력: .glb는 단일 파일 형식입니다. .gltf는 같은 장면을 JSON으로 표현한 것이라 보통 .bin 버퍼와 이미지 폴더를 함께 가져옵니다. 여러 개를 한꺼번에 선택하거나, 폴더 전체를 끌어다 놓거나, zip을 떨어뜨리면 뷰어가 상대 URI를 해석합니다. 내장 data URI는 사이드카 파일 없이도 작동합니다. 텍스처는 PNG, JPEG, WebP 또는 KTX2(Basis Universal)일 수 있고, 지오메트리는 Draco 또는 meshopt로 압축될 수 있습니다. 뷰어가 두 디코더를 모두 갖추고 있고, JSON 청크의 확장 목록을 읽어 어느 것을 쓸지 결정하기 때문입니다.

렌더링하는 것: 하나의 방향성 조명과 선택적 환경 맵 아래의 PBR 머티리얼, 실제 크기를 읽을 수 있는 켜고 끌 수 있는 1 m 그리드, 파일에 있는 모든 애니메이션의 클립 목록, 그리고 삼각형 수, 정점 수, 노드 수, 드로우 콜 추정치, 내장된 모든 이미지의 픽셀 크기와 바이트 크기를 보여 주는 통계 패널입니다. 메모리가 유일한 확실한 한계입니다. 100 MB GLB는 보통 데스크톱에서 열리지만, 휴대폰 탭은 파싱이 끝나기 전에 브라우저가 종료시킬 수 있습니다.

대안은 왕복입니다. DCC를 열고, 가져오고, 확인하고, 내보내고, 엔진에 로드하고, 문제를 발견하고, 되돌아갑니다. 각 단계는 몇 분씩 걸리고 각 단계가 나름의 변경을 끼워 넣을 수 있어서, 결국 에셋이 아니라 파이프라인을 디버깅하게 됩니다. 파일이 이미 있는 같은 탭에서 검사를 유지하면 왕복이 사라지고, 더 유용하게는 여러분이 읽는 수치가 곧 출시하려는 파일의 수치가 됩니다.

검사: 와이어프레임, 노멀, UV 레이아웃, 머티리얼

네 가지 뷰가 엔진에 도달하기 전에 대부분의 잘못된 내보내기를 잡아냅니다. 와이어프레임은 삼각형 밀도를 보여 주고 내보내기 도구가 n각형을 어디에서 삼각분할했는지 드러냅니다. 노멀은 면 방향을 보여 주므로, 뒤집힌 표면은 단일 방향성 조명 아래에서 검게 보입니다. UV 레이아웃은 UV 채널을 텍스처를 뒤에 둔 그리드로 펼쳐서 겹치는 아일랜드, 늘어난 텍셀, 0~1 범위를 벗어난 지오메트리를 한눈에 보이게 합니다. 머티리얼은 텍스처, 알파 모드, 양면 플래그, 색 공간 설정과 함께 모든 머티리얼을 나열합니다.

압축하기 전에 항상 검사하세요. Draco와 meshopt는 정점 버퍼를 다시 쓰고 정점 레이아웃을 바꾸며, 텍스처 크기 조정은 원래 있던 이음새를 숨길 수 있습니다. 먼저 압축하면 어떤 아티팩트가 여러분 잘못인지 압축기 잘못인지 더 이상 구분할 수 없게 됩니다.

통계 패널도 검사의 일부입니다. 무엇이든 손대기 전에 삼각형 수, 정점 수, 노드 수, 머티리얼 수, 각 내장 이미지의 크기를 적어 두세요. 이것이 모든 압축 단계 후에 비교할 기준 수치이며, 어떤 레버를 실제로 당길 가치가 있는지 알려 줍니다.

GLB를 깨뜨리지 않고 압축하기

세 가지 레버가 있고, 그 무게는 같지 않습니다. 아무것도 참조하지 않는 데이터를 버리는 것은 공짜이며 다시 내보내면 되돌릴 수 있습니다. 텍스처를 다시 인코딩하는 것은 일반적인 에셋에서 대부분의 바이트를 줄여 줍니다. 이미지가 파일을 좌우하기 때문입니다. 지오메트리 압축은 모델을 깨뜨릴 수 있는 유일한 레버라서 맨 마지막에 갑니다.

이 중 어느 것도 보장된 비율을 제공하지 않습니다. 4096 × 4096 PNG 하나로 이루어진 GLB는 대부분 정점 데이터인 GLB와 전혀 다르게 동작하고, 512 텍스처 30개가 있는 메시 위주 장면은 4K 아틀라스 하나를 가진 단일 캐릭터와 같은 방식으로 반응하지 않습니다. 남의 에셋에서 나온 수치를 믿지 말고 매 단계 후에 측정하세요.

디코더는 사소한 세부 사항이 아니라 출시 제약입니다. Draco는 Draco 디코더 모듈이 필요하고, meshopt는 MeshoptDecoder가 필요하며, KTX2는 올바른 대상 포맷을 가진 트랜스코더가 필요합니다. three.js는 GLTFLoader를 제공하지만 DRACOLoader, MeshoptDecoder, KTX2Loader는 직접 연결해야 합니다. Babylon.js와 Unity glTFast에는 그에 상응하는 것들이 있습니다. 런타임이 모르는 확장으로 압축하면 모델이 검게 로드되거나 예외를 던지는데, 이는 설정 실수라기보다 파일 손상처럼 보입니다.

GLB vs glTF vs FBX — 엔진이 원하는 것은

glTF 2.0은 런타임 포맷입니다. GLB와 .gltf는 같은 데이터를 담는 두 가지 컨테이너입니다. GLB는 JSON과 바이너리 버퍼를 한 파일에 넣고, .gltf는 읽을 수 있는 텍스트와 사이드카로 따로 유지합니다. FBX는 glTF보다 먼저 나온 DCC 교환 포맷이며 여전히 대부분의 리거와 애니메이터가 넘겨주는 형식이고, OBJ는 지오메트리만 담아 애니메이션도, PBR 머티리얼도 전혀 없습니다.

축과 단위 규약은 파일 크기보다 더 많은 가져오기 버그를 일으킵니다. glTF는 미터, Y-up, 오른손 좌표계이며 카메라는 -Z를 내려다봅니다. FBX 내보내기 도구들은 단위에 대해 서로 다르게 처리하고, 센티미터와 미터가 어긋나면 모델이 대략 100배 너무 작거나 크게 나타납니다. Blender의 glTF 내보내기 도구는 Z-up을 Y-up으로 알아서 변환해 줍니다. 이 기능을 끄면 모델이 옆으로 누운 채 도착합니다. 엔진을 탓하기 전에 뷰어에서 바운딩 박스를 알려진 치수와 비교해 보세요.

웹을 위한 최적화: 드로우 콜, 텍스처 크기, 폴리곤 예산

이것들은 한계가 아니라 프로젝트마다 조정하는 출발점으로 여기세요. 중급 노트북에서 안정적인 프레임 속도를 유지하는 브라우저 장면은 보통 수십만 개 미만의 삼각형이고, 훨씬 더 중요하게는 수백 개 미만의 드로우 콜입니다. 인스턴싱과 머티리얼 병합은 첫 번째 수치를 움직이고, 지오메트리를 합치는 것 외에는 두 번째 수치를 움직이는 것이 없습니다.

드로우 콜은 메시마다, 머티리얼마다 계산됩니다. 각자 자기 머티리얼을 가진 소품 200개는 각각이 겨우 수백 개의 삼각형이더라도 드로우 200번을 잡아먹고, 이를 제출하는 CPU 비용이 지오메트리의 GPU 비용을 넘을 수 있습니다. 같은 머티리얼을 공유하는 정적 지오메트리를 병합하고, 작은 텍스처를 하나의 이미지로 아틀라스화하고, 반복되는 소품을 인스턴싱하세요. 투명 머티리얼은 삼각형 수가 시사하는 것보다 더 많은 비용이 듭니다. 픽셀마다 정렬하고 블렌딩하기 때문이고, 그림자 캐스팅은 같은 지오메트리를 깊이 맵으로 다시 렌더링합니다.

텍스처 크기는 보통 파일과 VRAM 모두를 좌우하는데, 사람들이 거꾸로 이해하는 부분이 바로 이것입니다. 4096 × 4096 RGBA8 텍스처는 밉맵 전 메모리에서 67,108,864바이트이고, 밉맵이 대략 3분의 1을 더합니다. 그에 비해 위치, 노멀, UV에 4바이트를 쓰는 10만 삼각형 메시는 몇 메가바이트에 불과합니다. 부주의한 4K 노멀 맵 하나가 그 위에 놓인 메시 전체보다 무겁습니다. KTX2는 텍스처를 GPU 메모리에서 압축된 상태로 유지하는데, 이는 파일 크기와는 다른 절약이며 모바일에서 종종 더 중요한 절약입니다.

색 공간도 이 목록에 포함되는데, 늘 잘못 설정되기 때문입니다. 베이스 컬러와 이미시브는 sRGB입니다. 노멀, metallicRoughness, 오클루전은 리니어입니다. 둘을 바꾸면 머티리얼이 바래 보이거나 너무 어두워지고, 로드 시점에 데이터가 잘못 해석되었기 때문에 아무리 조명을 조정해도 고쳐지지 않습니다.

압축하기 전에 실제 모델 검사하기

토폴로지에 대해 읽는 것과 그것을 돌려 보는 것은 다릅니다. Blender Model Gallery가 이 페이지에 와이어프레임 모드로 삽입되어 있어, 실제 내보낸 파일을 돌려 보고 모델러가 본 깔끔한 사각형이 아니라 엔진이 실제로 그릴 삼각형을 볼 수 있습니다.

돌아갈 때 세 가지를 보세요. 곡률: 삼각형이 몰려 있는 곳이 내보내기 도구가 삼각형을 추가한 곳이며, 평평한 20삼각형 벽 옆에 20,000삼각형 구가 있는 것은 정상입니다. 이음새: 모서리를 가로질러 음영이 바뀌면 그곳에서 정점이 분리되었다는 뜻으로, UV 이음새에서는 맞고 매끄러운 표면에서는 틀립니다. 실루엣: 윤곽선은 플레이어가 멀리서 읽는 것이며, 내부 디테일보다 감면 단계를 훨씬 잘 견딥니다.

같은 예산이 Mini World와 The Cyclops' Island에 실린 에셋에도 적용됩니다. 둘 다 3D 게임 빌더를 통해 브라우저 탭에서 실행됩니다. 소품 하나가 40k 삼각형인 것은 괜찮습니다. 하지만 그것이 한 장면에 40개 있으면 안 되며, 프레임 속도가 알려 주기 전에 이를 알아내는 곳이 와이어프레임 뷰입니다.

그것이 속한 세계로 걸어 들어가기

스프라이트는 설 곳이 없는 캐릭터입니다. 마지막 단계는 다른 곳에서는 제공하지 않는 것입니다. 방금 만든 시트를 누군가 걸어 다닐 수 있는 세계에 넣으세요. 작은 섬, 행성, 비 내리는 거리 모퉁이 같은 곳입니다. 이 사이트의 모든 세계는 하나의 서술문으로 만들어졌고 플레이할 수 있는 페이지로 게시되었습니다.

FAQ