GLB 檢視器與壓縮器 — 在線上開啟、檢查並縮小 .glb / .gltf

瀏覽器裡的 GLB 檢視器會在同一個分頁內解碼檔案，再用 WebGL 畫出來。把 .glb 或 .gltf 丟到頁面上，桌機大概幾百毫秒內模型就出現在畫面上；沒有上傳步驟、不用安裝程式、也不用帳號。GLB 就是把 glTF 2.0 素材打包成單一二進位檔：12 byte 的標頭、一個描述場景圖的 JSON chunk，以及一個放頂點緩衝區、索引緩衝區，通常還有內嵌圖片的 BIN chunk。

同一個頁面就是遊戲流程裡的檢查與縮小步驟。你打開匯出檔，看線框、法線、UV 島和材質插槽，確認從 Blender 或 Maya 出來之後沒壞掉，再壓縮檔案、下載一份給引擎用。這一頁講的是每個檢查檢視各自能抓到什麼、三根壓縮槓桿與它們該拉的順序，以及瀏覽器場景實際上必須活在哪個預算裡。

在這裡直接開啟 .glb

把檔案拖到放置區，或用檔案對話框挑一個。頁面透過 File API 把它讀成 Blob URL 加 ArrayBuffer，並在同一個分頁裡解析。你可以順手打開瀏覽器的網路面板：沒有任何請求帶著模型。不會排隊、不會寫到伺服器，關掉分頁就沒了。

本機處理有兩層意義。先講隱私：還沒發表的角色、NDA 底下的案子、花錢掃描來的素材，把它們送進第三方轉換器，先是授權問題，才是效能問題。再講延遲：40 MB 的 GLB 走 10 Mbps 的上傳頻寬，轉換還沒開始就要等大約半分鐘，而這個等待會改變你多常去檢查一個檔案。從 SSD 本機讀取只要零點幾秒，解析成本也是自己機器上的 CPU 工作。

可接受的輸入：.glb 是單檔的情況。.gltf 是同一份場景的 JSON，所以通常會跟一個 .bin 緩衝區和一整包圖片一起來。你可以多選、把整個資料夾拖進來，或丟一個 zip，檢視器會自己解析相對 URI。內嵌的 data URI 不需要附帶檔案。貼圖可以是 PNG、JPEG、WebP 或 KTX2（Basis Universal），幾何可以是 Draco 或 meshopt 壓縮過的，因為檢視器兩種解碼器都內建，會讀 JSON chunk 裡的擴充清單來決定用哪一個。

渲染內容：單一方向光下的 PBR 材質，可另外掛環境貼圖；可切換的 1 公尺網格，方便你看實際比例；檔案裡每一段動畫的片段清單；還有一個統計面板，列出三角形數、頂點數、節點數、繪製呼叫估計值，以及每張內嵌圖片的像素尺寸與位元組大小。唯一的硬限制是記憶體。100 MB 的 GLB 在桌機通常開得起來；手機分頁可能在解析完之前就被瀏覽器砍掉。

另一條路是來回跑：開 DCC、匯入、看一下、匯出、載進引擎、發現問題、再回頭。每一段都要好幾分鐘，而且每一段都可能自己改到東西，最後你是在除錯流程，不是在除錯素材。把檢查留在檔案本來就在的那個分頁，就少了這趟來回；更有用的是，你讀到的數字就是即將出貨那個檔案裡的數字。

檢查：線框、法線、UV 佈局、材質

四個檢視就能在壞掉的匯出檔進到引擎之前擋下大部分問題。線框顯示三角形密度，也看得出匯出器在哪裡把 n 邊形三角化。法線顯示面的朝向，所以裡外翻過的面在單一方向光下會是一片黑。UV 佈局把 UV 通道攤平成格線、底下墊著貼圖，重疊的島、被拉開的 texel、跑到 0 到 1 範圍外的幾何，全都一目了然。材質檢視則列出每個材質的貼圖、alpha 模式、雙面旗標與色彩空間設定。

永遠先檢查再壓縮。Draco 與 meshopt 會重寫頂點緩衝區、改變頂點佈局，而重新調整貼圖尺寸可能把你原本就有的接縫藏起來。先壓縮的話，你就分不清瑕疵是自己造成的，還是壓縮器造成的。

統計面板也是檢查的一部分。動手之前先把三角形數、頂點數、節點數、材質數，以及每張內嵌圖片的尺寸記下來。這些是你每次壓縮後拿來對照的基準數字，也會告訴你哪一根槓桿真的值得拉。

壓縮 GLB，又不要把它弄壞

三根槓桿，份量並不相等。丟掉沒人參照的資料不用付代價，重新匯出就能還原。重新編碼貼圖通常能砍掉一份素材大部分的位元組，因為圖片就是檔案裡的大宗。幾何壓縮是唯一可能把模型弄壞的一根，所以放最後。

這幾步都沒有保證的壓縮比。一張 4096×4096 PNG 的 GLB，跟以頂點資料為主的 GLB，行為完全不一樣；一個網格吃重、30 張 512 貼圖的場景，也不會跟單一角色配一張 4K 圖集的反應相同。每一步之後都量一次，別相信別人素材上的數字。

解碼器是出貨條件，不是細節。Draco 需要 Draco 解碼模組，meshopt 需要 MeshoptDecoder，KTX2 需要轉碼器並指定正確的目標格式。three.js 附的是 GLTFLoader，但 DRACOLoader、MeshoptDecoder 和 KTX2Loader 要你自己接；Babylon.js 和 Unity 的 glTFast 有對應的東西。如果你用的擴充 runtime 不認識，模型會載成一片黑或直接丟錯，而且看起來會像檔案壞掉，不像設定失誤。

GLB、glTF、FBX — 你的引擎要哪一種

glTF 2.0 是執行時格式。GLB 與 .gltf 是同一份資料的兩種容器：GLB 把 JSON 和二進位緩衝區放進同一個檔案，.gltf 則把它們分開，一份可讀的文字加附帶檔案。FBX 是比 glTF 更早的 DCC 交換格式，至今仍是大多數綁定師與動畫師交件的格式；OBJ 只有幾何，沒有動畫，也完全沒有 PBR 材質。

軸向與單位慣例造成的匯入問題，比檔案大小還多。glTF 用公尺、Y 軸向上、右手座標系，攝影機看向 -Z。各家 FBX 匯出器對單位的看法不一致，公分與公尺搞錯，模型就會差大約 100 倍，太小或太大。Blender 的 glTF 匯出器會幫你把 Z-up 轉成 Y-up；把這個關掉，模型進來就是躺著的。先拿一個已知尺寸去對照檢視器裡的邊界框，再回頭怪引擎。

為網頁最佳化：繪製呼叫、貼圖尺寸、多邊形預算

把這些當成每個專案各自調整的起點，不是上限。一個能在中階筆電上穩住影格率的瀏覽器場景，通常落在數十萬顆三角形以內，而且更重要的是繪製呼叫在幾百次以內。instancing 與材質合併能動第一個數字；第二個數字除了把幾何合併起來，沒有別的辦法可以動。

繪製呼叫是以每個網格搭每個材質來計算。兩百個各自帶獨立材質的道具就是兩百次繪製，即使每個只有幾百顆三角形；把它們送出去的 CPU 成本可能超過幾何本身的 GPU 成本。把共用材質的靜態幾何合併、把小貼圖收進同一張圖集、重複的道具用 instancing。透明材質的代價比它的三角形數看起來高，因為它要逐像素排序與混合，而投射陰影會把同一份幾何再渲染進一張深度圖。

貼圖尺寸通常同時主宰檔案大小與 VRAM，而這一點很多人搞反。一張 4096×4096 的 RGBA8 貼圖，在還沒算 mipmap 之前就佔 67,108,864 位元組的記憶體，mipmap 再往上加大概三分之一；相較之下，十萬顆三角形、位置法線 UV 各 4 位元組的網格只有幾 MB。一張隨便做的 4K 法線貼圖，重量就超過它底下那整份網格。KTX2 讓貼圖在 GPU 記憶體裡保持壓縮，這省的是跟檔案大小不同的東西，而且常常是行動裝置上真正要緊的那一項。

色彩空間也該列進來，因為它經常設錯。基礎色與自發光是 sRGB。法線、metallicRoughness 與遮蔽是 linear。弄反的話，材質不是褪色就是過暗，而且再怎麼調燈光都救不回來，因為資料在載入時就被解讀錯了。

壓縮之前，先檢查一個真實模型

讀拓樸跟把它轉起來看是兩回事。這一頁內嵌了 Blender Model Gallery，以線框模式呈現，你可以轉動一個真實的匯出檔，看到引擎實際上會畫的三角形，而不是建模的人看到的那堆乾淨四邊形。

轉的時候看三件事。曲率：三角形擠在一起的地方就是匯出器加三角形的地方，一面 20 顆三角形的平牆旁邊站著一顆兩萬顆的球，這很正常。接縫：跨過一條邊陰影就變，代表頂點在那裡被拆開，在 UV 接縫上是對的，在平滑面上是錯的。輪廓：玩家從遠處讀的是外形，而外形在減面之後比內部細節更能保住。

Mini World 和 The Cyclops' Island 裡出貨的素材也套用同一套預算，兩者都是透過 3D game builder 在瀏覽器分頁裡跑的。一個道具自己 40k 三角形沒問題；一個場景裡放四十個就不行，而線框檢視就是讓你在影格率發現之前先發現這件事的地方。

走進它所屬的那個世界

精靈是沒有地方站的角色。最後這一步是別人沒提供的：把你剛做好的精靈表放進一個有人能走動的世界 — 一座小島、一顆行星、一個下雨的街角。這個網站上的每個世界都是從一段文字描述做出來的，並且發佈成一個可以直接玩的頁面。

常見問題