外包 3D 模型的進件、重現與驗收流程

glTF 規格保證什麼，不保證什麼

glTF 是 Khronos Group 發布的開放格式，用來在不同工具與引擎之間傳輸 3D 資產，也是網頁 3D 資產的開放標準格式（Khronos 3D Formats 工作小組，2021）。格式保證的是互通：符合規格的檔案，可以在不同工具之間交換。格式不保證內容正確。缺面的網格、重複匯出的節點、名稱掛錯的零件，在格式上全都合法。

Khronos 公開的 glTF-Validator 依 glTF 2.0 規格檢查 JSON、GLB、緩衝區與貼圖，提供瀏覽器版、命令列與 npm 套件，可以放進自動化流程（Khronos Group，glTF-Validator）。把驗證器放在進件的第一關是合理的用法。這是本文的建議，驗證器的說明頁並未提到進件流程。驗證器回答的是檔案合不合規格，不回答內容對不對這個產品。缺面、多餘節點、零件名稱對不上綁定規則，都是內容問題，要靠後面幾關的比對來擋。

針對產品類的 3D 內容，Khronos 的 3D Commerce 另有一份資產製作指南，目前為 2.0 版（2025 年），目標是讓產品的照片級數位孿生能在網頁、應用程式、遊戲與 XR 中使用（Khronos Group 3D Commerce，2025）。與建模方約定規格時，這份公開指南可以當作雙方共同的參照，細節以原文為準。

建模方交的檔只是原料，上架檔要能從來源重現

外包建模的檔案，常見的狀況是缺面、重複匯出、帶多餘的節點，或是前一手動過手腳。這樣的檔案若直接複製上架，之後沒有人說得清楚上架的版本是怎麼來的，畫面出問題時，連該從哪裡查起都不知道。開發團隊因此只守一條規則：不存在直接複製上架。

每一支上架檔都記錄三件事：來源、產出、參數。另有一道指令，驗證上架檔能從來源重現。重現驗證比的是結構與包圍盒，不比位元組，因為壓縮會改寫位元組，節點的世界座標也會跟著變動，拿這兩者來比，整批都會誤報。建模方改了什麼，同樣用「來源對上架」的差異腳本比對，判定量只用包圍盒。

另有三條通用規則。

• 重壓任何資產之前，先比對線上版與原始檔的材質旗標。從原始檔重新壓縮，會把線上版手動修好的材質設定洗回原狀。
• 修改 GLB 不用圖形庫整檔讀寫。幾何會被重新編碼，檔案可膨脹到原本的約 1.4 至 2.9 倍。
• 要就地改貼圖，做位元組層級的修改：檔案大小不變，其餘位元組完全不動。

進件先逐項比對，畫面出問題時分得出是素材還是管線

進件的第一輪比對查三件事：缺面、重複、多餘節點。曾有一次進件，來源模型的某個配色，其中一個零件缺了約 270 個三角面，另有約 60 個三角面的貼圖座標被拉伸。這次的修法只動幾何，貼圖的位元組一個都沒動。

畫面出現碎片或破洞時，開發團隊用逐項排除，把素材與管線分開。順序固定，每一步只排除一種可能。

同款兩個配色的同名部位互比，可以看出問題是否只出現在其中一個配色。原因判在素材這一側，退回建模方的清單會附上部位與數量；判在管線這一側，由開發團隊自行修正，不占用建模方的時間。

壓縮之後，解碼回來比原值，全量比，不抽樣

貼圖壓縮的驗證，做法是把壓縮後的檔案解碼回全解析度，與來源圖逐張比對，全部的張數都比。KHR_texture_basisu 擴充描述的是 KTX v2 容器搭配 Basis Universal 超壓縮，引擎要把通用格式轉碼成平台支援的區塊壓縮格式（Callow 等，2020）。轉碼後的顏色是否與來源一致，要由進件這一側自己量。

產品外觀色的貼圖改成 GPU 壓縮格式後，個別配色可能看起來發灰，直覺會判斷是素材壞了，打算請建模方重出。全解析度解碼來源圖與壓縮檔，再比平均色，才會發現是低位元率的 ETC1S 格式把個別貼圖的顏色端點壓向灰。改用高品質的 UASTC 格式，同一個來源重新編碼，顏色即還原，每張只多約 30 KB。同一批的其餘顏色用 ETC1S 完全正常，所以這是逐張才會出現的現象，抽樣看不出來。

驗證本身有兩個陷阱。解碼要在乾淨獨立的資料夾進行，並取最大的 mip 層級，否則用檔名萬用字元會抓到錯的層級，得到假數字。解壓指令會輸出多種變體，若餵成 alpha 通道，整批顏色都會被驗成白灰。至於抽樣只驗少數幾張，剛好漏掉出問題的那一張。結論是全量比只是一支迴圈，沒有理由抽樣。

含透明的貼圖一律走高品質格式，因為低位元率格式把 alpha 編成另一張切片，鏤空的邊緣會破碎。反方向則是純色貼圖該縮小。GPU 的佔用由解析度決定，與磁碟上的檔案大小無關，整面純色卻保留高解析度的貼圖，壓縮後在磁碟上幾乎沒有體積，所有只看檔案大小的稽核都看不見這種貼圖。判定量是解碼後逐通道（含 alpha）的標準差：標準差為 0 就是純色，可以縮成 4×4，畫面不變；其餘的是真圖，不能動。

整體的記憶體預算與首屏負擔怎麼控制，是另一個題目，見網頁 3D 的效能工程。

會變形的零件：不二次量化，修資料沒有盡頭時改用程式重建

隨骨架變形的零件（蒙皮網格）需要特別處理。有些建模方交來的檔已經壓縮過，管線若解碼後再用預設位元數壓一次，就是二次量化：法線被推到不同的網格上，零件出現可見的變形，看起來像是沒有綁到骨架。所以蒙皮零件永不做二次量化，直接使用原檔，壓縮腳本要把這類節點排除。

驗證蒙皮零件，不能看網格的包圍盒，那是攤平的綁定姿勢；要量骨頭的世界座標。

另一類問題是接縫處斷開一截。零件的原檔是一條連續的帶狀網格，貼圖單元的節距不等於骨頭的節距。常見的修資料做法有三種：補回塌掉的單元、依最近的段重新綁定、整段平移到中位數。結果往往是修好這一格，別的格又開洞；用單元中心的距離去量，還會算出不存在的假缺口。

較穩的做法是放棄修資料，改寫成程式：沿著骨頭路徑等距放置剛性單元的實例化網格，UV 與寬度從原網格量取，原檔維持原樣。之後換任何新款式，只要骨頭描對路徑就能用。外包模型的瑕疵，修資料有時是無底洞，每個款式壞的方式都不同；寫成程式，修的是規則，不是個案。

3D 的失敗不報錯：驗收看數字，不看截圖

3D 配置器的問題常常不報錯：主控台乾淨，自動化測試全綠，畫面看起來還好，卻有一個零件沒跟著折疊，或位置差了 2 公分。原因是一個模型項目要上線，GLB 節點名、綁定規則、資料、前端清單四層都要接上，漏掉任何一層，結果都是零錯誤、東西不在。

LIDROP 的 3D 配置器採用的驗收表，每一項都同時寫明「算作證據」與「不算證據」。整體做法見LIDROP 3D 配置器的做法，專案本身見LIDROP 案例。

截圖 diff 不算證據。場景的相機有多處程式在寫入，整張圖本來就一直在變，差異分不出是哪個改動造成。另有兩項：材質與貼圖的數量要與線上的那一顆相同；有多個款式時，每個款式都驗，各自留下證據。這套檢查收成一道指令，一次跑 7 項，涵蓋節點綁定、相機、型別、行為快照等。

只有掃描檔、舊模型或 CAD 時的做法

建模方若能事先把配色做好，glTF 有地方存放：KHR_materials_variants 擴充以緊湊格式在一個資產內存放多組預先做好的材質變體，執行期一次只啟用一組（Bond 等，2018–2020）。進件時，各變體之間的同名部位要能互相對照，這也是流程裡納入同款不同配色互比的原因。

客戶只有一個掃描出來的整體模型時，仍然能做部位換色。這類掃描模型的材質粒度可能太粗，同一個材質同時涵蓋好幾個部位。開發團隊的做法是在載入時依三角形的座標分區：逐個三角形計算世界座標的重心，落在分類區域盒內的三角形，重排到各自的幾何群組並配上專屬材質。約 19 萬個三角形，一次約 0.2 秒，而且只在載入時跑一次。

換色時，材質複製成「原名@分類碼」，只染帶標記的那幾個，所以共用同一個原材質的部位互不影響。切分之後有連鎖影響：兩個部位原本共用同一材質，切分後其中一個成了帶標記的新材質；比對特定材質名稱的規則，慣例上會先去掉標記，於是原本不相干的另一個部位也被比對到，連帶受到同樣的效果。該名稱因此要加上「只認未標記」的例外。

客戶手上有 CAD 時，重點是動工前先講清楚轉換的範圍。LIDROP 收到的是 CAD 爆炸視圖，要求網頁版照同一序列展開與組回。原檔的動畫區段解析出 52 步，對應成網頁上的 31 段時間軸；進度只有一個變數，相機取景、標籤與軸線全都只讀這個變數。動工前，開發團隊把不會轉進網頁版的部分白紙黑字列成清單：位移為 0 的佔位步驟、組合件內沒有獨立位移的子零件、爆炸時整條隱藏的線材。驗收時才不會有落差。組裝狀態的畫面與改動前逐像素相同。

手上只有舊模型、掃描檔或 CAD 時，先評估現況再決定工法，這屬於3D 互動開發的範圍。

建模方、開發團隊與客戶各負責什麼

責任界線先講清楚，後面才不會互相推。素材本身的缺陷，由建模方補件或重出；上架檔的重現與驗收，由開發團隊負責；客戶決定要換哪些部位，並在建模方不提供來源檔時決定是否重建。建模方與開發團隊之間誰負責什麼，也是評估軟體廠商時要先問清楚的事，見如何挑選軟體廠商。

不適合的情況

• 只需要一張靜態渲染圖。進件、重現、驗收都是為了反覆上架與換版，單張圖用不到這套流程。
• 模型只會用一次，不會再換版。重現與比對的成本，要靠換版時省下的查錯時間回收。
• 建模方不提供來源檔，又沒有預算重建。上架檔無從追到來源，重現這一步做不到，要先處理來源的問題。

要先準備什麼

• 現有的模型檔或 CAD 檔，有來源檔就一併提供。
• 建模方的資訊，包含當初約定的規格，以及來源檔能否取得。
• 要換的部位清單。

資料備齊後，請說明模型現況，與開發團隊討論。