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

瀏覽器中的 GLB 檢視器會在分頁內解碼檔案，並以 WebGL 繪製。將 .glb 或 .gltf 拖曳到頁面上，在桌機上模型會在數百毫秒內出現在畫面中；沒有上傳步驟、沒有安裝程式，也不需要帳號。GLB 是將 glTF 2.0 素材打包成單一二進位檔案：12 位元組的標頭、描述場景圖的 JSON 區塊，以及存放頂點緩衝區、索引緩衝區，通常還包含內嵌圖片的 BIN 區塊。

同一個頁面就是遊戲製作流程中的檢查與縮小步驟。你開啟匯出檔，檢視線框、法線、UV 島與材質插槽，確認從 Blender 或 Maya 匯出的過程中沒有損壞，接著壓縮檔案並下載一份給你的引擎。本頁說明每個檢查檢視能抓出什麼問題、三個壓縮槓桿以及拉動它們的順序，還有瀏覽器場景實際上必須遵守的預算。

在這裡直接開啟 .glb

將檔案拖曳到放置區，或用檔案對話框挑選一個。頁面會透過 File API 以 Blob URL 加上 ArrayBuffer 讀取它，並在同一個分頁中解析。操作時打開瀏覽器的網路面板：沒有任何請求會夾帶模型。不會排入佇列、不會寫入伺服器，關閉分頁後即銷毀。

在本機處理有兩層意義。首先是隱私：尚未公開的角色、受保密協議約束的客戶專案、你付費購買的掃描素材。把這些送進第三方轉換器，在成為效能問題之前先是授權問題。其次是延遲：在 10 Mbps 的上傳連線上傳送 40 MB 的 GLB，轉換還沒開始就得先等大約半分鐘，而這樣的等待會改變你實際檢查檔案的頻率。從 SSD 本機讀取只需一瞬間，解析成本也只是你自己的機器上的 CPU 工作。

可接受的輸入：.glb 是單一檔案的情況。.gltf 是以 JSON 表示的相同場景，因此通常會連同 .bin 緩衝區和一個圖片資料夾一起出現。將它們多選、拖曳整個資料夾，或拖入 zip，檢視器就會解析相對 URI。內嵌的 data URI 不需要附屬檔案即可運作。貼圖可以是 PNG、JPEG、WebP 或 KTX2（Basis Universal），幾何也可以是經 Draco 或 meshopt 壓縮的，因為檢視器同時內建兩種解碼器，並讀取 JSON 區塊中的擴充功能清單來決定該用哪一種。

它渲染的內容：在單一平行光加上選用環境貼圖下的 PBR 材質、可切換的 1 公尺格線以便讀取真實比例、檔案中每個動畫的片段清單，以及統計面板，內含三角形數、頂點數、節點數、繪製呼叫的估計值，還有每張內嵌圖片的像素尺寸與位元組大小。記憶體是唯一的硬性限制。100 MB 的 GLB 通常能在桌機上開啟；手機分頁則可能在解析完成前就被瀏覽器終止。

另一種做法是來回往返：開啟 3D 製作軟體、匯入、檢視、匯出、載入引擎、發現問題、再回頭。每一段往返都得花上數分鐘，而且每一段都可能引入各自的變更，於是你最後是在除錯流程，而不是在除錯素材。把檢查留在檔案原本所在的分頁中，就能省去往返，而且更有用的是，你讀到的數字就是你即將出貨的檔案裡的數字。

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

四種檢視能在大多數不良匯出檔送達引擎前就抓出問題。線框顯示三角形密度，並揭露匯出器在哪裡把 n 邊形三角化。法線顯示面的朝向，因此內外翻轉的表面在單一平行光下會呈現黑色。UV 佈局將 UV 通道攤平成格線，並在其後放置貼圖，讓重疊的島、被拉伸的紋素，以及落在 0 到 1 範圍外的幾何一目了然。材質會列出每個材質及其貼圖、透明模式、雙面旗標與色彩空間設定。

永遠都要先檢查再壓縮。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 有對應的元件。如果你用執行環境不認識的擴充功能來壓縮，模型會載入成黑色或拋出錯誤，而且看起來會像是檔案損毀，而不是設定錯誤。

GLB、glTF、FBX 之比較 — 你的引擎想要哪一種

glTF 2.0 是執行時格式。GLB 與 .gltf 是相同資料的兩種容器：GLB 把 JSON 與二進位緩衝區放進同一個檔案，.gltf 則將它們分開，成為可讀的文字加上附屬檔案。FBX 是早於 glTF 的 3D 製作軟體交換格式，至今仍是大多數骨架師與動畫師交付所用的格式；而 OBJ 只有幾何，完全沒有動畫，也沒有 PBR 材質。

軸向與單位慣例造成的匯入錯誤比檔案大小還多。glTF 是公尺、Y 軸朝上、右手座標系，攝影機朝向 -Z。FBX 匯出器對單位看法不一，公分與公尺的不一致會表現為模型大約小了或大了 100 倍。Blender 的 glTF 匯出器會替你將 Z 軸朝上轉換為 Y 軸朝上；把它關掉，模型就會側躺著送達。在怪罪引擎之前，先將檢視器中的邊界框與已知尺寸比對一下。

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

把這些當成你依專案調整的起點，而不是限制。能在中階筆電上維持穩定影格率的瀏覽器場景，通常低於數十萬個三角形，而且更重要的是，低於數百個繪製呼叫。實例化與材質合併會改變第一個數字；除了合併幾何之外，沒有什麼能改變第二個數字。

繪製呼叫是依每個網格、每個材質計算的。兩百個各自帶有自己材質的道具，即使每個只有幾百個三角形，也要花上兩百次繪製，而提交它們的 CPU 成本可能超過幾何本身的 GPU 成本。合併共用相同材質的靜態幾何，將小貼圖聚合成一張圖集，並對重複的道具做實例化。透明材質的成本比其三角形數所顯示的更高，因為它們要逐像素排序與混合，而投射陰影會把相同的幾何重新渲染到深度圖中。

貼圖大小通常同時主導了檔案與 VRAM，而這正是人們常搞反的部分。一張 4096×4096 的 RGBA8 貼圖在尚未計算漸遠貼圖前，記憶體中就是 67,108,864 位元組，而漸遠貼圖還會再加上大約三分之一；相較之下，一個有 4 位元組位置、法線與 UV 的十萬三角形網格只有幾 MB。一張不小心處理的 4K 法線貼圖，其份量就超過它所附著的整個網格。KTX2 讓貼圖在 GPU 記憶體中保持壓縮，這與檔案大小的節省不同，而且往往是行動裝置上真正要緊的那一種。

色彩空間之所以列在這裡，是因為它經常被弄錯。基礎顏色與自發光是 sRGB。法線、metallicRoughness 與遮蔽是線性。把兩者對調，材質就會看起來褪色或太暗，而且再怎麼調整光照都救不回來，因為資料在載入時就被錯誤解讀了。

壓縮前先檢查真實模型

閱讀關於拓樸的說明，和實際旋轉它並不是同一回事。Blender Model Gallery 以線框模式內嵌於本頁，因此你可以旋轉真實的匯出檔，看看引擎實際會繪製的三角形，而不是建模者所見的整齊四邊形。

旋轉時留意三件事。曲率：三角形聚集之處就是匯出器添加它們的地方，而緊鄰著兩萬三角形球體的一面平坦二十三角形牆是正常的。接縫：跨越某條邊的陰影變化意味著頂點在那裡被分割，這在 UV 接縫處是正確的，在平滑表面上則是錯的。輪廓：外緣是玩家在遠處所讀取的形狀，而它比內部細節更能經受簡化處理。

同樣的預算也適用於 Mini World 與獨眼巨人島中出貨的素材，兩者都透過 3D 遊戲建立器在瀏覽器分頁中執行。一個本身有四萬三角形的道具沒問題；一個場景裡放四十個就不行，而線框檢視就是讓你在影格率察覺之前先發現這件事的地方。

走進它所屬的世界

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

FAQ