尧图网站建设 
简介一套面向Unity开发者的.unity3d格式转换脚本工具专门用于将场景、模型、纹理、动画等游戏资源打包为单一格式文件解决项目资源管理与传输中的格式不统一、加载开销大等问题。压缩包采用RAR格式整体仅约5KB内含三个文件两个JavaScript脚本和一个C#脚本虽精简但覆盖了资源导出、自动化批处理等关键路径已有333人学习下载。脚本中C#辅助类专为Unity编辑器设计置于Editor目录下即可扩展为工具菜单两个JS脚本分别对应单个资源导出与批量自动化任务可结合构建流程调用并支持通过参数调整输出路径、压缩质量等针对模型减面、纹理压缩、资源合并等需求进行定制。通过研读这套脚本开发者能快速理解Unity序列化、AssetDatabase及导出接口的配合方式获得一套易于改写复用的资源优化框架还可据此建立自己的构建步骤与命名规则大幅缩短资源准备周期、减少重复劳动对于需要频繁出包或维护多版本资源的团队尤为实用。整体代码简短清晰适合已有一定Unity基础、希望搭建自定义资源管线的开发者和美术人员参考。 在Unity里搞3D模型格式转换尤其是“把一批乱七八糟的模型统一成能用的格式”这件事做过游戏或3D应用开发的人应该都有体会。美术交付的是FBX网上下载的资源是OBJ或者glTF甚至有从老项目里扒出来的模型还带着一层层没用的空节点。手动导入再手动导出真的太费时间还容易漏材质、丢贴图。后来我干脆写了个转换脚本放在Editor目录下选中对象一键转换实测下来确实简单有效。这篇博文就把这个Unity 3D格式转换脚本的实现思路、核心代码和坑都梳理一遍给你一个能直接拿去用的参考。1. 3D格式转换脚本要解决什么问题哪种方案适合你1.1 三个高频场景我看过太多人在这里浪费时间先说场景。第一种项目里来了个外来资源包里面目标模型是FBX但贴图是散的材质球命名是中文导入Unity之后材质全丢全得手动重新指定。第二种你要把Unity项目里的部分模型资产导出给外部团队做二次开发对方只要OBJ格式但你不可能一个个去DCC软件里重新导。第三种程序化生成的内容比如运行时动态生成的Mesh或者从地形系统拆分出来的模型块需要沉淀成可提交的资源文件。这三个场景本质上是同一件事你手上有一堆Unity运行时或编辑器里能读到的3D数据但你希望把它们以另一种格式落到磁盘上。这时候写一个一次性的转换脚本比反复手动操作靠谱得多。脚本可以批量跑可以保证每次导出的参数一致还可以顺手清理节点层级、统一缩放、重置旋转这些手工容易漏的步骤在代码里都是固定流程。1.2 先想清楚你要的是“开发期工具”还是“运行时功能”很多人第一次遇到这个问题时会纠结我应该把转换脚本挂在游戏里运行时让别人点个按钮就能导出模型吗我一般会反问一句你的使用场景到底是在编辑器里打包资产还是要给最终用户提供导出功能。这两者差别非常大选错了后面全是坑。维度Editor脚本推荐Runtime脚本谨慎运行环境Unity编辑器菜单里执行打包后的玩家端运行能访问的资源工程内任意资源、导入设置仅运行时已加载的资源和可读AssetBundle典型用途资产整理、格式统一、批量导出用户自定义内容保存、存档导出依赖UnityEditor命名空间不参与发布只依赖UnityEngine需注意平台API限制调试体验可在Inspector查看支持Undo日志排查相对麻烦做“Unity 3D格式转换脚本”这种工具我的建议是默认走Editor方向因为你在开发阶段解决资产问题根本没必要把这块逻辑打进玩家包里。而且Editor脚本可以直接调用AssetDatabase、ModelImporter这些东西能用最少的代码拿到完整的数据访问权限写起来比Runtime那套干净得多。2. 技术原理脚本为什么能“简单有效”2.1 从Mesh到文本文件OBJ格式是怎样“翻译”出来的想理解转换脚本的核心最好先花五分钟看懂OBJ格式。OBJ是一种极简的文本3D格式它不像FBX是个二进制的大包裹而是一行一行的人能读懂的文本。这个特点决定了它非常适合做“导出目标格式”因为你完全可以不依赖第三方库用字符串拼接就把它写出来。一个OBJ文件里最常见的几类行是这些v x y z // 顶点坐标v 开头 vt u v // UV坐标vt 开头 vn nx ny nz // 法线vn 开头 f 1/1/1 2/2/2 3/3/3 // 面斜杠分隔 顶点索引/UV索引/法线索引面那一行的三个元素前一个是顶点索引中间是UV索引最后是法线索引。注意OBJ索引是从1开始的而Unity这边的数组索引是从0开始脚本里做转换的时候一定要加1。如果你懒得管这些细节把UV、法线的索引和顶点索引当作同一个编号来写只要保证导出时每个顶点都对应一份UV和法线也是能用的Unity的Mesh就是这么组织的顶点数组、UV数组、法线数组按同一套索引对齐所以转换脚本可以写得很简洁。2.2 Unity的Mesh数据到底从哪里取拿到Unity里的模型最直接的数据来源就是MeshFilter组件挂载的sharedMesh。这个对象里有你需要的所有几何信息vertices是顶点坐标数组normals是法线数组uv是UV数组triangles是按三角形排列的索引数组。对于多材质模型还得分subMesh每个子网格对应一种材质。这里有一个关键的取舍导出的时候到底用局部坐标还是世界坐标。我的做法是用transform.localToWorldMatrix先乘一遍顶点这样即使场景里有多个相同模型只有一个是旋转缩放过的导出的OBJ也能保持它在场景中的实际形态。法线同理用矩阵的旋转部分去变换否则模型导出后光影方向会不对劲。很多人第一次写转换脚本就是忘了乘矩阵结果导出模型和场景里呈现的完全不是一回事。2.3 材质、贴图、动画该由谁负责讲一句实在的几何体转换是最容易的部分材质和贴图才是多数转换脚本的痛点。OBJ本身不管材质它用同名的.mtl文件来记录材质信息mtl里通过map_Kd指定漫反射贴图路径。所以如果你要做带材质的OBJ导出你得同时生成一个.mtl文件并且把贴图复制出来不然对方拿到OBJ依旧是灰模。动画和骨骼就更别指望OBJ了它压根就不支持这种高级数据。如果你的目标格式里面必须包含动画那OBJ根本不合适直接上FBX导出方案要么Unity官方FBX Exporter包要么Assimp这类第三方库。所以我通常把需求分成两档只要静态网格用自研脚本导OBJ要动画要骨骼老老实实用官方工具自己写那个复杂度性价比太低。3. 动手实现一个能直接用的Unity Editor脚本3.1 搭建脚本框架目录、菜单、特性先讲结构。转换脚本必须放在Editor目录下否则打包发布时UnityEditor命名空间会直接报错。你可以在Assets下新建一个Editor文件夹在里边建脚本保持和业务代码隔离。脚本最核心的入口是用MenuItem特性注册菜单。这个特性是Unity编辑器扩展的命脉写法就一行[MenuItem(Tools/3D格式转换/导出选中模型为OBJ)]加上这个之后菜单栏Tools下就会出现对应选项。顺带提一下类似的热搜里经常看到“unity特性”“unity宏定义”其实Editor脚本里经常用到#if UNITY_EDITOR宏做平台隔离和MenuItem特性合作就能写出只在编辑器生效的工具代码。还有一个小技巧导出的目标目录用EditorUtility.OpenFolderPanel弹窗选择而不是写死路径这样工具发给别人用的时候不需要改代码就能跑到自己本地目录。3.2 核心转换代码Mesh转OBJ下面是我实际精简过的一个版本完整可以跑。核心逻辑就是前面说的遍历选中对象取MeshFilter的sharedMesh把顶点、法线、UV写到OBJ的文本行里再把三角形索引写成面。using UnityEngine; using UnityEditor; using System.IO; using System.Text; using System.Collections.Generic; public class MeshToObjExporter : EditorWindow { [MenuItem(Tools/3D格式转换/导出选中模型为OBJ)] static void ExportSelectedToObj() { GameObject[] selectedObjects Selection.gameObjects; if (selectedObjects.Length 0) { Debug.LogWarning(请先在场景或层级中选中需要导出的模型对象。); return; } string outputDir EditorUtility.OpenFolderPanel(选择OBJ输出目录, , obj_exports); if (string.IsNullOrEmpty(outputDir)) return; int converted 0; foreach (var go in selectedObjects) { MeshFilter mf go.GetComponentInChildrenMeshFilter(); if (mf null || mf.sharedMesh null) { Debug.LogWarning(${go.name} 没有可以导出的MeshFilter跳过。); continue; } string fileName SanitizeName(go.name); string objPath Path.Combine(outputDir, fileName .obj); string mtlPath Path.Combine(outputDir, fileName .mtl); Mesh mesh mf.sharedMesh; StringBuilder objSb new StringBuilder(); StringBuilder mtlSb new StringBuilder(); Matrix4x4 matrix mf.transform.localToWorldMatrix; objSb.AppendLine(# export from Unity); objSb.AppendLine($mtllib {fileName}.mtl); // 顶点 for (int i 0; i mesh.vertices.Length; i) { Vector3 v matrix.MultiplyPoint3x4(mesh.vertices[i]); objSb.AppendLine($v {v.x:F6} {v.y:F6} {v.z:F6}); } // 法线 for (int i 0; i mesh.normals.Length; i) { Vector3 n matrix.MultiplyVector(mesh.normals[i]); objSb.AppendLine($vn {n.x:F6} {n.y:F6} {n.z:F6}); } // UV for (int i 0; i mesh.uv.Length; i) { objSb.AppendLine($vt {mesh.uv[i].x:F6} {mesh.uv[i].y:F6}); } // 材质 Renderer renderer mf.GetComponentRenderer(); Material[] materials renderer ! null ? renderer.sharedMaterials : new Material[1]; DictionaryMaterial, int matIndexMap new DictionaryMaterial, int(); // 子网格面 for (int sub 0; sub mesh.subMeshCount; sub) { int[] triangles mesh.GetTriangles(sub); Material mat sub materials.Length ? materials[sub] : null; if (mat ! null !matIndexMap.ContainsKey(mat)) { matIndexMap[mat] matIndexMap.Count; string matName SanitizeName(mat.name); mtlSb.AppendLine($newmtl {matName}); if (mat.mainTexture ! null) { // 实际项目这里需要拷贝贴图到输出目录并写 map_Kd 行 mtlSb.AppendLine($map_Kd {mat.mainTexture.name}.png); } } if (mat ! null) { objSb.AppendLine($usemtl {SanitizeName(mat.name)}); } for (int i 0; i triangles.Length; i 3) { int i0 triangles[i] 1; int i1 triangles[i 1] 1; int i2 triangles[i 2] 1; objSb.AppendLine($f {i0}/{i0}/{i0} {i1}/{i1}/{i1} {i2}/{i2}/{i2}); } } File.WriteAllText(objPath, objSb.ToString(), Encoding.UTF8); File.WriteAllText(mtlPath, mtlSb.ToString(), Encoding.UTF8); converted; Debug.Log($已导出: {objPath}); } EditorUtility.DisplayDialog(导出完成, $共导出 {converted} 个模型到 {outputDir}, OK); AssetDatabase.Refresh(); } static string SanitizeName(string name) { StringBuilder sb new StringBuilder(name.Length); foreach (char c in name) { sb.Append(char.IsLetterOrDigit(c) || c _ ? c : _); } return sb.ToString(); } }这段代码如果你直接用普通的静态模型导出是没问题的。三个地方需要注意一下。第一我把顶点索引、UV索引、法线索引写成了同一个值因为前面说过Unity的顶点属性是按同一套顶点索引对齐的这在大多数模型上是成立的。第二材质部分只写了mtl文件名没有真正把贴图文件复制过去实战中要补一段Texture2D导出用AssetDatabase.LoadAssetAtPath拿贴图再EncodeToPNG写入磁盘。第三导出前最好检查一下材质用的Shader是不是标准管线URP/HDRP的材质直接导过去对方软件可能不认这时候需要根据目标需求转一张漫反射贴图。3.3 批量处理与进度反馈脚本里用Selection.gameObjects遍历天然就支持批量。选中十个模型一次全部导出这是手工操作没法比的效率。但批量导出有个体验问题模型多了之后脚本会卡住看起来像Unity崩了。最好加一个进度条让用户知道还在跑。进度条在这个工具里的实现很直接用EditorUtility.DisplayProgressBar就行。在遍历循环里按当前选中数量算百分比每导出一个就刷一次。导出结束后别忘了EditorUtility.ClearProgressBar否则进度条会一直挂在编辑器上。这些小细节正是脚本工具从“能用”变成“好用”的关键。4. 扩展与坑从OBJ到FBX/glTF以及必踩的坑4.1 想转FBX或glTF怎么办OBJ能覆盖静态模型场景但如果你要带骨骼动画的FBX自研脚本的工作量会指数级上升。这时候别再重复造轮子。Unity官方有FBX Exporter包菜单里Window Package Manager搜索“FBX Exporter”就能装打开工具窗口后可以直接把选中模型导出成FBX并保留材质引用、动画Clip。glTF格式推荐用glTFast这个开源库它既能运行时加载glTF也提供了编辑器下的导出接口。顺便说一句用命令行形式的外部转换工具比如某些导出的exe或者用Python脚本调Blender批量转换我也试过。它们适合“完全不打开Unity”的批处理流水线但会带来新的依赖问题。最典型的就是环境变量很多人在终端里输入命令提示“无法识别”并不是工具坏了而是没把可执行文件路径加入PATH。这个和Unity本身无关属于常规环境配置问题我后面在常见问题里也会提。4.2 常见问题与排查速查表整理几个问得最多的问题基本都是我在实际项目里踩过的。问题常见原因解决方案导出后模型没有材质是灰模没有生成.mtl或贴图没有连同导出确保写mtllib且输出目录内包含贴图文件模型方向不对或者颠倒了DCC软件和Unity坐标系不同导出时针对目标软件做轴向交换通常是Z轴取反导出后灯光阴影奇怪法线没有用矩阵变换或法线方向反了用MultiplyVector变换法线必要时翻转法线方向中文文件名/路径导入其他软件乱码OBJ是文本格式编码不匹配文件写入用UTF-8或文件名统一转成英文字符大模型导出卡顿、崩编辑器顶点数量巨大字符串拼接性能差用StringBuilder或分块写入配合进度条第三方插件报DLL加载失败缺少对应平台的native插件包检查插件目录是否包含当前平台架构x86/x64/ARM64最后一行那个DLL问题搜“unity dllnotfoundexception unable to load dll”的话能看到一堆案例。其实就是Unity在编辑器环境下加载native插件时对架构和平台非常严格。插件目录下的dll必须和Unity编辑器进程的架构一致并且放对位置比如Windows x64的编辑器对应x86_64目录。这个坑遇到时不要慌按“插件目录结构是否正确”和“Target Platform是否匹配”两条线查就行。4.3 实测经验效率优化与安全保存最后分享一点我自己用这类工具攒下来的习惯。第一个习惯写完脚本先找一个小模型比如一个Cube加上一个带贴图的材质球把整个导出流程跑通再上真实项目的大模型。如果一开始就拿复杂角色测试出了错很难定位是脚本逻辑问题还是模型本身的问题。第二个习惯批量转换前把源文件做一次备份尤其是被覆盖导入设置的场景。脚本如果除了转换格式之外还会改ModelImporter配置Unity的导入设置是没法轻松撤销的没有备份就有风险。第三个习惯日志一定要打全导出了哪个文件、跳过了哪个对象、为什么跳过这些Debug.Log本身就是排查工具省得以后别人用你的脚本时出了问题还得来问你。如果真的要做项目级的“格式统一”工具我建议在脚本里再增加一个“导入规格统一”的功能选中一批FBX后用ModelImporter把全局缩放、法线导入方式、可读选项全部设置成项目标准然后批量SaveAndReimport。这一步比单纯的格式转换更能解决团队协作中的模型格式混乱问题。我自己的项目里通常是把“格式转换”和“导入规整”合在一个工具窗口里两边是互补的关系。先把外部模型按项目标准导入再导出成需要交付的格式一套流程下来基本不用碰DCC软件。根据个人经验再叮嘱一句写这类工具时不要一上来就想着支持所有格式先锁定你当前项目最小可用的那一个格式跑通等确实有需求了再扩展。我见过太多人一开始就规划“支持FBX、OBJ、glTF、DAE”结果做了一周还在搭框架实际需求早被别人用一个简单的导出脚本解决了。工具是为流程服务的能解决当天的问题比设计一个完美的系统重要得多。本文还有配套的精品资源点击获取 Unity 3D模型格式转换脚本实战：从Mesh到OBJ的批量导出方案
简介一套面向Unity开发者的.unity3d格式转换脚本工具专门用于将场景、模型、纹理、动画等游戏资源打包为单一格式文件解决项目资源管理与传输中的格式不统一、加载开销大等问题。压缩包采用RAR格式整体仅约5KB内含三个文件两个JavaScript脚本和一个C#脚本虽精简但覆盖了资源导出、自动化批处理等关键路径已有333人学习下载。脚本中C#辅助类专为Unity编辑器设计置于Editor目录下即可扩展为工具菜单两个JS脚本分别对应单个资源导出与批量自动化任务可结合构建流程调用并支持通过参数调整输出路径、压缩质量等针对模型减面、纹理压缩、资源合并等需求进行定制。通过研读这套脚本开发者能快速理解Unity序列化、AssetDatabase及导出接口的配合方式获得一套易于改写复用的资源优化框架还可据此建立自己的构建步骤与命名规则大幅缩短资源准备周期、减少重复劳动对于需要频繁出包或维护多版本资源的团队尤为实用。整体代码简短清晰适合已有一定Unity基础、希望搭建自定义资源管线的开发者和美术人员参考。 在Unity里搞3D模型格式转换尤其是“把一批乱七八糟的模型统一成能用的格式”这件事做过游戏或3D应用开发的人应该都有体会。美术交付的是FBX网上下载的资源是OBJ或者glTF甚至有从老项目里扒出来的模型还带着一层层没用的空节点。手动导入再手动导出真的太费时间还容易漏材质、丢贴图。后来我干脆写了个转换脚本放在Editor目录下选中对象一键转换实测下来确实简单有效。这篇博文就把这个Unity 3D格式转换脚本的实现思路、核心代码和坑都梳理一遍给你一个能直接拿去用的参考。1. 3D格式转换脚本要解决什么问题哪种方案适合你1.1 三个高频场景我看过太多人在这里浪费时间先说场景。第一种项目里来了个外来资源包里面目标模型是FBX但贴图是散的材质球命名是中文导入Unity之后材质全丢全得手动重新指定。第二种你要把Unity项目里的部分模型资产导出给外部团队做二次开发对方只要OBJ格式但你不可能一个个去DCC软件里重新导。第三种程序化生成的内容比如运行时动态生成的Mesh或者从地形系统拆分出来的模型块需要沉淀成可提交的资源文件。这三个场景本质上是同一件事你手上有一堆Unity运行时或编辑器里能读到的3D数据但你希望把它们以另一种格式落到磁盘上。这时候写一个一次性的转换脚本比反复手动操作靠谱得多。脚本可以批量跑可以保证每次导出的参数一致还可以顺手清理节点层级、统一缩放、重置旋转这些手工容易漏的步骤在代码里都是固定流程。1.2 先想清楚你要的是“开发期工具”还是“运行时功能”很多人第一次遇到这个问题时会纠结我应该把转换脚本挂在游戏里运行时让别人点个按钮就能导出模型吗我一般会反问一句你的使用场景到底是在编辑器里打包资产还是要给最终用户提供导出功能。这两者差别非常大选错了后面全是坑。维度Editor脚本推荐Runtime脚本谨慎运行环境Unity编辑器菜单里执行打包后的玩家端运行能访问的资源工程内任意资源、导入设置仅运行时已加载的资源和可读AssetBundle典型用途资产整理、格式统一、批量导出用户自定义内容保存、存档导出依赖UnityEditor命名空间不参与发布只依赖UnityEngine需注意平台API限制调试体验可在Inspector查看支持Undo日志排查相对麻烦做“Unity 3D格式转换脚本”这种工具我的建议是默认走Editor方向因为你在开发阶段解决资产问题根本没必要把这块逻辑打进玩家包里。而且Editor脚本可以直接调用AssetDatabase、ModelImporter这些东西能用最少的代码拿到完整的数据访问权限写起来比Runtime那套干净得多。2. 技术原理脚本为什么能“简单有效”2.1 从Mesh到文本文件OBJ格式是怎样“翻译”出来的想理解转换脚本的核心最好先花五分钟看懂OBJ格式。OBJ是一种极简的文本3D格式它不像FBX是个二进制的大包裹而是一行一行的人能读懂的文本。这个特点决定了它非常适合做“导出目标格式”因为你完全可以不依赖第三方库用字符串拼接就把它写出来。一个OBJ文件里最常见的几类行是这些v x y z // 顶点坐标v 开头 vt u v // UV坐标vt 开头 vn nx ny nz // 法线vn 开头 f 1/1/1 2/2/2 3/3/3 // 面斜杠分隔 顶点索引/UV索引/法线索引面那一行的三个元素前一个是顶点索引中间是UV索引最后是法线索引。注意OBJ索引是从1开始的而Unity这边的数组索引是从0开始脚本里做转换的时候一定要加1。如果你懒得管这些细节把UV、法线的索引和顶点索引当作同一个编号来写只要保证导出时每个顶点都对应一份UV和法线也是能用的Unity的Mesh就是这么组织的顶点数组、UV数组、法线数组按同一套索引对齐所以转换脚本可以写得很简洁。2.2 Unity的Mesh数据到底从哪里取拿到Unity里的模型最直接的数据来源就是MeshFilter组件挂载的sharedMesh。这个对象里有你需要的所有几何信息vertices是顶点坐标数组normals是法线数组uv是UV数组triangles是按三角形排列的索引数组。对于多材质模型还得分subMesh每个子网格对应一种材质。这里有一个关键的取舍导出的时候到底用局部坐标还是世界坐标。我的做法是用transform.localToWorldMatrix先乘一遍顶点这样即使场景里有多个相同模型只有一个是旋转缩放过的导出的OBJ也能保持它在场景中的实际形态。法线同理用矩阵的旋转部分去变换否则模型导出后光影方向会不对劲。很多人第一次写转换脚本就是忘了乘矩阵结果导出模型和场景里呈现的完全不是一回事。2.3 材质、贴图、动画该由谁负责讲一句实在的几何体转换是最容易的部分材质和贴图才是多数转换脚本的痛点。OBJ本身不管材质它用同名的.mtl文件来记录材质信息mtl里通过map_Kd指定漫反射贴图路径。所以如果你要做带材质的OBJ导出你得同时生成一个.mtl文件并且把贴图复制出来不然对方拿到OBJ依旧是灰模。动画和骨骼就更别指望OBJ了它压根就不支持这种高级数据。如果你的目标格式里面必须包含动画那OBJ根本不合适直接上FBX导出方案要么Unity官方FBX Exporter包要么Assimp这类第三方库。所以我通常把需求分成两档只要静态网格用自研脚本导OBJ要动画要骨骼老老实实用官方工具自己写那个复杂度性价比太低。3. 动手实现一个能直接用的Unity Editor脚本3.1 搭建脚本框架目录、菜单、特性先讲结构。转换脚本必须放在Editor目录下否则打包发布时UnityEditor命名空间会直接报错。你可以在Assets下新建一个Editor文件夹在里边建脚本保持和业务代码隔离。脚本最核心的入口是用MenuItem特性注册菜单。这个特性是Unity编辑器扩展的命脉写法就一行[MenuItem(Tools/3D格式转换/导出选中模型为OBJ)]加上这个之后菜单栏Tools下就会出现对应选项。顺带提一下类似的热搜里经常看到“unity特性”“unity宏定义”其实Editor脚本里经常用到#if UNITY_EDITOR宏做平台隔离和MenuItem特性合作就能写出只在编辑器生效的工具代码。还有一个小技巧导出的目标目录用EditorUtility.OpenFolderPanel弹窗选择而不是写死路径这样工具发给别人用的时候不需要改代码就能跑到自己本地目录。3.2 核心转换代码Mesh转OBJ下面是我实际精简过的一个版本完整可以跑。核心逻辑就是前面说的遍历选中对象取MeshFilter的sharedMesh把顶点、法线、UV写到OBJ的文本行里再把三角形索引写成面。using UnityEngine; using UnityEditor; using System.IO; using System.Text; using System.Collections.Generic; public class MeshToObjExporter : EditorWindow { [MenuItem(Tools/3D格式转换/导出选中模型为OBJ)] static void ExportSelectedToObj() { GameObject[] selectedObjects Selection.gameObjects; if (selectedObjects.Length 0) { Debug.LogWarning(请先在场景或层级中选中需要导出的模型对象。); return; } string outputDir EditorUtility.OpenFolderPanel(选择OBJ输出目录, , obj_exports); if (string.IsNullOrEmpty(outputDir)) return; int converted 0; foreach (var go in selectedObjects) { MeshFilter mf go.GetComponentInChildrenMeshFilter(); if (mf null || mf.sharedMesh null) { Debug.LogWarning(${go.name} 没有可以导出的MeshFilter跳过。); continue; } string fileName SanitizeName(go.name); string objPath Path.Combine(outputDir, fileName .obj); string mtlPath Path.Combine(outputDir, fileName .mtl); Mesh mesh mf.sharedMesh; StringBuilder objSb new StringBuilder(); StringBuilder mtlSb new StringBuilder(); Matrix4x4 matrix mf.transform.localToWorldMatrix; objSb.AppendLine(# export from Unity); objSb.AppendLine($mtllib {fileName}.mtl); // 顶点 for (int i 0; i mesh.vertices.Length; i) { Vector3 v matrix.MultiplyPoint3x4(mesh.vertices[i]); objSb.AppendLine($v {v.x:F6} {v.y:F6} {v.z:F6}); } // 法线 for (int i 0; i mesh.normals.Length; i) { Vector3 n matrix.MultiplyVector(mesh.normals[i]); objSb.AppendLine($vn {n.x:F6} {n.y:F6} {n.z:F6}); } // UV for (int i 0; i mesh.uv.Length; i) { objSb.AppendLine($vt {mesh.uv[i].x:F6} {mesh.uv[i].y:F6}); } // 材质 Renderer renderer mf.GetComponentRenderer(); Material[] materials renderer ! null ? renderer.sharedMaterials : new Material[1]; DictionaryMaterial, int matIndexMap new DictionaryMaterial, int(); // 子网格面 for (int sub 0; sub mesh.subMeshCount; sub) { int[] triangles mesh.GetTriangles(sub); Material mat sub materials.Length ? materials[sub] : null; if (mat ! null !matIndexMap.ContainsKey(mat)) { matIndexMap[mat] matIndexMap.Count; string matName SanitizeName(mat.name); mtlSb.AppendLine($newmtl {matName}); if (mat.mainTexture ! null) { // 实际项目这里需要拷贝贴图到输出目录并写 map_Kd 行 mtlSb.AppendLine($map_Kd {mat.mainTexture.name}.png); } } if (mat ! null) { objSb.AppendLine($usemtl {SanitizeName(mat.name)}); } for (int i 0; i triangles.Length; i 3) { int i0 triangles[i] 1; int i1 triangles[i 1] 1; int i2 triangles[i 2] 1; objSb.AppendLine($f {i0}/{i0}/{i0} {i1}/{i1}/{i1} {i2}/{i2}/{i2}); } } File.WriteAllText(objPath, objSb.ToString(), Encoding.UTF8); File.WriteAllText(mtlPath, mtlSb.ToString(), Encoding.UTF8); converted; Debug.Log($已导出: {objPath}); } EditorUtility.DisplayDialog(导出完成, $共导出 {converted} 个模型到 {outputDir}, OK); AssetDatabase.Refresh(); } static string SanitizeName(string name) { StringBuilder sb new StringBuilder(name.Length); foreach (char c in name) { sb.Append(char.IsLetterOrDigit(c) || c _ ? c : _); } return sb.ToString(); } }这段代码如果你直接用普通的静态模型导出是没问题的。三个地方需要注意一下。第一我把顶点索引、UV索引、法线索引写成了同一个值因为前面说过Unity的顶点属性是按同一套顶点索引对齐的这在大多数模型上是成立的。第二材质部分只写了mtl文件名没有真正把贴图文件复制过去实战中要补一段Texture2D导出用AssetDatabase.LoadAssetAtPath拿贴图再EncodeToPNG写入磁盘。第三导出前最好检查一下材质用的Shader是不是标准管线URP/HDRP的材质直接导过去对方软件可能不认这时候需要根据目标需求转一张漫反射贴图。3.3 批量处理与进度反馈脚本里用Selection.gameObjects遍历天然就支持批量。选中十个模型一次全部导出这是手工操作没法比的效率。但批量导出有个体验问题模型多了之后脚本会卡住看起来像Unity崩了。最好加一个进度条让用户知道还在跑。进度条在这个工具里的实现很直接用EditorUtility.DisplayProgressBar就行。在遍历循环里按当前选中数量算百分比每导出一个就刷一次。导出结束后别忘了EditorUtility.ClearProgressBar否则进度条会一直挂在编辑器上。这些小细节正是脚本工具从“能用”变成“好用”的关键。4. 扩展与坑从OBJ到FBX/glTF以及必踩的坑4.1 想转FBX或glTF怎么办OBJ能覆盖静态模型场景但如果你要带骨骼动画的FBX自研脚本的工作量会指数级上升。这时候别再重复造轮子。Unity官方有FBX Exporter包菜单里Window Package Manager搜索“FBX Exporter”就能装打开工具窗口后可以直接把选中模型导出成FBX并保留材质引用、动画Clip。glTF格式推荐用glTFast这个开源库它既能运行时加载glTF也提供了编辑器下的导出接口。顺便说一句用命令行形式的外部转换工具比如某些导出的exe或者用Python脚本调Blender批量转换我也试过。它们适合“完全不打开Unity”的批处理流水线但会带来新的依赖问题。最典型的就是环境变量很多人在终端里输入命令提示“无法识别”并不是工具坏了而是没把可执行文件路径加入PATH。这个和Unity本身无关属于常规环境配置问题我后面在常见问题里也会提。4.2 常见问题与排查速查表整理几个问得最多的问题基本都是我在实际项目里踩过的。问题常见原因解决方案导出后模型没有材质是灰模没有生成.mtl或贴图没有连同导出确保写mtllib且输出目录内包含贴图文件模型方向不对或者颠倒了DCC软件和Unity坐标系不同导出时针对目标软件做轴向交换通常是Z轴取反导出后灯光阴影奇怪法线没有用矩阵变换或法线方向反了用MultiplyVector变换法线必要时翻转法线方向中文文件名/路径导入其他软件乱码OBJ是文本格式编码不匹配文件写入用UTF-8或文件名统一转成英文字符大模型导出卡顿、崩编辑器顶点数量巨大字符串拼接性能差用StringBuilder或分块写入配合进度条第三方插件报DLL加载失败缺少对应平台的native插件包检查插件目录是否包含当前平台架构x86/x64/ARM64最后一行那个DLL问题搜“unity dllnotfoundexception unable to load dll”的话能看到一堆案例。其实就是Unity在编辑器环境下加载native插件时对架构和平台非常严格。插件目录下的dll必须和Unity编辑器进程的架构一致并且放对位置比如Windows x64的编辑器对应x86_64目录。这个坑遇到时不要慌按“插件目录结构是否正确”和“Target Platform是否匹配”两条线查就行。4.3 实测经验效率优化与安全保存最后分享一点我自己用这类工具攒下来的习惯。第一个习惯写完脚本先找一个小模型比如一个Cube加上一个带贴图的材质球把整个导出流程跑通再上真实项目的大模型。如果一开始就拿复杂角色测试出了错很难定位是脚本逻辑问题还是模型本身的问题。第二个习惯批量转换前把源文件做一次备份尤其是被覆盖导入设置的场景。脚本如果除了转换格式之外还会改ModelImporter配置Unity的导入设置是没法轻松撤销的没有备份就有风险。第三个习惯日志一定要打全导出了哪个文件、跳过了哪个对象、为什么跳过这些Debug.Log本身就是排查工具省得以后别人用你的脚本时出了问题还得来问你。如果真的要做项目级的“格式统一”工具我建议在脚本里再增加一个“导入规格统一”的功能选中一批FBX后用ModelImporter把全局缩放、法线导入方式、可读选项全部设置成项目标准然后批量SaveAndReimport。这一步比单纯的格式转换更能解决团队协作中的模型格式混乱问题。我自己的项目里通常是把“格式转换”和“导入规整”合在一个工具窗口里两边是互补的关系。先把外部模型按项目标准导入再导出成需要交付的格式一套流程下来基本不用碰DCC软件。根据个人经验再叮嘱一句写这类工具时不要一上来就想着支持所有格式先锁定你当前项目最小可用的那一个格式跑通等确实有需求了再扩展。我见过太多人一开始就规划“支持FBX、OBJ、glTF、DAE”结果做了一周还在搭框架实际需求早被别人用一个简单的导出脚本解决了。工具是为流程服务的能解决当天的问题比设计一个完美的系统重要得多。本文还有配套的精品资源点击获取