简介一款面向Unity开发者的场景与模型导出插件用于将包含GameObject与Terrain的完整场景以及FBX模型批量转换为OBJ文件解决关卡资源备份、跨工具交换和导航网格烘焙前的几何数据准备问题。插件支持自定义裁剪区域、自动裁剪和非正式选择导出能够灵活控制导出范围与对象筛选核心逻辑以Editor目录下的C#脚本实现方便中高级开发者在原生导出流程上继续扩展。压缩包共10个文件大小仅540KB包含1个核心ExportScene.cs脚本、4张界面效果图、3个Markdown说明文档README、更新日志、许可证以及package.json和.gitignore配置结构精简便于直接查阅和二次修改。资源以zip格式提供可导入Unity工程后直接复用目前已有1630人学习下载是理解场景对象与地形遍历、裁剪和OBJ序列化输出的轻量参考实现也可作为Unity编辑器扩展的学习样例。1. ExportSceneToObj 到底是什么一次把场景变成 OBJ 的 Unity 工具做 Unity 项目的人迟早会遇到一个很奇怪的需求场景里摆好的地形、建筑、物件怎么才能原封不动地交给别的工具用不管是给 Blender 做后期修模、给 3ds Max 做光照烘焙还是拿去做外部工具的数据校验最通用的中间格式就是 OBJ。ExportSceneToObj 这个 Unity 工具干的就是这件事——把当前场景里的 GameObject、地形 Terrain、甚至导入的 FBX 资源一键导出成带顶点、UV、法线、材质的 .obj 文件。它不是 Asset Store 上那种黑匣子插件源码就是 C#挂在 Editor 菜单里就能跑适合需要自定义导出逻辑的团队直接改。如果你正在做导航网格、场景烘焙、模型外送或者只是想把 Unity 里的场景给同事的 Max 打开这篇笔记能帮你少踩不少坑。2. 场景导出链路从 GameObject 到 OBJ 文件的顶点重算OBJ 这种格式说穿了就是一组顶点坐标、一组 UV 坐标、一组法线再加一堆用顶点索引拼出来的面。Unity 场景里见到的 Mesh 千奇百怪——有带骨骼的 SkinnedMeshRenderer、有不带骨骼的 MeshFilter、有程序化生成的网格还有 Terrain 这种压根没有 Mesh 的地形组件。要把它们统一导成一个 OBJ核心思路是先把所有东西掰成同一个形态要么你拿到 MeshFilter.sharedMesh 直接读要么你把 Renderer 的顶点变换到世界空间再输出。下面按实际工具的做法拆开讲。2.1 遍历场景对象的 C# 主循环ExportSceneToObj 的做法是遍历当前场景根物体下的所有子物体逐个检查有没有需要导出的组件。常见做法是这样对每个 GameObject 先取 MeshFilter没取到再取 SkinnedMeshRenderer两个都没有就跳过。这样能保证场景里 99% 的静态物体都被捞进来。核心代码逻辑类似using UnityEngine; using UnityEditor; using System.Collections.Generic; using System.IO; public static class SceneExporter { public static bool ExportActiveScene(string outputPath) { var rootObjects UnityEngine.SceneManagement.SceneManager .GetActiveScene().GetRootGameObjects(); var allMeshes new List(Mesh mesh, Transform transform)(); foreach (var root in rootObjects) { var filters root.GetComponentsInChildrenMeshFilter(); foreach (var filter in filters) { if (filter.sharedMesh null) continue; allMeshes.Add((filter.sharedMesh, filter.transform)); } var skinned root.GetComponentsInChildrenSkinnedMeshRenderer(); foreach (var s in skinned) { if (s.sharedMesh null) continue; allMeshes.Add((s.sharedMesh, s.transform)); } } // 真正的顶点变换和文件写入在下一步 return ObjWriter.Write(allMeshes, outputPath); } }这里有个细节值得注意SkinnedMeshRenderer 的顶点拿到后需要把骨骼蒙皮算一遍才能得到最终顶点位置直接拿 sharedMesh.vertices 导出的话人物是 T-Pose 原始形态。ExportSceneToObj 的默认处理是 Stepping 蒙皮计算还是导绑定姿势决定了最终导出结果是不是你看到的画面状态。我一般会加一个开关参数默认导出 T-Pose需要被蒙皮动画形状时再开计算因为蒙皮计算涉及大量矩阵运算场景角色一多导出速度差距很明显。Has 组件判断的先后顺序也有讲究。优先判断 MeshFilter 再判断 SkinnedMeshRenderer是因为场景里偶尔会出现同时挂两个渲染组件的情况先拿到谁就用谁能保证导出结果和 Game 视图看到的一致。另一个容易遗漏的点是 LOD Group物体带 LOD 时MeshFilter 通常挂在子物体上GetComponentsInChildren 默认是能拿到的但 LOD 切换用的 Renderer 可能是当前不可见的导出时要显式忽略 enabled false 的组件否则会把隐藏 LOD 层的模型也导出来。2.2 OBJ 写入器顶点、UV、法线的拼接顺序拿到 Mesh 之后真正难的是把 Unity 的顶点数据结构安全翻译成 OBJ 的文本行。OBJ 的格式要求所有顶点共用一份 v 列表、所有 UV 共用一份 vt 列表、所有法线共用一份 vn 列表面通过 v/vt/vn 的索引组合引用它们。Unity 的 Mesh.vertices 和 mesh.uv 是对应关系但每个三角形的顶点索引是独立的所以最简单的方式是不做顶点合并直接按三角形展开写入。这个方法省了查重逻辑代价是文件体积偏大但胜在绝对不会出错。核心写文件的代码可以这样组织public static class ObjWriter { public static bool Write(List(Mesh mesh, Transform transform) entries, string path) { var sb new System.Text.StringBuilder(); sb.AppendLine(# exported by ExportSceneToObj); int vertexOffset 1; // OBJ 索引从 1 开始 foreach (var entry in entries) { var mesh entry.mesh; var tf entry.transform; // 把顶点变换到世界空间 Vector3[] verts mesh.vertices; Vector3[] normals mesh.normals; Vector2[] uvs mesh.uv; sb.AppendLine($o {tf.gameObject.name}); // 写顶点坐标 for (int i 0; i verts.Length; i) { Vector3 world tf.TransformPoint(verts[i]); sb.AppendLine($v {world.x:F6} {world.y:F6} {world.z:F6}); } // 写 UV if (uvs.Length 0) { for (int i 0; i uvs.Length; i) { sb.AppendLine($vt {uvs[i].x:F6} {uvs[i].y:F6}); } } else { // 补默认 UV保证索引对齐 for (int i 0; i verts.Length; i) sb.AppendLine(vt 0.000000 0.000000); } // 写法线注意要经过 transform 的旋转 if (normals.Length 0) { for (int i 0; i normals.Length; i) { Vector3 worldNormal tf.TransformDirection(normals[i]); sb.AppendLine($vn {worldNormal.x:F6} {worldNormal.y:F6} {worldNormal.z:F6}); } } else { for (int i 0; i verts.Length; i) sb.AppendLine(vn 0 1 0); } // 写三角面 for (int sub 0; sub mesh.subMeshCount; sub) { int[] tris mesh.GetTriangles(sub); for (int i 0; i tris.Length; i 3) { int i0 tris[i] vertexOffset; int i1 tris[i 1] vertexOffset; int i2 tris[i 2] vertexOffset; sb.AppendLine($f {i0}/{i0}/{i0} {i1}/{i1}/{i1} {i2}/{i2}/{i2}); } } vertexOffset verts.Length; } File.WriteAllText(path, sb.ToString()); return true; } }这段代码有几个关键决策点要解释清楚。第一顶点用 TransformPoint 转到世界空间等于把所有局部坐标的模型都摆到它在场景里的最终位置这样导出的 OBJ 打开后看到的就是和 Unity 场景一致的整体布局。第二每个面都写 v/vt/vn 三个相同索引是因为上面没做顶点合并同一个顶点在三个列表里的位置一一对应这样最简单也最稳。如果你的场景里一个物体几千个三角面这个写法没问题如果是几百万面的高模建议先做一遍顶点焊接再导出不然文件能用但加载会慢。UV 缺失补默认值这个操作特别重要。OBJ 的 vt 列表必须和面索引对上如果某些 Mesh 没有 UV 而你又直接跳过 vt 行导入到 Blender 时面的索引就会错位模型会变成一团乱线。补一组 (0,0) 至少保证索引对齐。法线的处理也是同理Unity 里某些程序化生成的 Mesh 没有法线数据这时不补 vn 的话导入端可能直接拒绝识别。默认给 (0,1,0) 是偷懒但至少模型不会丢。这里还有一个暗坑normal 用 TransformDirection 旋转是对的但因为 Unity 是左手坐标系、OBJ 是右手坐标系整个模型导出去后其实是镜像的。这个放到避坑章展开说实践中因为这个问题翻车的人最多。2.3 Terrain 地形转 Mesh采样高度图再生成顶点Terrain 在 Unity 里是很特殊的存在。它没有 MeshFilter用的是一整块地形系统通过高度图驱动 GPU 细分生成几何体。要导出 OBJ标准做法是把 TerrainData 的高度图按指定精度采样成网格顶点。ExportSceneToObj 里对 Terrain 的处理思路大概是先拿到 terrainData.heightmapResolution然后按用户配置的 step 间隔遍历高度点生成一个平面网格。伪代码逻辑public static Mesh TerrainToMesh(Terrain terrain, int step) { TerrainData data terrain.terrainData; int w data.heightmapResolution; int h data.heightmapResolution; var vertices new ListVector3(); var triangles new Listint(); var uvs new ListVector2(); for (int y 0; y h - 1; y step) { for (int x 0; x w - 1; x step) { // 获取世界空间下的地形顶点坐标 float height data.GetHeight(y, x); float worldX terrain.transform.position.x x; float worldZ terrain.transform.position.z y; float worldY terrain.transform.position.y height; vertices.Add(new Vector3(worldX, worldY, worldZ)); } } // 按行生成三角面索引 int cols Mathf.CeilToInt((w - 1) / step) 1; // ... 循环生成 triangle 索引 var mesh new Mesh(); mesh.vertices vertices.ToArray(); mesh.triangles triangles.ToArray(); mesh.uv uvs.ToArray(); return mesh; }这段代码有两个必须说透的参数。第一个是 step它决定了导出地形的精细程度。step 1 时采样原始高度图的每一个点几百米的地形可能产生几十万顶点文件几十 MBstep 4 或 8 时顶点数量指数级下降但地形细节会丢一部分。我实际项目里一般 step 取 4地面起伏不明显的区域取 8除非是要做精确碰撞或导航网格才用 1。第二个关键点是 GetHeight 返回的是相对地形本地坐标的高度需要加上 terrain.transform.position.y 才是世界坐标。这个漏掉的话整个地形会悬浮或者陷入地下。还要注意地形上的纹理。Terrain 的 splatmap 纹理信息在 OBJ 里没法直接表达导出时一般只保留顶点位置的几何信息。如果你需要地面的贴图信息得额外生成一张 splatmap 融合后的贴图然后手动挂到导出的 OBJ 材质上——这个 ExportSceneToObj 本身不做需要你自己在外部处理。忽略贴图只导几何对大多数用途来说已经够了。3. FBX 导入资源的导出Unity 的导入缩放与坐标系翻转Unity 里导 FBX 和直接导 Mesh 还是有区别的。FBX 文件在导入 Unity 时会被 AssetImporter 做一次预处理包括缩放单位的换算、坐标轴方向的适配、材质贴图的提取。如果你在场景里放了一个 FBX 模型直接 GetComponent ().sharedMesh 拿到的顶点坐标和在 Blender/Max 里打开原始 FBX 看到的坐标并不一样。这块不搞清楚导出的 OBJ 就很可能会出现模型歪了或者尺寸差 100 倍的问题。3.1 FBX 在 Unity 里的真实变换链Unity 导入 FBX 时默认的坐标转换是FBX 的 Z 轴方向变成了 Unity 的 Y 轴方向同时缩放单位从厘米换算成米。比如你在 3ds Max 里做了一个 100 厘米的立方体导入 Unity 后 Transform.scale 会显示成 100但模型的 localScale 其实是 1——之所以看起来尺寸对是因为 Unity 的 Import Settings 里 File Scale 默认把单位换算掉了。导 FBX 时会出现一种典型问题直接在 OnPostprocessAllAssets 里读 sharedMesh然后按上面的 ObjWriter 导出结果拿到 Blender 里打开模型是倒的或者旋转了 90 度。原因是 sharedMesh 里的顶点已经是 Unity 坐标系下的数据但你的导出逻辑可能没有经过场景里 Transform 的旋转补偿。ExportSceneToObj 的做法是在导出 FBX 时单独处理把根节点的旋转清零只保留缩放或者干脆在导出前遍历所有子节点把旋转和缩放的复合矩阵算进顶点变换。public static void ExportFbxAsObj(string fbxAssetPath, string outputPath) { var fbx AssetDatabase.LoadAssetAtPathGameObject(fbxAssetPath); var allFilters fbx.GetComponentsInChildrenMeshFilter(); using (var writer new StreamWriter(outputPath)) { int vOffset 1; foreach (var filter in allFilters) { var mesh filter.sharedMesh; var tf filter.transform; // FBX 实际导入后根节点通常 scale 是 1但子节点可能带旋转 Matrix4x4 localMatrix tf.localToWorldMatrix; for (int i 0; i mesh.vertices.Length; i) { Vector3 localVert mesh.vertices[i]; Vector3 worldVert localMatrix.MultiplyPoint(localVert); // 这里要额外做一次坐标轴交换从 Unity (Y-up) 到 OBJ (Z-up) 或者保留 writer.WriteLine($v {worldVert.x} {worldVert.y} {worldVert.z}); } // ... 后续 UV、法线、面索引逻辑与前面一致 } } }这里的 localToWorldMatrix 拿的是每个 MeshFilter 自身的变换FBX 资源里子节点的旋转经常不是规规矩矩的 0/90 度而是有负 scale。负 scale 会导致法线方向反转导出后模型表面会出现黑面。处理方式是检测矩阵的 determinant 是否为负如果是就说明有镜像缩放这时法线要乘上 -1。这个坑很多人等到模型导入 Blender 后才发现——模型看起来只翻转了一部分面特别难排查。还有一个实际项目里常遇到的FBX 的动画和变形器。带骨骼动画的 FBX 导到 OBJ 就没意义了——OBJ 不支持骨骼权重和动画曲线。ExportSceneToObj 对这类资源要么导 T-Pose 静态网格要么直接跳过并报警告日志。别指望把动画模型导成 OBJ 还能保留动画这个格式的边界就在这。3.2 材质与 mtl 文件导出 OBJ 后颜色为什么是灰的OBJ 本身不存材质颜色它通过外挂的 .mtl 文件引用贴图和基础色。Unity 里材质用的是 PBR 管线Albedo、Metallic、Smoothness 各是一张贴图导出成 OBJ 时如果只导几何信息导入 Blender 后默认是灰度材质看起来像丢失了所有颜色。这不是工具问题是 OBJ 格式本身就简陋。ExportSceneToObj 的常见扩展是顺带生成一个 mtl 文件把 Unity 材质里的 Albedo 贴图路径写成 map_Kd 指令再把 Metallic 对应到 map_Pm 或者直接忽略。我在实际项目里的做法是导出 OBJ 时同时生成 mtlmtl 里把每个 Unity 材质导出成 Blender 能识别的 Principled BSDF 参数近似值newmtl Material_001 Kd 0.800000 0.800000 0.800000 map_Kd Textures/albedo_001.png Ns 150.000000 Ni 1.000000 d 1.000000 illum 2注意 map_Kd 引用的是相对路径这个路径必须和你导出的 OBJ 文件在同一个层级否则打开 OBJ 时贴图找不到。另外 Unity 的贴图资源是 .asset 元数据包裹的实际贴图文件路径不一定是你在 Project 面板看到的路径导出时要通过 AssetDatabase.GetAssetPath 拿到完整路径再决定复制贴图文件到 OBJ 旁边的目录还是只写路径。前者文件体积大后者换一台电脑打不开贴图两种方案各有利弊我一般选复制文件省得别人拿到模型后贴图加载一脸懵。材质和面的对应关系也有讲究。Unity 的一个 Mesh 可能有多个 submaterial导出 OBJ 面对应 mtl 的 usemtl 指令。如果你的 Mesh 用了两个材质三角面索引必须按 submesh 分开写每组三角面前加一行 usemtl Material_002。漏掉这一步的后果是模型整体只用第一个材质多材质模型看起来颜色完全不对。很多人在这一步翻车原因是 Unity 的 GetTriangles 是按 submesh 返回的遍历的时候很容易忘记切换 mtl 名。3.3 RecastNavigation 整合点为 NavMesh 数据准备的导出标题关键词里出现的 recast-navigation 不是装饰品。Recast 是 Recast Navigation 的开源库Unity 的 NavMesh 烘焙底层用的就是它。有些项目需要在运行时或者离线阶段把场景几何喂给 Recast 的 C 模块做 NavMesh 生成这时候场景里摆的物体、地形就必须先导出成 Recast 能吃的格式。OBJ 恰好是 Recast 官方 demo 支持读入的几何格式之一。ExportSceneToObj 在这个场景下的价值就体现出来了你可以在编辑器里导出 OBJ然后拿这个 OBJ 喂给自建的 Recast 烘焙工具或者直接在运行时用 C 插件读取 OBJ 做动态寻路网格。Unity 自带的 Navigation 面板虽然也能烘焙 NavMesh但它是黑匣子参数不透明生成结果也不能导出到外部。用 ExportSceneToObj 生成 OBJ 再走 Recast 流程好处是你可以完全控制体素化参数、代理半径、爬坡角度生成逻辑在外部可调试、可复现。结合点上的一个关键参数是导出的坐标精度。Recast 对输入几何的精度很敏感如果 OBJ 里的顶点坐标用了太多小数位体素化阶段会产生大量冗余三角形NavMesh 生成时间拉长好几倍。建议导出时把坐标保留到 3 位小数即毫米级精度——这个精度对导航网格足够文件体积却小得多。上面代码里用的是 F6做导航用途时应该手动改成 F3。4. 避坑与排查导出 OBJ 常见的五个翻车现场这部分内容才是这个工具真正值钱的地方。以下问题我基本全踩过一遍有些甚至是同一个坑踩了两次——第一次是不懂原理第二次是忘了上次的教训。每条都按现象、原因、解决的顺序写你自己对号入座即可。4.1 模型导进 Blender 后法线一片黑现象OBJ 导入 Blender 后模型表面看起来灰黑色斑块状翻面也很奇怪光照像打在碎镜子上。 原因Unity 的左手坐标系和 OBJ 的右手坐标系不兼容。顶点坐标本身没有问题但三角形的 winding order 反了——Unity 的顺时针在 OBJ 里是逆时针导致背面剔除逻辑反转法线方向也跟着全反。另一个原因是负缩放的 Transform某个轴 scale 是 -1 时导出的法线计算结果完全错误。 解决导出时对三角形索引做一次翻转把 f 行的三个索引顺序从 i0/i1/i2 改成 i0/i2/i1。同时检测矩阵的 determinant负数时把法线全部取反。上面写的代码里没有做这一步实际工具里必须加上。这个修复后Blender 里模型的法线方向和 Unity 里的视觉效果就基本一致了。4.2 地形导出后发现地面整个位移了现象地形导出的 OBJ 加载到 3ds Max 里位置比场景里的其他物体高出一大截或者直接嵌入到地下几十米。 原因Terrain.GetHeight 返回的是相对地形本身的本地高度而 terrain.transform.position.y 才是地形在世界空间的地面高度。常见错误是只写了高度图的数值忘了加 transform.position.y导致整个地形模型的位置整体偏离。还有一种是 step 采样时坐标轴搞混把 width 当 height 用地形 OBJ 变成了长宽互换的形状。 解决把顶点生成部分改成 worldY terrain.transform.position.y height; 并且确认遍历顺序和高度图的行列方向一一对应。建议导出后先在 Blender 里对比地形和周边物体的位置关系确认无误再继续后续操作。地形导错位置是最隐蔽的因为如果不和周边对照单独看地形形状是对的。4.3 FBX 导出后模型尺寸莫名其妙大了 100 倍现象从 FBX 预置体导出 OBJ导入其他软件后模型比原始尺寸大得多或者正好缩小 100 倍。 原因Unity 的 FBX 导入默认按厘米为单位换算但如果你把 FBX 挂在场景里的某个 GameObject 下这个 GameObject 的 scale 可能已经被你调过了。导出时用了 worldToLocalMatrix 后又叠上了一次导入时的缩放单位换算被重复计算。 解决在做 FBX 导出时不取场景里的 transform而是只取 FBX 原始资源里 MeshFilter 的顶点数据不做任何世界空间变换——保持原始 FBX 的坐标输出。如果一定要用场景里的变换需要先手动统一所有 scale 为 1或者记录下 FBX 的原始尺寸再按比例回调。我的习惯是 FBX 导出统一从资源层面走不从场景实例走这样结果最可控。4.4 顶点数量爆炸几百 KB 的模型导出成几十 MB现象一个 3 万面的模型导出 OBJ 后一个文件几十 MB导入 Blender 要卡好几秒。 原因OBJ 导出时做了三角形展开每个顶点重复写了多次。同一个顶点在 Mesh.vertices 里出现两次导出的 OBJ 里就有两个 v 行两者数值完全相同。表面看是格式冗余实际是导出的数据没有做顶点焊接。 解决导出前对顶点做一次 hash 去重把相同位置的顶点合并成同一个索引。代码上可以维护一个 DictionaryVector3, int 记录坐标到索引的映射写入顶点时先查表。这个操作顶点数量一多能缩小一半以上的文件体积而且对后续加载性能影响很大。不过要注意UV 和法线如果不同单纯按位置哈希会丢失属性——用位置 UV 法线的组合哈希可以避免这个问题。4.5 导出后打开 OBJ 提示错误模型显示空白现象双击 OBJ 文件常用查看软件直接不显示模型或者提示索引超出范围之类的错误。 原因OBJ 的索引从 1 开始但有些导出代码很容易在顶点合并后忘记更新索引偏移。另一个原因是有的 Mesh 只有三角形索引但导出代码按四边形处理就出现了索引错位。还有一种情况是 MeshFilter.sharedMesh 是 null但物体仍存在导出端没做判空就继续写数据写出来的 OBJ 文件里只有 o 行为空。 解决导出循环里强制检查 mesh.vertexCount 0mesh.triangles.Length 0不满足的直接跳过并打印警告。输出完成后在 Unity 的 Console 面板看一遍日志确认所有跳过的物体是否符合预期。再用一个最小验证方案——拿一个 Cube 导出导入 Blender 确认正常再去导复杂场景。从最小用例开始排查能省大量定位时间。5. 参数与配置按你的需求调整导出精度和范围ExportSceneToObj 这类工具默认输出干净利落但实际项目里没人用默认参数就能一步到位。不同的下游工具对 OBJ 的耐心不同——3ds Max 能吃下几百万面但移动端的查看器可能需要简化网格。这一章把最关键的几个参数说清楚并给出实际项目中的推荐配置。5.1 关键参数表采样间隔、坐标偏移、是否合并网格参数名默认值作用范围推荐设置terrainStep1Terrain 采样精度场景大用 4~8小场景用 1~2exportWorldSpacetrue顶点坐标空间导出给外部软件保持 true给 Recast 用 truemergeAllMeshesfalse是否合并所有网格为一个对象需要顶点焊接时开 true保持结构时开 falseflipWindingtrue三角形绕序导入 Blender/XSI 必须 true导入 Unity 自用可 falseincludeSkinnedPosefalse蒙皮网格导出方式导出 T-Pose 选 false导出当前姿势选 truecoordinateSwapYToZfalse坐标轴Blender/Max 导入时开 true外部工具支持 Y-up 时关precision6小数点位数Recast 用途填 3普通查看用途填 6exportMaterialstrue是否生成 mtl需要贴图关联时开 true纯几何时关 false其中 mergeAllMeshes 这个参数值得多讲两句。开 true 时所有物体焊接成一个整体好处是导入 Recast 或 3ds Max 时处理起来快坏处是丢失了各个物体的独立层级结构——物体名字、分组信息全没了。如果你是导出给美术同事在 Blender 里按物件单独调材质务必保持 false。terrainStep 也是同样的道理它对地形的顶点数量影响是指数级的从 1 调到 4顶点数缩到 1/16。5.2 批量导出多场景、多 FBX 的批处理方案实际项目里经常碰到整个项目有 30 个场景每个场景都要导出一份 OBJ的需求手动一个一个点 Editor 菜单会点崩溃。这时直接在 Editor 脚本里写成批处理用 MenuItem 的优先级控制入口然后用 AssetDatabase 遍历所有场景文件批量导出。大体思路[MenuItem(Tools/Export All Scenes As Obj)] public static void ExportAllScenes() { string[] sceneGuids AssetDatabase.FindAssets(t:Scene); foreach (var guid in sceneGuids) { string scenePath AssetDatabase.GUIDToAssetPath(guid); string outputPath Exported/ Path.GetFileNameWithoutExtension(scenePath) .obj; // 打开场景导出再切回当前场景 EditorSceneManager.OpenScene(scenePath); SceneExporter.ExportActiveScene(outputPath); Debug.Log($Exported {scenePath} to {outputPath}); } }这段逻辑里有三个容易踩的细节。第一EditorSceneManager.OpenScene 会改变当前环境批量导出前必须先记录当前激活场景的路径导出完再切回来否则美术同事切到别的场景导出正好把他改到一半没保存的场景内容弄丢——别问我是怎么知道的。第二FindAssets(t:Scene) 会返回项目中所有场景包括那些还没放进 Build Settings 的批量导出前最好按目录过滤或者维护一个导出白名单列表。第三导出过程涉及大量 IO 操作Unity 主线程会卡住建议加上 EditorUtility.DisplayProgressBar 显示进度条——场景数量超过二十个时这个 UI 反馈能避免同事误以为 Unity 崩了。批量方案还有一个隐性收益方便做 CI。如果你在 CI 环境里跑导出可以直接用 Unity 的命令行参数执行编辑器静态方法这样每次项目更新后都会自动生成一套新的 OBJ 快照供外部工具链消费。我所在团队的做法是每天晚上自动导出全部场景第二天早上大家直接在共享盘里拿最新 OBJ 做导航网格测试。5.3 自定义过滤规则排除特定物体与区域场景不是所有东西都该导出。编辑器辅助线、Gizmo、Debug 专用的球体、性能测试用的临时体这些 obj 导出后就变成了垃圾数据占用体积极光还容易被下游误用。ExportSceneToObj 需要提供按名称、按 Tag、按 Layer 的过滤方式。我在自己项目里加了一套规则按 Tag 排除所有 EditorOnly 标签的物体按层级排除所有名字带 _temp 后缀的物体public static bool ShouldExport(GameObject go) { if (go.CompareTag(EditorOnly)) return false; if (go.name.StartsWith(_Temp)) return false; if (go.layer LayerMask.NameToLayer(IgnoreExport)) return false; // 排除隐藏物体默认选项 if (!go.activeInHierarchy !exportInactive) return false; return true; }这段过滤逻辑要放在遍历 MeshFilter 之前判断父物体而不是找到 MeshFilter 后判断每个组件挂的物体。因为一个父物体隐藏时子物体的 activeInHierarchy 已经是 false但直接判断子物体还能捞到它——你导出的模型里会出现一堆明明在场景里看不到的隐藏构件。正确做法是先判断最上层的根物体是否满足条件不满足就整个跳过子物体不用管。另一个容易遗漏的是场景里某些物体挂了一个名为 DoNotExport 的自定义脚本这种情况用 Tag 或名字判断都行但记得在导出日志里把这些跳过的物体列出来方便二次确认。6. 进阶验证把导出的 OBJ 拿回引擎做差异对比与自动化校验前面讲的都是怎么导这一章说怎么验证导得到底对不对。手动在 Blender 里打开 OBJ 看几眼能解决 80% 的问题但大型项目里还得有一套自动化的校验逻辑否则每次改动场景后都要人工去盯效率太低。我从实际项目里提炼出一个惯用的验证套路供你参考。先做一个最小验证工具在 Unity 里写一个 Editor 脚本读取导出的 OBJ 文件把顶点和三角面解析回 Mesh并和当前场景里的原始 Mesh 做顶点数量和包围盒对比。这个对比只能在几何级别做粗略匹配因为顶点顺序可能因为坐标转换而被重新排列但顶点数量和包围盒尺寸应该是同一个量级的。匹配逻辑大致是var exportedMesh ObjParser.LoadFromFile(Exported/test.obj); var originBounds GetActiveSceneBounds(); var exportedBounds exportedMesh.bounds; float sizeDelta Vector3.Distance(originBounds.size, exportedBounds.size); if (sizeDelta 0.01f) { Debug.LogError($Export validation failed: bounds size mismatch by {sizeDelta}); } else { Debug.Log($Export validation passed: bounds {exportedBounds.size}, tris {exportedMesh.triangles.Length / 3}); }从做过这一整套流程之后我对 Unity 导出的信心来源不再是看着差不多而是每次模型结构变更后跑一遍这个脚本确认顶点数量和包围盒没有偏差。尤其是地形这种动辄几万顶点的物体肉眼根本无法判断采样是否齐全包围盒一对比就知道有没有丢区块。我现在的习惯是任何一次导出配置变更比如 terrainStep 从 4 改到 2都强制走一遍Unity 原始场景 → OBJ → 解析回 Mesh → 对比包围盒的验证流程。这个习惯救了我很多次——有一回我把 terrainStep 误设成 0代码直接死循环程序集编译不过幸好验证脚本在 CI 里先报了错没把坏配置流到美术同事那边。希望这套验证思路能帮你在自己的项目里少走这些弯路导出这件事算是所有工具链里最容易出幺蛾子的一环。本文还有配套的精品资源点击获取