簡介一份面向Unity開發(fā)者的角色換裝技術(shù)示例工程圍繞網(wǎng)格合并、材質(zhì)管理與骨骼動畫三條主線演示如何通過CombineMeshes將身體、頭部、衣物等部位合并為統(tǒng)一網(wǎng)格并利用材質(zhì)實(shí)例與Animator控制器實(shí)現(xiàn)服裝切換和動作跟隨。內(nèi)容覆蓋模型拆分、材質(zhì)替換、動畫重定向等關(guān)鍵操作適合正在學(xué)習(xí)Unity渲染優(yōu)化或角色定制系統(tǒng)的初中級開發(fā)者。壓縮包共258個文件主體包含fbx角色模型、prefab預(yù)制體、mat材質(zhì)、cs換裝腳本及對應(yīng)meta/asset配置另含場景與工程設(shè)置整體僅4.54MB結(jié)構(gòu)緊湊便于直接導(dǎo)入查看。已有858人學(xué)習(xí)下載。通過閱讀工程中的腳本注釋與對象組織方式可快速理解繪制調(diào)用優(yōu)化、骨骼綁定注意事項(xiàng)以及換裝狀態(tài)的動態(tài)管理邏輯并在此基礎(chǔ)上擴(kuò)展出背包換裝、外觀預(yù)覽等更高階功能。1. unity mesh合并換裝先認(rèn)清它是渲染優(yōu)化方案還是骨骼綁定方案做一個帶換裝的角色最常見的做法是給每個部件單獨(dú)掛一個 SkinnedMeshRenderer。頭發(fā)、頭、上衣、下裝、手套、鞋子六個部件六個材質(zhì)球、六份骨骼綁定、六次 Draw Call。角色一多移動端直接燙手。把多個部件的 Mesh 合并成一個同時保留骨骼蒙皮信息就是 unity mesh合并換裝要做的事。它不是把模型原地拼起來那么簡單背后是骨骼索引重映射、bindposes 重建、材質(zhì)與貼圖合并三件事。這篇文章寫給做捏臉、時裝、角色預(yù)制的客戶端程序看完能自己實(shí)現(xiàn)一套可運(yùn)行的運(yùn)行時合并流程也明白哪些坑繞不開。2. 為什么換裝必須合并Draw Call、骨骼與蒙皮權(quán)重的關(guān)系2.1 換裝系統(tǒng)的渲染壓力六件套就是六次 Draw Call換裝游戲的渲染壓力比普通角色多一倍不止。一個不換裝的角色往往只有一個 SkinnedMeshRenderer一張貼圖、一個材質(zhì)球移動端上就是一個 Batch。換裝角色每個部件單獨(dú)渲染六個部件就是六個 Batch如果每個部件還帶描邊材質(zhì)、陰影材質(zhì)Batch 數(shù)量直接翻倍。Unity 的靜態(tài)合批對 SkinnedMeshRenderer 無效動態(tài)合批又要求網(wǎng)格頂點(diǎn)數(shù)和材質(zhì)一致?lián)Q裝部件基本不滿足條件。最終壓力全部落在 CPU 的渲染狀態(tài)切換和 GPU 的頂點(diǎn)輸入上。我自己做過一次實(shí)驗(yàn)一個 5 萬面角色拆成六個部件每個部件 8000 到 12000 面。每個部件獨(dú)立渲染時Frame Debugger 里看到 6 個 Batch、12 個 SetPassCall因?yàn)橛械牟考Я藘蓪硬馁|(zhì)。角色同屏 20 個Batch 沖到 120 以上中端安卓機(jī)幀率直接掉到 30 以下。合并成一個 SkinnedMeshRenderer 之后同屏 20 個角色的 Batch 數(shù)降到 20 左右?guī)驶謴?fù) 60。這個對比就是換裝合并最直接的價值不是省顯存是省狀態(tài)切換。2.2 三種常見合并方案離線合并、運(yùn)行時合并與骨骼換裝行業(yè)內(nèi)做換裝合并有三條路線適用場景完全不同。離線合并也叫編輯器合并美術(shù)在導(dǎo)出階段就把所有換裝組合烘焙成獨(dú)立 Mesh 和材質(zhì)。好處是運(yùn)行時零開銷壞處是組合數(shù)量爆炸6 個槽位每個 10 個選項(xiàng)就是 10 的 6 次方種組合全部烘焙不現(xiàn)實(shí)。實(shí)際項(xiàng)目里只烘焙常用組合和默認(rèn)形象。運(yùn)行時合并是大多數(shù)換裝項(xiàng)目的選擇也就是把各個部件的 SkinnedMeshRenderer 在角色創(chuàng)建或換裝瞬間合并成一個。Unity 官方的 Mesh.CombineMeshes 能合并頂點(diǎn)和三角形但不會處理蒙皮骨骼索引和 bindposes直接用來合并 SkinnedMeshRenderer 會導(dǎo)致動畫播放時權(quán)重錯亂。后面第 3 章的核心代碼就是解決這件事。第三種叫骨骼換裝不合并 Mesh只替換骨骼上掛的節(jié)點(diǎn)。它常用于部件差異特別大的場景比如武器、翅膀、尾巴這種獨(dú)立附著物。骨骼換裝的問題是部件還是獨(dú)立渲染Draw Call 沒有本質(zhì)改善只解決了骨骼復(fù)用問題。對時裝類換裝Mesh 合并才是正解。2.3 合并的本質(zhì)不是頂點(diǎn)搬家而是骨骼索引重映射很多第一次做換裝合并的程序員拿著 Mesh.CombineMeshes 直接干合出來的模型靜止時看不出問題動畫一播就整個扭曲。原因很簡單CombineMeshes 只管頂點(diǎn)的 position、normal、uv、triangle它不知道每個頂點(diǎn)受哪根骨骼影響。SkinnedMeshRenderer 的每個頂點(diǎn)都有 BoneWeight里面存了四根骨骼的索引和權(quán)重。這四個索引指向的是 SkinnedMeshRenderer.bones 數(shù)組而 bones 數(shù)組里每根骨骼又對應(yīng)一個 bindpose也就是骨骼綁定到 Mesh 空間的逆矩陣。三個數(shù)據(jù)必須一一對應(yīng)頂點(diǎn)權(quán)重里的索引、bones 數(shù)組里 Transform 的位置、bindposes 數(shù)組里矩陣的位置。換裝部件的 bones 數(shù)組長度和順序各不相同直接合并后索引指向錯位動畫自然崩。所以合并換裝的核心技術(shù)動作是先把所有部件的骨骼收集成一個統(tǒng)一的骨骼列表再把每個頂點(diǎn)權(quán)重里的骨骼索引改寫成統(tǒng)一列表里的新索引最后重建 bindposes 數(shù)組。這個流程有個嚴(yán)格前提所有部件必須共享同一套骨骼層級和命名。美術(shù)導(dǎo)出時統(tǒng)一 T-Pose、統(tǒng)一骨骼命名、統(tǒng)一模型空間原點(diǎn)運(yùn)行時才能合并這點(diǎn)后面還會反復(fù)提到。3. 用 SkinnedMeshCombiner 在運(yùn)行時合并換裝核心代碼與接入流程3.1 換裝數(shù)據(jù)的組織槽位、部件網(wǎng)格與骨骼約定做換裝合并先要把數(shù)據(jù)組織想清楚代碼是后面的事。我一般用一個枚舉定義槽位每個部件 prefab 上掛一個標(biāo)記組件里面記錄它屬于哪個槽位、是否參與合并、是否帶獨(dú)立動畫。部件網(wǎng)格在美術(shù)導(dǎo)出時就要滿足三個約定共享同一套骨骼層級、頂點(diǎn)坐標(biāo)在同一個模型空間、綁定姿勢統(tǒng)一為 T-Pose 且部件 prefab 的本地變換為零。第三個約定最關(guān)鍵但最容易忽略很多換裝部件在 prefab 里被調(diào)整過位置和旋轉(zhuǎn)合并時如果不處理 transform頂點(diǎn)坐標(biāo)和骨骼空間就對不上。如果美術(shù)給的是帶偏移的部件合并前要么在資源導(dǎo)入階段把網(wǎng)格頂點(diǎn)烘焙到 root 空間要么在運(yùn)行時合并時用矩陣把變換消掉。我的建議是前者導(dǎo)入階段用 AssetPostprocessor 或編輯器腳本做網(wǎng)格頂點(diǎn)重烘焙運(yùn)行時一律按零變換處理。部件上還要注意清理冗余骨骼。很多美術(shù)導(dǎo)出時會把輔助掛點(diǎn)、空節(jié)點(diǎn)一并導(dǎo)出成骨骼節(jié)點(diǎn)這些節(jié)點(diǎn)不參與蒙皮但會進(jìn)入 bones 數(shù)組導(dǎo)致合并后骨骼列表里出現(xiàn)一堆 null 或無用引用。下面的合并代碼會把空引用跳過但最省事的還是導(dǎo)出階段就清理掉。3.2 核心合并代碼骨骼映射、bindposes 與 CombineMeshes直接給可運(yùn)行的 C# 代碼。這個類做了四件事收集全局骨骼列表、重映射部件網(wǎng)格的 BoneWeight 索引、重建 bindposes、用 CombineMeshes 合并頂點(diǎn)數(shù)據(jù)并重建 SkinnedMeshRenderer。using System.Collections.Generic; using UnityEngine; public static class SkinnedMeshCombiner { // 入口把 parts 里的所有部件合并進(jìn) root 上的 SkinnedMeshRenderer public static SkinnedMeshRenderer Combine( GameObject root, ListSkinnedMeshRenderer parts, string newMeshName Combined_Mesh) { // 階段一遍歷所有部件把骨骼按出現(xiàn)順序收集成全局骨骼列表 ListTransform finalBones new ListTransform(); DictionaryTransform, int boneIndexMap new DictionaryTransform, int(); foreach (SkinnedMeshRenderer part in parts) { if (part null || part.sharedMesh null) continue; foreach (Transform bone in part.bones) { if (bone null) continue; // 跳過空骨骼避免索引錯位 if (!boneIndexMap.ContainsKey(bone)) { boneIndexMap[bone] finalBones.Count; finalBones.Add(bone); } } } // 階段二準(zhǔn)備 bindposes 容器并標(biāo)記哪個位置已填充 Matrix4x4[] mergedBindposes new Matrix4x4[finalBones.Count]; bool[] bindposeFilled new bool[finalBones.Count]; for (int i 0; i mergedBindposes.Length; i) { mergedBindposes[i] Matrix4x4.identity; } ListCombineInstance combineInstances new ListCombineInstance(); ListMaterial finalMaterials new ListMaterial(); foreach (SkinnedMeshRenderer part in parts) { if (part null || part.sharedMesh null) continue; // 階段三把部件自身的 bindposes 填到全局列表對應(yīng)位置 Matrix4x4[] partBindposes part.sharedMesh.bindposes; Transform[] partBones part.bones; for (int i 0; i partBones.Length; i) { Transform bone partBones[i]; if (bone null || !boneIndexMap.TryGetValue(bone, out int newIdx)) continue; if (!bindposeFilled[newIdx]) { mergedBindposes[newIdx] partBindposes[i]; bindposeFilled[newIdx] true; } } // 階段四復(fù)制網(wǎng)格重映射 BoneWeight 的四個骨骼索引 Mesh partMesh Object.Instantiate(part.sharedMesh); partMesh.name part.sharedMesh.name _prepared; BoneWeight[] weights partMesh.boneWeights; for (int wi 0; wi weights.Length; wi) { BoneWeight w weights[wi]; w.boneIndex0 RemapBoneIndex(w.boneIndex0, partBones, boneIndexMap); w.boneIndex1 RemapBoneIndex(w.boneIndex1, partBones, boneIndexMap); w.boneIndex2 RemapBoneIndex(w.boneIndex2, partBones, boneIndexMap); w.boneIndex3 RemapBoneIndex(w.boneIndex3, partBones, boneIndexMap); weights[wi] w; } partMesh.boneWeights weights; // 階段五部件本地變換必須為單位變換合并時直接用 identity if (part.transform.localPosition ! Vector3.zero || part.transform.localRotation ! Quaternion.identity || part.transform.localScale ! Vector3.one) { Debug.LogWarning(${part.name} 本地變換不是單位變換合并結(jié)果可能異常); } CombineInstance ci new CombineInstance(); ci.mesh partMesh; ci.subMeshIndex 0; // 每個部件只取第一個 submesh ci.transform Matrix4x4.identity; // 前提所有部件在同一模型空間 combineInstances.Add(ci); // 材質(zhì)按部件順序收集后續(xù)再決定是否合并貼圖 Material mat part.sharedMaterials.Length 0 ? part.sharedMaterials[0] : null; finalMaterials.Add(mat); } // 階段六合并頂點(diǎn)與三角形數(shù)據(jù) Mesh finalMesh new Mesh(); finalMesh.name newMeshName; finalMesh.CombineMeshes(combineInstances.ToArray(), true, false); // 階段七關(guān)鍵一步——合并后的網(wǎng)格必須手動覆蓋 bindposes finalMesh.bindposes mergedBindposes; // 階段八重建或復(fù)用 SkinnedMeshRenderer SkinnedMeshRenderer result root.GetComponentSkinnedMeshRenderer(); if (result null) result root.AddComponentSkinnedMeshRenderer(); result.sharedMesh finalMesh; result.rootBone root.transform; result.bones finalBones.ToArray(); result.sharedMaterials finalMaterials.ToArray(); result.updateWhenOffscreen true; return result; } // 把舊骨骼索引映射到全局骨骼列表的新索引 private static int RemapBoneIndex( int oldIndex, Transform[] partBones, DictionaryTransform, int boneIndexMap) { if (oldIndex 0 || oldIndex partBones.Length) return 0; Transform bone partBones[oldIndex]; if (bone null) return 0; if (boneIndexMap.TryGetValue(bone, out int newIndex)) return newIndex; return 0; } }代碼邏輯說明階段一是整個合并的地基它把所有部件用到的骨骼去重收進(jìn)一個全局?jǐn)?shù)組并用 Dictionary 記錄每個 Transform 對應(yīng)的新索引。階段三把每個部件的 bindposes 按照新索引填進(jìn)全局?jǐn)?shù)組同一個骨骼在多個部件里出現(xiàn)時只填第一次的值因?yàn)橥桓趋赖?bindpose 在共享骨架下應(yīng)該是一致的。階段四對每個頂點(diǎn)權(quán)重調(diào)用 RemapBoneIndex把舊索引翻譯成新索引。階段六傳的mergeSubMeshes: true很關(guān)鍵它告訴 CombineMeshes 把所有三角形的 submesh 標(biāo)記統(tǒng)一成 0避免合并后出現(xiàn)一堆無意義的 submesh。useMatrices: false表示不用 CombineInstance.transform 去變換頂點(diǎn)這建立在上文強(qiáng)調(diào)的“所有部件共享同一模型空間”前提上。階段七是運(yùn)行時合并蒙皮網(wǎng)格最容易漏的一步。CombineMeshes 合并出的網(wǎng)格自帶一組默認(rèn) bindposes它是根據(jù)合并矩陣生成的對蒙皮網(wǎng)格來說是錯的。必須手動賦值我們在階段三里拼好的 mergedBindposes動畫系統(tǒng)才會按正確的骨骼逆矩陣計(jì)算頂點(diǎn)位置。參數(shù)說明里要留意幾個點(diǎn)RemapBoneIndex 對查不到的骨骼一律返回 0也就是默認(rèn)由全局骨骼列表第一根骨頭兜底這能防止越界但會產(chǎn)生錯誤權(quán)重所以部件里出現(xiàn)未知骨骼時最好在開發(fā)期直接報錯而不是靜默兜底合并后 bones 數(shù)組長度等于 finalBones.CountsharedMaterials 數(shù)量等于部件數(shù)量如果你的換裝還有武器這類需要獨(dú)立蒙皮的部件不要把它加進(jìn) parts 列表。3.3 把合并接進(jìn)換裝流程換掉槽位后重新合并合并代碼本身只解決“怎么合”換裝流程還需要一個調(diào)用方。我的習(xí)慣是寫一個 OutfitChanger 組件掛在角色根節(jié)點(diǎn)上保存當(dāng)前所有部件的引用換裝時先找到對應(yīng)槽位替換再重新調(diào)用 Combine。public class OutfitChanger : MonoBehaviour { public ListSkinnedMeshRenderer currentParts new ListSkinnedMeshRenderer(); // 換掉指定槽位的部件后重新合并 public void ChangePart(string slotName, SkinnedMeshRenderer newPart) { for (int i 0; i currentParts.Count; i) { if (currentParts[i].name.Contains(slotName)) { currentParts[i] newPart; break; } } SkinnedMeshCombiner.Combine(gameObject, currentParts, Player_Combined); } }這里有個容易忽略的問題每次重新合并都會 Instantiate 一份部件網(wǎng)格舊網(wǎng)格不會自動釋放。連續(xù)換裝幾次Mesh 對象就泄漏了。我一般把 Combine 返回的 sharedMesh 記錄在角色上下次合并前手動 Object.Destroy 掉。不要在換裝瞬間做合并尤其是移動端CombineMeshes 不是免費(fèi)的后面避坑章會細(xì)說。4. 換裝合并避坑5 個翻車現(xiàn)場與排查方法4.1 動畫一播手指就扭成麻花BoneWeight 索引沒有重映射現(xiàn)象合并后的模型靜止時完全正常一播動畫手指、腳趾、裙擺這些權(quán)重密集的區(qū)域扭曲成麻花身體其他部位看起來又沒事。原因靜止時頂點(diǎn)位置本身就是建模時的坐標(biāo)不需要骨骼計(jì)算也正確。動畫驅(qū)動后蒙皮階段要按 BoneWeight 里記錄的骨骼索引去 bones 數(shù)組取變換矩陣索引指向錯誤的骨骼權(quán)重就作用在錯誤關(guān)節(jié)上。手指這類關(guān)節(jié)多、權(quán)重分配細(xì)的區(qū)域最先暴露問題。解決逐頂點(diǎn)重映射 BoneWeight 索引這是合并代碼里不能跳過的階段四。注意只改 Mesh.boneWeights 還不夠如果用了 GPU 蒙皮或者頂點(diǎn)數(shù)超過 65535 走了 BoneWeight4 通道BlendWeight 和 BlendIndices 也要一并重映射否則高端機(jī)型上用的還是老的索引數(shù)據(jù)。4.2 Draw Call 沒降反升每個部件成了獨(dú)立 submesh現(xiàn)象按教程合完后Frame Debugger 里 Batch 數(shù)壓根沒降甚至比原來還多了一兩個。原因CombineMeshes 的 mergeSubMeshes 傳了 false或者部件的 sharedMaterials 長度超過 1。合并時每個 submesh 對應(yīng)一個材質(zhì)槽材質(zhì)決定渲染順序和狀態(tài)切換。六個部件即使頂點(diǎn)合在一起只要 submesh 沒合并SkinnedMeshRenderer 還是會按六個 submesh 渲染六次。解決合并時 mergeSubMeshes 傳 true且合并前把部件材質(zhì)統(tǒng)一成一個。如果你確實(shí)需要多材質(zhì)比如臉和身體用不同 shader那就要接受多個 submesh 的現(xiàn)狀但要讓相同材質(zhì)的 submesh 盡量連續(xù)排列減少渲染狀態(tài)切換。把六個 Draw Call 優(yōu)化到兩個而不是一個也算達(dá)成目的。4.3 換裝瞬間卡頓掉幀CombineMeshes 在主線線程上干活現(xiàn)象換裝按鈕點(diǎn)下去角色卡了一兩百毫秒連續(xù)換裝還會越來越卡。原因CombineMeshes 是同步的 CPU 密集操作頂點(diǎn)越多越慢。換裝瞬間要做 Instantiate 網(wǎng)格、重映射權(quán)重、合并頂點(diǎn)、重新上傳 GPU 數(shù)據(jù)全部堆在渲染線程前。連續(xù)換裝卡頓加劇通常是 Mesh 泄漏舊的臨時網(wǎng)格沒有被釋放內(nèi)存和顯存持續(xù)上漲GC 頻繁觸發(fā)。解決換裝合并不要在點(diǎn)擊瞬間做。常見做法是換裝界面打開時預(yù)合一組常用搭配真正換裝時把合并拆到兩到三幀里或者接受一次性卡頓但嚴(yán)格控制臨時 Mesh 的釋放。我做項(xiàng)目時會在 OutfitChanger 里維護(hù)一個 oldMesh 引用下一次合并前主動 Destroy并用 ObjectPool 緩存 CombineInstance 數(shù)組減少 GC 壓力。4.4 空骨骼引用不報錯美術(shù)導(dǎo)出留下的隱形炸彈現(xiàn)象合并時沒有任何報錯編輯器里看 bones 數(shù)組有一兩個 null角色動畫部分失效或整體偏移有些部位飄在空中。原因SkinnedMeshRenderer.bones 數(shù)組允許存在 null 引用運(yùn)行時不會崩但蒙皮計(jì)算時把空骨骼當(dāng)單位矩陣處理權(quán)重對應(yīng)的頂點(diǎn)就停在原地或被錯誤拉扯。美術(shù)建模軟件里刪除骨骼操作不干凈留下了冗余骨骼節(jié)點(diǎn)導(dǎo)出時帶了出來。解決合并代碼里對 null 骨骼做跳過處理只能治標(biāo)真正要做的是在資源導(dǎo)入階段校驗(yàn)。用一個編輯器腳本遍歷所有換裝部件檢查 bones 數(shù)組是否有 null、是否有不在骨骼層級里的孤立節(jié)點(diǎn)發(fā)現(xiàn)問題直接攔截。開發(fā)期讓美術(shù)修比運(yùn)行時兜底靠譜得多。4.5 陰影和描邊全亂材質(zhì)模板不統(tǒng)一讓合并白做現(xiàn)象合并后主體渲染正常但陰影、描邊、輪廓光這些后處理效果全亂了有的部件有描邊有的沒有陰影顏色深淺不一。原因換裝合并把頂點(diǎn)數(shù)據(jù)統(tǒng)一了材質(zhì)沒有統(tǒng)一。部件各自帶材質(zhì)半透明材質(zhì)和不透明材質(zhì)混在同一個 SkinnedMeshRenderer 里渲染管線按 submesh 逐個處理透明度排序和描邊 Pass 就亂了。解決合并前定義一套統(tǒng)一的材質(zhì)模板所有部件只換貼圖不換 shader。半透明部件比如薄紗、紗裙單獨(dú)挑出來不參與主 Mesh 合并作為獨(dú)立 SkinnedMeshRenderer 額外渲染。雙面材質(zhì)和 shader 里的描邊 Pass 也要在合并前確認(rèn)一致?lián)Q裝合并優(yōu)化的前提是渲染狀態(tài)統(tǒng)一材質(zhì)分叉越多合并收益越低。5. 材質(zhì)與貼圖合并讓換裝合并真正降下 Draw Call5.1 先合材質(zhì)還是先合貼圖順序決定了合并上限Mesh 合并把頂點(diǎn)整合了材質(zhì)如果不合Draw Call 只能降到部件數(shù)量這個級別。一個六個部件的角色合并后還有六個材質(zhì)球Batch 還是六個。要把 Batch 壓到一兩個必須把材質(zhì)和貼圖同步合并。材質(zhì)合并的做法是所有部件使用同一個 shader 模板合并時按紋理用途創(chuàng)建一張大的 Texture Atlas把部件各自的 albedo、normal、mask 貼圖打包進(jìn)去再生成一個 Material 實(shí)例。運(yùn)行時合并的目標(biāo)是讓 sharedMaterials 的長度變成 1 或 2否則 Mesh 合并就做了一半。先合并材質(zhì)還是先合貼圖沒有絕對順序我的習(xí)慣是先把部件材質(zhì)統(tǒng)一到同一個 shader 變體再處理貼圖。如果 shader 不一致比如一個用 URP Lit一個用 Built-in StandardTexture Atlas 做得再整齊也沒用渲染狀態(tài)還是切來切去。Shader 模板統(tǒng)一后貼圖合并才有意義。5.2 Texture Atlas 的關(guān)鍵參數(shù)尺寸、留白與打包順序Texture Atlas 直接在運(yùn)行時用 Texture2D.PackTextures 打包最省事。PackTextures 有三個參數(shù)會影響合并質(zhì)量。一是圖集尺寸。常見設(shè)置是 2048 或 4096 的二次冪尺寸。2048 適合中低端機(jī)型每張圖集的像素預(yù)算大約算一下六個部件各一張 1024 貼圖打包成 2048 圖集就能放下前提是部件共享比例相近。部件里有超高精度貼圖比如臉和頭發(fā)用 2048 單張貼圖時強(qiáng)行打包進(jìn) 2048 圖集要么糊掉要么浪費(fèi)大量空白直接上 4096 但要注意移動端顯存帶寬。二是留白 padding。PackTextures 的 padding 參數(shù)控制相鄰貼圖之間的距離。建議設(shè) 4 像素或 8 像素防止 mipmap 采樣時貼圖邊緣顏色互相滲透。數(shù)值太小遠(yuǎn)處看角色會有輕微色斑太大浪費(fèi)圖集空間。三是打包順序。PackTextures 會自動排布矩形但順序不穩(wěn)定同一張貼圖集每次打包結(jié)果可能不一樣。這會影響序列幀動畫里 UV 穩(wěn)定性和網(wǎng)絡(luò)同步尤其是你那套換裝系統(tǒng)還做了翻頁預(yù)覽。我一般自己寫一個排序規(guī)則按貼圖高度降序排列后傳入保證穩(wěn)定的打包布局。參數(shù)推薦值說明atlasSize2048 / 4096二次冪按部件貼圖數(shù)量和精度決定padding4 或 8 像素防 mipmap 邊緣顏色滲透貼圖格式ASTC 6x6 或 8x8移動端推薦兼顧畫質(zhì)與帶寬mipmap開啟換裝角色距離變化大關(guān)閉會出現(xiàn)閃爍噪點(diǎn)打包順序高度降序保證多次打包結(jié)果一致PackTextures 生成圖集后還要把每張貼圖對應(yīng)的 UV 換算進(jìn)圖集坐標(biāo)這個換算過程要在合并 Mesh 前重寫 uv2 或直接改寫 uv 數(shù)據(jù)。我做過最常翻車的地方就在這一步UV 坐標(biāo)系是左下角還是左上角寫錯一次整張貼圖在模型上就是上下顛倒的。5.3 Shader 模板統(tǒng)一半透明、雙面與陰影的合并邊界合并換裝追求的是渲染狀態(tài)統(tǒng)一但不是所有部件都適合合進(jìn)同一個材質(zhì)球。半透明材質(zhì)和全透明材質(zhì)是兩條路不能混在一個 Atlas 里。角色的薄紗裙、蕾絲邊這類部件單獨(dú)用一個透明材質(zhì)球和貼圖不參與主 Mesh 合并否則合完后透明部分和不透明部分的深度排序一塌糊涂。雙面材質(zhì)的處理也要想清楚。很多時裝部件是雙面渲染的裙擺內(nèi)側(cè)、飄帶如果把它們合并進(jìn)不透明單面材質(zhì)內(nèi)側(cè)會直接看不見。常見做法是雙面材質(zhì)部件單獨(dú)出一個小 Mesh用帶 Cull Off 的 shader 渲染不參與主合并。你如果用了 Unity 的雙面材質(zhì) shader注意它的 renderQueue 通常要比不透明材質(zhì)高合并時混在一起排序很麻煩。陰影也有類似的邊界問題。換裝合并后角色的 shadow caster 只有一個 Mesh如果部件里有帶特殊陰影需求的比如武器要投影但不受影要么在 shader 里做陰影變體控制要么把特殊部件拆出主合并。合并換裝不是把所有東西都塞進(jìn)一個 SkinnedMeshRenderer 才叫完成而是把渲染批次壓縮到業(yè)務(wù)允許的最小值。6. 合并結(jié)果怎么驗(yàn)Profiler 抓批次數(shù)與權(quán)重抽檢6.1 用 Frame Debugger 確認(rèn)批次數(shù)真的降了合并做完第一件事不是看模型正不正常而是打開 Window Analysis Frame Debugger找到角色渲染那一幀數(shù)一下角色占用了多少個 Batch。看兩個指標(biāo)角色渲染占用的 DrawCall 數(shù)量、SetPassCall 數(shù)量。如果合并前六七個 Batch合并后還是一個甚至兩個渲染側(cè)就算成功了。如果 Batch 數(shù)沒降優(yōu)先檢查 sharedMaterials 數(shù)組長度。長度是 1 但 Batch 還是多個看 shader 的 pass 數(shù)量和 renderQueue某個 pass 用了不同的隊(duì)列比如透明度隊(duì)列渲染狀態(tài)就會分裂。6.2 骨骼權(quán)重抽檢腳本在運(yùn)行時檢查異常頂點(diǎn)動畫扭成麻花的問題不一定會立刻暴露需要一個簡單的抽檢腳本。選幾個已知位置的骨骼比如左手小指末端輸出它影響的頂點(diǎn)數(shù)量和權(quán)重分布跟合并前對比。// 掛到角色上用來抽檢某個骨骼對合并后網(wǎng)格的影響 public class WeightCheck : MonoBehaviour { public Transform targetBone; [ContextMenu(Check Weight)] void CheckWeight() { SkinnedMeshRenderer smr GetComponentSkinnedMeshRenderer(); int boneIndex System.Array.IndexOf(smr.bones, targetBone); if (boneIndex 0) { Debug.LogError(目標(biāo)骨骼不在 bones 數(shù)組中); return; } int affected 0; float totalWeight 0f; BoneWeight[] weights smr.sharedMesh.boneWeights; for (int wi 0; wi weights.Length; wi) { BoneWeight w weights[wi]; if (w.boneIndex0 boneIndex || w.boneIndex1 boneIndex || w.boneIndex2 boneIndex || w.boneIndex3 boneIndex) { affected; totalWeight w.weight0 w.weight1 w.weight2 w.weight3; } } Debug.Log($骨骼 {targetBone.name} 影響 {affected} 個頂點(diǎn)總權(quán)重 {totalWeight:F2}); } }這段代碼的目的是驗(yàn)證索引重映射是否生效抽檢骨骼在合并后的 bones 數(shù)組里能找到且權(quán)重索引正確。如果 affected 是 0說明骨骼沒參與蒙皮如果總權(quán)重遠(yuǎn)大于頂點(diǎn)數(shù)正常情況每個頂點(diǎn)權(quán)重合計(jì)約 1說明權(quán)重重復(fù)累計(jì)合并邏輯有 bug。合并換裝做多了我養(yǎng)成的習(xí)慣是先立骨骼約定再動合并代碼。美術(shù)那邊骨骼命名不統(tǒng)一運(yùn)行時代碼寫得再嚴(yán)謹(jǐn)也會在某次更新后突然崩壞。還有每次發(fā)布前跑一遍批量換裝壓測用同一個角色連續(xù)換裝五十次看內(nèi)存曲線有沒有持續(xù)上漲這一條能攔住絕大多數(shù) Mesh 泄漏問題。合并換裝這套方案本身不復(fù)雜復(fù)雜的是數(shù)據(jù)規(guī)范和邊界條件這兩樣抓牢了后面出問題的概率會小很多。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取