簡介這是一組面向Unity開發(fā)者的輕量級格式轉(zhuǎn)換腳本用于在編輯器環(huán)境中處理.unity3d資源文件。Unity3D格式可將場景、模型、紋理、動畫等資源打包為單一文件而這套腳本正是為整合、優(yōu)化或格式轉(zhuǎn)換提供自動化途徑幫助開發(fā)者降低模型復(fù)雜度、壓縮紋理、合并資源從而改善游戲加載速度與內(nèi)存占用。壓縮包內(nèi)僅含3個文件包括兩個JavaScript腳本和一個C#腳本整體體積僅5KB導(dǎo)入Assets/Editor目錄后即可在編輯器菜單中調(diào)用不會打進發(fā)布包。已有333人學(xué)習(xí)下載。腳本基于Unity的AssetDatabase與序列化機制運行覆蓋資源讀取、處理、導(dǎo)出全流程能夠減少手動重復(fù)操作Editor目錄隔離設(shè)計也更適合需要自定義資源管線的初中級開發(fā)者快速上手或二次修改。 做Unity項目做到一定程度幾乎都會碰到模型格式對不上號的情況。上周美術(shù)丟給我一個模型包里面全是.ma和.3ds還特別備注了一句“引擎要什么格式自己轉(zhuǎn)一下”。以前遇到這種事要么開Blender手動轉(zhuǎn)要么去找第三方轉(zhuǎn)換工具來回折騰效率特別低。這次我直接在Unity工程里寫了一個3D格式轉(zhuǎn)換腳本把常用的網(wǎng)格轉(zhuǎn)換邏輯封裝成菜單命令一鍵導(dǎo)出OBJ連命令行批量導(dǎo)出都做完了全程都沒離開Unity編輯器。實測下來簡單有效省了大量重復(fù)勞動。這篇博文就把這個腳本的完整實現(xiàn)、原理和踩坑記錄整理出來給還在跟格式問題較勁的朋友一個參考。1. 為什么我決定在Unity內(nèi)部寫腳本做格式轉(zhuǎn)換1.1 從一次讓人頭大的模型交付說起上周美術(shù)丟給我一個模型包里面全是.ma和.3ds還特別備注了一句“引擎要什么格式自己轉(zhuǎn)一下”。這種“格式不太對”的破事我已經(jīng)不是第一次遇到以前的做法要么開Blender手動轉(zhuǎn)要么在網(wǎng)上下一個格式轉(zhuǎn)換工具來回折騰效率特別低。后來有一回美術(shù)給的模型在第三方工具里轉(zhuǎn)出來跑進Unity之后法線全反了材質(zhì)也丟了大半我想查一下原始導(dǎo)入的數(shù)據(jù)到底長什么樣才發(fā)現(xiàn)轉(zhuǎn)換工具根本沒把Unity可用的資源形態(tài)暴露給我。那之后我就下決心直接在Unity工程里寫一個3D格式轉(zhuǎn)換腳本。思路很簡單既然Unity已經(jīng)幫我把外部模型資源解析成了Mesh、材質(zhì)、貼圖那我在編輯器里讀取這些數(shù)據(jù)再用代碼重新序列化成目標(biāo)格式輸出就行。整個轉(zhuǎn)換過程不依賴任何外部軟件也不會因為工具版本不一致出現(xiàn)結(jié)果偏差。實測下來這套方案簡單有效雖然不能替代DCC軟件做精細(xì)調(diào)參但解決日常的格式交換、資源交付、批量處理完全夠用。1.2 對比三種常見轉(zhuǎn)換方案動手之前我把市面上常見的方案快速過了一遍各有各的問題。第一種是找“萬能轉(zhuǎn)換器”。網(wǎng)上的轉(zhuǎn)換工具品類很多但實際用下來問題不少要么支持格式有限遇到.ma、.3ds、.dae這些“冷門貨”直接不認(rèn)要么碰到幾十萬頂點的超大Mesh就卡死還有一批在線轉(zhuǎn)換網(wǎng)站模型傳上去之后貼圖丟失是常態(tài)更不用說安全性。如果只是偶爾轉(zhuǎn)一個模型無所謂一旦批量轉(zhuǎn)換一個個點開工具選文件選參數(shù)重復(fù)勞動能占掉一上午。第二種是DCC軟件中轉(zhuǎn)。打開Blender或者3ds Max導(dǎo)入再導(dǎo)出這個方法很萬能格式兼容性最好。但麻煩在于DCC軟件里的顯示效果和Unity最終渲染效果往往有差異轉(zhuǎn)出來到了Unity里可能比例不對、法線方向變了、貼圖路徑斷裂還得再調(diào)一輪。另外項目成員不一定都裝了Blender你臨時要轉(zhuǎn)一個模型還得先花時間裝環(huán)境。第三種就是本文要講的Unity腳本方案。它直接把Unity已經(jīng)導(dǎo)入解析好的資源再導(dǎo)出不依賴外部軟件結(jié)果所見即所得。尤其是在“模型最終要放到Unity里跑”這個場景下這個方案沒有任何多余環(huán)節(jié)。1.3 在Unity里做轉(zhuǎn)換的真正優(yōu)勢所見即所得這一點最值錢。腳本跑的是Unity渲染時真正用的那一份Mesh數(shù)據(jù)不像DCC轉(zhuǎn)完還可能二次走樣。導(dǎo)出后的模型拿到Blender或者其他工具里打開大小比例、頂點順序、材質(zhì)分布基本和Unity里看到的一致省掉了反復(fù)比對的時間。第二個優(yōu)勢是能復(fù)用Unity的整個資源管線。Unity導(dǎo)入FBX時已經(jīng)把網(wǎng)格、UV、法線、切線全解析好了腳本只需要從MeshFilter、SkinnedMeshRenderer上取數(shù)據(jù)。更進一步我還可以在AssetPostprocessor里寫一個導(dǎo)入后自動轉(zhuǎn)換的邏輯模型一拖進工程就自動輸出OBJ。這種“導(dǎo)入即轉(zhuǎn)換”的工作流外部工具鏈很難做到。第三個優(yōu)勢是沒有額外依賴。腳本其實就是幾個.cs文件扔到Editor文件夾下就能跑一臺裝了Unity的機器全流程搞定。我們項目里還有一批給微信小游戲做資源瘦身的場景需要大量對比高低模差異用這套腳本批量轉(zhuǎn)OBJ再在Blender里快速看網(wǎng)格結(jié)構(gòu)效率比人肉操作高了一個量級。2. OBJ格式的底細(xì)先搞清楚“文本結(jié)構(gòu)”再動手2.1 OBJ文件到底長什么樣寫腳本前我先把OBJ文件的“底細(xì)”摸清了。OBJ是Wavefront定義的3D模型文本格式每一個頂點、每根法線、每個三角形都寫成一行文本用行首的關(guān)鍵字區(qū)分類型。一個最簡單的Cube打開OBJ文件內(nèi)容大概是這樣o Cube v 1.000000 1.000000 -1.000000 v 1.000000 -1.000000 -1.000000 v -1.000000 1.000000 -1.000000 v -1.000000 -1.000000 -1.000000 v 1.000000 0.999999 1.000000 v 1.000000 -1.000000 1.000000 vt 0.000000 0.000000 vt 0.000000 1.000000 vt 1.000000 0.000000 vt 1.000000 1.000000 vn 0.000000 1.000000 0.000000 ... f 1/1/1 3/2/2 5/3/3這些前綴的含義非常好理解o是object對象名v是頂點坐標(biāo)vt是UV坐標(biāo)vn是法線f是面索引。f后面每三個數(shù)一組分別代表三角形三個頂點的“頂點索引/UV索引/法線索引”注意索引從1開始。如果使用了材質(zhì)文件里還會有mtllib xxx.mtl引用外部材質(zhì)庫。我第一次寫導(dǎo)出腳本就是照著這幾個字段逐行吐數(shù)據(jù)跑通最基礎(chǔ)的Mesh導(dǎo)出只用了十幾分鐘。OBJ能成為各種工具之間通用的“中間格式”靠的就是這種極度簡單的文本結(jié)構(gòu)。2.2 從Unity Mesh到OBJ中間要做的三件事光會寫這些字段還不夠從Unity的Mesh對象到OBJ文本坑藏在三個地方。第一坐標(biāo)系轉(zhuǎn)換。Unity是左手坐標(biāo)系X向右、Y向上、Z向屏幕內(nèi)而OBJ規(guī)范采用右手坐標(biāo)系X向右、Y向上、Z向屏幕外。如果直接把Unity的頂點坐標(biāo)原樣寫進OBJ導(dǎo)出的模型會沿某個軸鏡像法線和三角面朝向也救不回來。我的做法是導(dǎo)出時把X取反同時對三角形索引做一次反序保證面朝外。第二索引基數(shù)。Unity的Mesh.triangles是零基索引而OBJ文件中f后面的索引最小是1。每寫一個三角形都要對每個索引做1處理。這個處理看似不起眼漏掉的話整個模型在軟件里會錯亂成一片。第三子網(wǎng)格的處理。一個GameObject上可能掛了多材質(zhì)對應(yīng)Mesh里的多個submesh。OBJ里遇到不同的submesh要切換usemtl指令否則所有面都會統(tǒng)一用最后一種材質(zhì)最終結(jié)果就是材質(zhì)錯亂。2.3 為什么選OBJ而不是直接轉(zhuǎn)FBX我承認(rèn)FBX是現(xiàn)在DCC和引擎之間更通用的橋梁格式Unity官方后面也推出了FBX Exporter包。但在我這個“簡單有效”的目標(biāo)下OBJ有不可替代的好處。純文本異常好調(diào)試。導(dǎo)出的文件用文本編輯器打開就能查問題FBX是二進制出錯了你根本不知道是哪兒錯了。幾乎所有軟件都認(rèn)OBJ包括各種在線預(yù)覽工具、3D打印切片軟件甚至一些做AI三維重建的接口。腳本復(fù)雜度低。寫一個OBJ導(dǎo)出器只需要處理字符串拼接不需要引用任何SDK。OBJ的缺點也很明確不支持蒙皮動畫、不支持多動畫剪輯、格式壓縮率低。所以我在工具里給了兩條路日常幾何交換、給合作方或打印廠用OBJ要保留完整動畫和材質(zhì)就走官方FBX Exporter。后面第5節(jié)會講到這個選擇。3. 核心腳本實現(xiàn)把Mesh數(shù)據(jù)序列化成OBJ文本3.1 編輯器菜單入口和目錄設(shè)計先看工程結(jié)構(gòu)。我的腳本放在Assets/Editor/ModelTools/ObjExporter.csEditor目錄是Unity約定好的這個目錄下的腳本只會參與編輯器功能不會編譯進游戲包。菜單入口用MenuItem特性注冊public static class ObjExporter { [MenuItem(Tools/Model Convert/Export Selected To OBJ)] public static void ExportSelected() { GameObject[] selected Selection.gameObjects; if (selected.Length 0) { Debug.LogWarning(請先在場景中選中要導(dǎo)出的物體); return; } string path EditorUtility.SaveFilePanel(Export OBJ, , export.obj, obj); if (string.IsNullOrEmpty(path)) return; ExportGameObjectsToObj(selected, path); } }菜單名叫Tools/Model Convert/...放進Unity菜單欄的Tools分類順眼也好找。ExportSelected處理用戶從場景選中物體的場景后面第4節(jié)我會把它擴展成支持命令行調(diào)用的靜態(tài)方法。3.2 核心的MeshToString方法這段是把一個Mesh實例序列化成OBJ文本的核心邏輯改進自社區(qū)流傳的經(jīng)典版本我在這基礎(chǔ)上加了坐標(biāo)轉(zhuǎn)換、法線反置和多submesh支持。public static string MeshToString(Mesh mesh, string objectName, string mtlName) { StringBuilder sb new StringBuilder(); sb.Append(o ).Append(objectName).Append(\n); sb.Append(mtllib ).Append(mtlName).Append(.mtl\n); Vector3[] vertices mesh.vertices; Vector3[] normals mesh.normals; Vector2[] uvs mesh.uv; for (int i 0; i vertices.Length; i) { Vector3 v vertices[i]; sb.Append(v ).AppendFormat({0} {1} {2}\n, -v.x, v.y, v.z); } for (int i 0; i normals.Length; i) { Vector3 n normals[i]; sb.Append(vn ).AppendFormat({0} {1} {2}\n, -n.x, n.y, n.z); } for (int i 0; i uvs.Length; i) { Vector2 uv uvs[i]; sb.Append(vt ).AppendFormat({0} {1}\n, uv.x, uv.y); } for (int submesh 0; submesh mesh.subMeshCount; submesh) { int[] triangles mesh.GetTriangles(submesh); sb.Append(usemtl material_).Append(submesh).Append(\n); for (int i 0; i triangles.Length; i 3) { int a triangles[i] 1; int b triangles[i 1] 1; int c triangles[i 2] 1; // 將左手系的三角形順序反轉(zhuǎn) sb.Append(f ).Append(a).Append(/).Append(a).Append(/).Append(a); sb.Append( ).Append(c).Append(/).Append(c).Append(/).Append(c); sb.Append( ).Append(b).Append(/).Append(b).Append(/).Append(b); sb.Append(\n); } } return sb.ToString(); }這里有幾個關(guān)鍵點需要解釋。第一頂點和法線的X取反是最核心的坐標(biāo)轉(zhuǎn)換Z軸方向其實可以不改只要X取反加三角形順序反轉(zhuǎn)模型從Unity的左手系變成OBJ的右手系視覺上就一致了。第二法線必須同步取反否則模型雖然頂點坐標(biāo)對了但光照法線用的是原來的方向在別的軟件里會看起來明暗不對。第三三角形索引我故意調(diào)成a, c, b的順序。Unity三角形頂點順序是順時針而OBJ軟件大多按逆時針識別正面反序之后面朝向才正確。第四每個submesh用material_0、material_1這樣的命名切換材質(zhì)和后面生成的MTL一一對應(yīng)。3.3 帶材質(zhì)和貼圖的MTL文件生成OBJ本身不存材質(zhì)材質(zhì)信息全部放在旁邊同名MTL文件里。上面代碼里我寫了mtllib objName.mtl所以還得生成一個配套的MTL文件。項目里掛的是Standard材質(zhì)或URP的Lit材質(zhì)時我主要取三樣?xùn)|西_MainTex貼圖、_Color顏色、_Metallic金屬度。public static void WriteMtlFile(string materialFolder, ListMaterial materials) { StringBuilder sb new StringBuilder(); for (int i 0; i materials.Count; i) { Material mat materials[i]; sb.Append(newmtl material_).Append(i).Append(\n); sb.Append(Kd 1.000000 1.000000 1.000000\n); if (mat.HasProperty(_Color)) { Color c mat.color; sb.Append(Kd ).AppendFormat({0} {1} {2}\n, c.r, c.g, c.b); } Texture tex mat.HasProperty(_MainTex) ? mat.mainTexture : null; if (tex ! null) { string srcPath AssetDatabase.GetAssetPath(tex); string dstPath Path.Combine(materialFolder, Path.GetFileName(srcPath)); File.Copy(srcPath, dstPath, true); sb.Append(map_Kd ).Append(Path.GetFileName(srcPath)).Append(\n); } } File.WriteAllText(Path.Combine(materialFolder, export.mtl), sb.ToString()); }這里有一個細(xì)節(jié)值得注意寫貼圖路徑時我刻意用的是相對路徑只寫文件名而不是E:\textures\xxx.png這種絕對路徑。因為OBJMTL這套文件經(jīng)常要給同事、給外包、給3D打印平臺絕對路徑到了別人機器上全斷相對路徑只要貼圖跟OBJ在同一目錄下就萬事大吉。map_Kd對應(yīng)的就是.mtl文件所在目錄下的相對路徑所有軟件都能識別。3.4 遍歷場景導(dǎo)出有了上面兩個方法剩下的就是遍歷場景里所有帶MeshFilter或SkinnedMeshRenderer的對象public static void ExportGameObjectsToObj(GameObject[] roots, string outputPath) { string dir Path.GetDirectoryName(outputPath); ListMaterial materials new ListMaterial(); StringBuilder sb new StringBuilder(); foreach (GameObject root in roots) { MeshFilter[] filters root.GetComponentsInChildrenMeshFilter(true); foreach (MeshFilter f in filters) { Mesh mesh f.sharedMesh; if (mesh null) continue; Renderer renderer f.GetComponentRenderer(); if (renderer ! null) { foreach (Material mat in renderer.sharedMaterials) { if (mat ! null !materials.Contains(mat)) materials.Add(mat); } } sb.Append(MeshToString(mesh, f.gameObject.name, export)); } } File.WriteAllText(outputPath, sb.ToString()); WriteMtlFile(dir, materials); Debug.Log(Export complete: outputPath); }這里用的是GetComponentsInChildren(true)第二個參數(shù)傳true是為了連未激活的物體也一起導(dǎo)出很多美術(shù)資源會臨時隱藏一些分組你不傳true就得來回?fù)v鼓激活狀態(tài)。另外我優(yōu)先取sharedMesh而不是mesh因為mesh會觸發(fā)Mesh實例化在批量處理幾十個同源模型時每實例化一次都是內(nèi)存和耗時用sharedMesh拿共享數(shù)據(jù)就夠了而且不會改動原模型。運行方式很簡單在場景里選好根物體點菜單Tools/Model Convert/Export Selected To OBJ再選一個保存路徑腳本自動把整棵子物體樹的Mesh全部打到一個OBJ文件里MTL和貼圖也自動放好。4. 從點擊菜單到無人值守批量導(dǎo)出命令行調(diào)用技巧4.1 把導(dǎo)出邏輯包成可被命令行調(diào)用的靜態(tài)方法菜單按鈕點著方便但項目里動輒幾十上百個模型一個個選中導(dǎo)出還是太慢。我后來加了一個批量模式直接把第3節(jié)的導(dǎo)出方法再包一層做成無界面依賴的靜態(tài)方法。public static void ExportAllFromCommandLine() { string inputDir GetArg(-inputDir, Assets/Models); string outputDir GetArg(-outputDir, ExportedOBJ); string filter GetArg(-filter, ); if (!Directory.Exists(inputDir)) { Debug.LogError([ObjExporter] input dir not found: inputDir); return; } Directory.CreateDirectory(outputDir); string[] assets Directory.GetFiles(inputDir, *.fbx, SearchOption.AllDirectories); foreach (string assetPath in assets) { if (!string.IsNullOrEmpty(filter) !assetPath.Contains(filter)) continue; string relativePath assetPath.Replace(\\, /); GameObject model AssetDatabase.LoadAssetAtPathGameObject(relativePath); if (model null) continue; string outFile Path.Combine(outputDir, Path.GetFileNameWithoutExtension(assetPath) .obj); ExportGameObjectsToObj(new[] { model }, outFile); } Debug.Log([ObjExporter] batch export finished. files: assets.Length); } private static string GetArg(string argName, string defaultValue) { string[] args System.Environment.GetCommandLineArgs(); for (int i 0; i args.Length; i) { if (args[i] argName i 1 args.Length) return args[i 1]; } return defaultValue; }這個方法用AssetDatabase.LoadAssetAtPath加載FBX資源再把FBX的根GameObject當(dāng)成普通根節(jié)點扔給之前的導(dǎo)出函數(shù)這樣FBX里如果有多個子Mesh也會自動全部展開導(dǎo)出。注意這里不能用Resources.Load或者Instantiate因為命令行模式下沒有激活的場景上下文Instantiate出來的GameObject拿不到序列化數(shù)據(jù)。AssetDatabase.LoadAssetAtPath是編輯器API在Editor里加載靜態(tài)資源最可靠。4.2 Windows和macOS下的命令行調(diào)用Unity Editor本身就支持批處理模式可以在不打開圖形界面的情況下執(zhí)行指定靜態(tài)方法。Windows下我寫了一個export.batecho off set UNITY_EXEC:\Program Files\Unity\Hub\Editor\2021.3.30f1\Editor\Unity.exe set PROJECT_PATHD:\MyProject %UNITY_EXE% -batchmode -projectPath %PROJECT_PATH% ^ -executeMethod ObjExporter.ExportAllFromCommandLine ^ -inputDir Assets/Models -outputDir D:/ExportOBJ ^ -quit -logFile D:/export_log.txtmacOS/Linux下對應(yīng)寫個export.shUNITY_EXE/Applications/Unity/Hub/Editor/2021.3.30f1/Unity.app/Contents/MacOS/Unity $UNITY_EXE -batchmode -projectPath /Users/me/MyProject \ -executeMethod ObjExporter.ExportAllFromCommandLine \ -inputDir Assets/Models -outputDir /Users/me/ExportOBJ \ -quit -logFile /Users/me/export_log.txt跑了之后Unity會啟動、進入工程、執(zhí)行靜態(tài)方法、導(dǎo)出、退出全程無界面。如果你只想導(dǎo)出一部分通過參數(shù)-filter hero就能只處理帶hero關(guān)鍵字的文件。加上-quit參數(shù)Unity會在方法執(zhí)行完自動關(guān)閉不會掛在后臺。4.3 實測效率和幾個限制我拿一個真實項目的資源做了下測試120個帶MeshFilter和標(biāo)準(zhǔn)材質(zhì)的FBX模型平均幾千頂點命令行批量導(dǎo)出到OBJ大概用時40多秒單個模型不到0.5秒比人肉在軟件里一個個轉(zhuǎn)快了不知道多少倍。如果你只要幾十個小模型10秒內(nèi)就能全部完成。但命令行模式有幾個限制我踩出來過不要彈任何對話框。EditorUtility.SaveFilePanel、DisplayDialog這些在batchmode下會卡住進程腳本要改成直接用參數(shù)傳路徑。不要碰有幀依賴的編輯器API比如EditorApplication.delayCall批處理模式下很可能還沒執(zhí)行完就退出了。日志要留。-quit之后Unity關(guān)得很快如果不加-logFile參數(shù)出問題你根本看不到Debug.LogError打出來的內(nèi)容。我習(xí)慣每次導(dǎo)出都生成獨立的log文件排查效率高很多。5. 踩坑記錄坐標(biāo)鏡像、蒙皮烘焙、材質(zhì)路徑等5.1 導(dǎo)出去鏡像問題一次只做一半坐標(biāo)轉(zhuǎn)換的代價我第一次把導(dǎo)出的OBJ丟進Blender時模型整個沿軸鏡像了仔細(xì)看法線也有問題。排查下來的元兇就是坐標(biāo)轉(zhuǎn)換只做了一半。后來我固定檢查三個點這套標(biāo)準(zhǔn)反復(fù)用了很久頂點X是否取反法線X是否取反三角形索引順序是否反序這三個點必須同時做缺一個模型就會歪。寫代碼的時候用注釋把轉(zhuǎn)換規(guī)則標(biāo)清楚不然時隔半年再回來看腳本肯定忘。5.2 SkinnedMeshRenderer怎么導(dǎo)出當(dāng)前姿態(tài)如果場景里有人物模型直接拿SkinnedMeshRenderer.sharedMesh導(dǎo)出的網(wǎng)格是T-Pose綁定期狀態(tài)不是你在場景里看到的當(dāng)前動畫姿勢。要在腳本里先烘焙一次SkinnedMeshRenderer smr GetComponentSkinnedMeshRenderer(); Mesh bakedMesh new Mesh(); smr.BakeMesh(bakedMesh); // 之后把bakedMesh交給MeshToString處理注意BakeMesh在編輯器下對非激活物體有時會不生效我處理的方式是臨時激活一下再烘焙完事再恢復(fù)原狀。另外烘焙出來的Mesh不包含當(dāng)前材質(zhì)材質(zhì)還是要從smr.sharedMaterials獲取。5.3 材質(zhì)、貼圖和SubMesh的對應(yīng)關(guān)系很多人在寫MTL文件時直接用Unity的材質(zhì)名當(dāng)材質(zhì)名比如newmtl Standard (Instance)空格和括號混在文件名里導(dǎo)入到某些軟件直接報錯。我試過最省心的做法是不管是OBJ里的usemtl還是MTL里的newmtl統(tǒng)一用material_0、material_1這種序號式命名避免特殊字符和重名問題。貼圖則統(tǒng)一拷貝到OBJ同級目錄用純文件名作為map_Kd路徑保證跨平臺不出錯。Unity的Mesh支持多個submesh每個submesh對應(yīng)一組三角形索引。導(dǎo)出時如果不按submesh分段輸出而是把triangles整體當(dāng)一組那么多材質(zhì)模型的UV、法線和材質(zhì)對應(yīng)全亂。腳本里一定要做兩層循環(huán)外層循環(huán)submesh內(nèi)層循環(huán)該submesh的三角形并在切換時輸出usemtl?？此贫嗉恿宋辶写a實際上省了無數(shù)檢查時間。5.4 大Mesh和特殊字符帶來的性能與命名問題當(dāng)Mesh頂點數(shù)到了幾十萬直接用StringBuilder一直Append最后一次性File.WriteAllText會占大量內(nèi)存而且GC會拖慢編輯器。我實測過50萬頂點的Mesh一次性拼接大概要多花300~400MB內(nèi)存。建議改成StreamWriter逐行寫文件using (StreamWriter sw new StreamWriter(outputPath)) { sw.Write(o ).Write(objectName).WriteLine(); foreach (Vector3 v in vertices) sw.WriteLine(string.Format(v {0} {1} {2}, -v.x, v.y, v.z)); // 其他字段同理 }StreamWriter底層有自己的緩沖逐行寫字符串的開銷比你想的低很多而且峰值內(nèi)存能控制在幾十MB以內(nèi)處理大場景時不會卡到編輯器閃退。還有個容易被忽略的點游戲物體名字里經(jīng)常有空格、斜杠、中文、括號這些字符在o對象名里還能忍但在文件名、MTL名里就會出問題。我在導(dǎo)出文件時統(tǒng)一做了清洗把非法文件名字符替換成下劃線string safeName Regex.Replace(originalName, [\\/:*?\|], _);如果是給3D打印做模型要注意OBJ坐標(biāo)和三角面方向之外還得確認(rèn)導(dǎo)出尺寸。Unity單位是米Blender里默認(rèn)單位也是米但很多切片軟件以毫米顯示你需要跟對方確認(rèn)好單位否則打印出來的尺寸和預(yù)期差1000倍。最后再分享一個實際操作中的小細(xì)節(jié)。腳本寫完不是終點真正讓你省時間的是把它塞進項目工作流。我現(xiàn)在維護著一個“一鍵轉(zhuǎn)換”菜單里面同時掛了OBJ導(dǎo)出、官方FBX Exporter、批量命令行三個入口平時把模型拖進工程按需求點按鈕或跑腳本五分鐘之內(nèi)就能把資源轉(zhuǎn)成合作方要的格式。每次在項目里跑完轉(zhuǎn)換我都會拿導(dǎo)出的OBJ到Blender里簡單疊一下網(wǎng)格確認(rèn)沒有法線翻轉(zhuǎn)和丟材質(zhì)再往下游走。這個習(xí)慣幫我躲過了不少坑。如果你的工作流里也經(jīng)常遇到模型格式不兼容的問題這套思路可以直接拿去改花不了多少時間就能變成自己順手的小工具。本文還有配套的精品資源點擊獲取