GLB 太大、手機跑不動，請廠商優化，對方會報一個「省了多少」。這個數字可能是檔案大小、下載量，也可能是載入後的記憶體，三者不是同一件事，常常還往相反方向走。
下面是開發團隊在 LIDROP 3D 配置器 和 淇豪廣告的首頁 3D 城市 做過的前後數字，每一列寫清楚量什麼、怎麼量、適用範圍。LIDROP 整個專案另寫在 摺疊車 3D 配置器的開發拆解。
兩個前提：除非註明，數字都量於桌機（M1 Pro），不直接代表手機；LIDROP 有兩種口徑（首屏 7 支 GLB 下載量、整頁首屏下載量），不能相加或並列比較。
下載量最小，不等於記憶體最小
LIDROP 首屏載入 7 支 GLB。開發團隊把建模師的原始檔用三種方式重壓：meshopt、qdraco（本專案指量化過的 Draco）、純 draco。下載量純 draco 最小，16.31MB；qdraco 21.18MB；meshopt 26.32MB。
解碼後情況相反。放進 GPU 的幾何，meshopt 52.18MB，qdraco 約 52MB，純 draco 96.86MB，約為另外兩種的 1.86 倍，因為純 draco 解碼後的頂點座標是 Float32，另外兩種是 Int16。手機記憶體吃緊時，解碼後的大小比下載量更要緊，所以沒選純 draco，定案 qdraco：下載量比 meshopt 少 19.5%，GPU 幾何沒增加。
- 26.32MBmeshopt52.18MB
- 21.18MBqdraco定案約 52MB
- 16.31MB純 draco96.86MB
LIDROP 首屏 7 支 GLB。GPU 幾何由 GLB 內容估算，不含貼圖。
這組 GPU 幾何只算首屏這 7 支的幾何，不含貼圖，是解析 GLB 內容估的。三種編碼都從建模師的原始檔重壓，這樣比較才站得住腳。
前後對照表
「前」「後」是同一量法下的兩個數字，跨列不要相加；「量測方式」欄註明各列的量法與範圍。
| 對象 | 指標 | 前 | 後 | 量測方式 |
|---|---|---|---|---|
| LIDROP 首屏 7 支 GLB | 下載量 | meshopt 26.32MB | qdraco 21.18MB（少 19.5%） | 三種編碼都從原始檔重壓。純 draco 為 16.31MB |
| 同上 | GPU 幾何（解碼後，不含貼圖） | meshopt 52.18MB | qdraco 約 52MB；純 draco 96.86MB | 解析 GLB 內容估算 |
| LIDROP H6 整頁 | 首屏下載量 | 36.5MB | 32.5MB | 建置後用 headless 瀏覽器讀資源載入紀錄，依副檔名分類（GLB 約占 80%）。做法：縮小會被換掉的底色圖、降一張貼圖解析度、延後載入一份資訊檔 |
| 淇豪首頁 3D 城市 | GPU 貼圖記憶體：8 張 4096 x 4096 降到 2048 x 2048（WebP 品質 80） | 約 681MB | 約 170MB | 以「張數 x 邊長² x 4 位元組 x 4/3（mipmap）」核算 |
| 同上 | 貼圖下載量 | 3.38MB | 2.84MB | 貼圖檔案大小 |
| 同上 | GPU 記憶體：再改 KTX2（ETC1S、含 mipmap） | 約 170MB | 約 30MB | 估算；這組貼圖已進正式版本。兩步合計約 681MB 到約 30MB |
- 8 張 4096 x 4096約 681MB
- 降到 2048 x 2048約 170MB
- 再改 KTX2約 30MB
淇豪首頁 3D 城市的 GPU 貼圖記憶體。數字為估算，這組貼圖已進正式版本。
第二張表：一棟建築模型
這張表來自與 Mxm 共同開發的建案看屋網站。原始建模檔約有 3,400 萬個頂點、4,900 萬個面、1.9 萬個物件，沒有燈光與攝影機。
| 對象 | 指標 | 前 | 後 | 量測方式 |
|---|---|---|---|---|
| 一棟建築模型 | 塔樓外殼面數（保形減面） | 約 240 萬面 | 約 70 萬面 | 腳本計數；先焊接頂點（1.5mm），再用角度溶解（門檻 0.75° 到 2.5°） |
| 同上 | 室內全景圖 | 約 60 張 6000 x 3000，原始約 300MB | 4096 x 2048 WebP 加 512 x 256 底圖，共約 15MB | 檔案總大小 |
| 同上 | 植栽約 800 棵 | 原渲染檔格式約 3GB | 輸入約 50KB | 檔案大小；不載植栽模型，由標記點即時生成實例 |
兩種口徑的下載量不能並列比較
- LIDROP 首屏 7 支 GLB 的下載量：26.32MB 到 21.18MB。
- LIDROP 整頁的首屏下載量：36.5MB 到 32.5MB，GLB 約占 80%。
兩者的範圍與量法都不同：前者只算 7 支 GLB 的檔案，後者是整頁首屏載入的全部資源，GLB 只是其中一部分。不能相加，也不能並列比較。
壓縮與量測的做法
比較要從原始檔出發
要比較不同編碼，每一種都從建模師的原始檔重壓。拿已經壓過的檔再壓一次，或在兩種編碼之間互轉，量化會疊加，得到的數字代表不了編碼本身。
重壓前先列出手動修正
手動修過的材質設定，例如透明混合改成透明裁切、雙面材質的取捨，從原檔重壓時會被蓋回預設。重壓前先列出手動修正的項目，壓完逐項核對。
等場景載完再量，分頁與 GPU 行程都要量
載入期間畫布較小，數字偏低。要先確認場景已載完再量（畫布寬度等於視窗寬度乘像素密度）。Chrome 分頁的「記憶體用量」也不含 GPU 行程，兩個都要量。
用真 GPU 量
headless 瀏覽器預設用軟體算繪，會把 KTX2 壓縮貼圖整張解開，記憶體數字被灌大。要量記憶體，用真 GPU。
降像素密度之前，先確認瓶頸在像素
互動時暫時降低像素密度，聽起來合理，但只有場景被像素數綁住時才有用。先量清楚瓶頸在像素、draw call 還是三角形數，再決定要不要動。瓶頸不在像素，來回切換本身就是額外的成本。
- 想降像素密度互動時暫時降低
- 先量瓶頸像素、draw call、三角形數
- 瓶頸在像素可以降降像素密度才有用
- 瓶頸不在像素不要動來回切換是額外成本
數字的適用範圍
表裡的 GPU 數字為估算，桌機數字也不能直接換算成手機；手機實機的記憶體要在目標機型上另外量。
表中不列 fps，因為幀率取決於裝置、瀏覽器、解析度與場景，單一桌機的數字代表不了使用者的實際體驗。headless 預設只跑得出每秒 1 到 3 幀，瀏覽器分頁被隱藏時，動畫迴圈還會凍結。廠商若給幀率提升的百分比，請廠商說清楚裝置、瀏覽器、解析度與場景。
優化後的模型怎麼接成買家走得完的路徑，見建案 3D 看屋的路徑。
不適合的情況：壓縮不是答案
這幾種情況，先不要花錢壓模型：
- 模型已經夠輕，或檔案的大宗是貼圖。幾何編碼只動幾何，貼圖占大宗的部件，換幾何編碼沒有差別。
- 問題在場景的 draw call 或程式。瓶頸在那裡，降像素密度、把模型檔壓得再小也解不了。
- 客戶要求保留所有細節，例如高精度貼皮。高壓縮率的貼圖格式（ETC1S）可能出現色差，要保色準的貼圖可以改用畫質較高的 UASTC，檔案會大一些。要全部細節時，能壓的空間有限，先談好能接受的色差。
看廠商給的數字，要向廠商確認的項目
選廠商時其餘要看的地方，寫在 軟體外包廠商的評估表與簽約前查核項目。看廠商的數字時，先向廠商確認這幾項：
- 確認量的是檔案大小、下載量，還是載完後的記憶體。
- 要求廠商說明範圍是單一檔案、首屏，還是整頁。
- 確認在哪種裝置量：桌機、手機實機，還是模擬，以及 GPU 行程有沒有量。
- 請廠商說明比較的起點是原始檔，還是壓過的檔，以及畫質與手動修正有沒有核對。
- 若廠商給了幀率，請廠商列出裝置、瀏覽器、解析度與場景。
想知道手上的 GLB 值不值得壓，或想檢查一份優化報告的量法，可以把檔案、目標裝置和卡住的地方告訴開發團隊。3D 網頁開發會先量，再決定要不要動手。
