Meshy 管線，以及那件弄壞姿勢估測的長袍

生成式 3D 的好壞，取決於那條把提示變成執行期就緒資產的管線。RakuAI 打造了一條撐得過供應商端點憑空消失、Unicode 當機，以及各種示範影片絕不會給你看的摩擦的管線。

資產管線是引擎裡那種「無聊但承重」的部件之一。它負責把設計師的想法（「我想要塔防包裡有二十種敵人」）變成一個資料夾，裡面裝著有貼圖、有骨架、有 LOD 的 3D 資產，讓執行期能夠載入。過去六個星期，做這件事的管線是 Meshy.ai，透過一支七階段腳本串接，位置在執行期儲存庫的 scripts/meshy_asset_pipeline.py。

這個星期六早上，Meshy 管線和 SDK 內容包格式之間的 v1 橋接已經穩定到我可以把學到的東西寫下來了。三件事。沒有一件在 API 文件裡。

七個階段實際上在做什麼

依序，對每個資產：

1. 以預覽模式做文字轉 3D 生成。
2. 生成 PBR 貼圖：albedo、metallic、roughness、normal。
3. 輪詢並下載 LOD0。
4. 對 v1 API 建立 remesh 任務。
5. 輪詢並下載 LOD1 remesh。
6. 在磁碟上整理資產檔案。
7. 組裝內容包。

管線把一個資產從頭跑到尾，再換下一個。它不批次處理。不批次的原因來自下面的第三課，而且很痛。

第一課：長袍會弄壞姿勢估測

Meshy 的文字轉 3D 輸出對很大範圍的人形設計都沒問題。骷髏、士兵、騎士、露出手臂的法師。管線幫它們上骨架，骨架能用，資產出貨。

但對重度罩袍的人形就不行了。RPG 內容包在 Sprint 2 撞上這件事。四個理應乾淨上骨架的資產在姿勢估測時輪廓萃取失敗。兩個在預料之中（slime 和 wolf_enemy 不是人形，姿勢估測器本來就不該在它們身上找手臂）。兩個是意外：mage_hero 和 blacksmith。都是人形。都失敗了。

失敗的關鍵在輪廓。Meshy 的姿勢估測器看模型渲染出來的外框輪廓來找四肢。穿長袍的法師在輪廓裡沒有可見的腿，所以沒有腿部關鍵點可以錨定骨架。穿圍裙的鐵匠在胸和髖之間沒有可見的軀幹分界，所以脊椎關節猜錯位置。模型沒問題。骨架是錯的。

管線側的修法是記錄失敗、保存未上骨架的幾何，並在資產清單裡標一個旗標，寫著「這一個需要人工上骨架」。提示側的修法是為任何需要自動上骨架的人形，在文字提示裡指定「緊身衣物、露出四肢」。更長期的修法在 Meshy 那一側，不是我們能做的。

橫跨十三種遊戲類型，失敗率並不平均。塔防五個裡失敗一個。平台跳躍六個裡失敗一個。RPG 十一個裡失敗四個，而那四個裡有三個是衣物幾何。這一課可以推廣：當生成式模型失敗時，失敗通常不是隨機的，而失敗模式會告訴你這個模型的訓練資料長什麼樣。

第二課：Unicode 會讓任何把 stdout 導向檔案的東西當掉

RPG 包裡的鬼族陣營用日文角色名稱。風代表 wind，雷代表 thunder，金剛代表 diamond。這些就是提交給 Meshy 任務時的資產名稱。管線在背景執行，把 stdout 重新導向到日誌檔，之後再解析日誌看哪些資產成功了。

鬼族資產第一次跑的時候，每一個都失敗了。錯誤是 Python 的 stdout 丟出 UnicodeEncodeError。建置機器上的預設編碼，在 stdout 不是 TTY 時是 ASCII。日文字元不是 ASCII。print 陳述式在資產送交 Meshy 之前就當掉了。

修法是啟動腳本裡的一行：PYTHONIOENCODING=utf-8。設好這個環境變數之後，print 陳述式正常運作，資產也生成了。

這一課比我的年紀還老：任何把 Unicode 送過 stdout 重導向管線的東西，都需要明確設定編碼。一個已經被記載了二十年的問題，賠掉了兩天。記進行為日誌了。在啟動腳本裡修好了。Meshy 沒修，因為這不是 Meshy 該修的問題。

第三課：供應商 API 會憑空消失

Sprint 2 進行到一半，Meshy v2 的 /remesh 端點開始回 404。不是針對特定資產。是每一次呼叫。

remesh 階段負責把 LOD0（高面數、渲染昂貴）變成 LOD1（低面數、渲染便宜）。少了 remesh，資產出貨時就只有 LOD0。它們在開發者機器上渲染得好好的，卻會在 AR 眼鏡目標上把幀率殺死。

我不知道這個端點是被棄用了、被鎖進更高階的方案了、搬家沒留轉址了，還是暫時掛了。Meshy 的文件仍然引用它。對它的呼叫回 404。管線不能等供應商搞清楚到底是哪一種。

修法在 meshy_asset_pipeline.py 的 remesh 階段。在 remesh 呼叫外包一層 try/except。失敗時，把資產記錄為僅有 LOD0，把這個事實寫進資產清單，然後繼續跑完管線其餘部分。每個資產都有 LOD0。有些有 LOD1。內容包無論如何都能出貨。

這一課是每個依賴供應商 API 的專案終究會學到的：你依賴的 API 不是你的，它可能在你腳下改變，唯一的防禦就是優雅降級。我們現在有了。

管線現在走到哪裡

十三種遊戲類型完成了八種。太空射擊、益智、卡牌對戰、跑酷、平台跳躍、賽車、塔防、RPG。剩下五種（運動、模擬、沙盒、格鬥、輕量 MMO）排在佇列上。

點數預算是意外之喜。Sprint 2 的估算是該類型兩個陣營合計約 510 點。實際花費持續比估算低 25 到 35 個百分點。這給了整個計畫足夠的餘裕，可以把剩下五種類型推完，不用再開一次預算會議。

本月初落地的 v1 橋接，也就是帶著二十四個一致性測試的 scripts/generate_rakupack.py，是讓這一切能從 SDK 側取用的關鍵。使用 SDK 的開發者不需要知道一個資產是出自 Meshy 還是出自手工建模的管線。內容包格式就是契約。Meshy 管線產出內容包。SDK 載入內容包。

為什麼我要把這一篇寫下來

兩個理由。

第一，上面那三課正是那種不會出現在供應商示範裡、也不會出現在行銷頁面上的摩擦。長袍與姿勢估測。Unicode 與 stdout。remesh 與 404。如果你正在評估一家生成式 3D 供應商，讀到這裡然後說「這正是我在下決定之前想知道的事」，那這篇文章就值回票價了。

第二，管線現在已經穩定到，下一場對話不再是「Meshy 對我們可不可行」，而是「我們想要資產庫成為什麼樣子」。那是設計師的對話，不是工程的對話。工程這一側已經藉由讓路完成了它的工作。

八種類型完成。還有五種。管線撐得過 404。管線撐得過日文字元。管線目前還撐不過一件長袍。這個星期六花得值得。