1. 从改个模型要开三个软件说起Modeling Mode 到底解决了谁的痛点如果你做过 UE5 的场景搭建或者原型制作大概率经历过这种憋屈美术给了一个 FBX你只是想把它拉长一点、挖个洞、或者把几个静态网格拼成一个整体结果流程是——导出到 DCC 软件、改完、再导回来、重新指定材质、重新摆位置。一个五分钟的活硬生生拖成半小时。更别提那些需要反复迭代的关卡白模改一次导一次人都麻了。UE5 的Modeling Mode就是冲着这个痛点来的。它把一整套网格编辑工具直接塞进了引擎编辑器里让你在视口里就能对静态网格做拉伸、挤出、布尔、雕刻、简化、UV 调整这些操作。而Geometry Script则是把这套能力进一步开放成了蓝图和 Python 可调用的 API意味着你可以用程序化的方式批量处理网格、生成程序化内容、甚至做运行时Runtime的动态网格编辑。这篇内容我打算按一个实际使用者的视角来拆不搞官方文档那种功能罗列。我会讲清楚三件事Modeling Mode 的工具集到底怎么用、动态网格编辑在什么场景下值得上、以及 Geometry Script 怎么和前面两者联动起来解决真实问题。适合已经会基本 UE5 操作、想往程序化建模和工具链方向走的同学也适合被改模型这件事折磨过的场景美术和 TA。先说一个反直觉的结论Modeling Mode 不是用来替代 Blender 或 Maya 的它的定位是引擎内的快速迭代工具。你指望用它做高精度角色建模那肯定失望但你要做关卡白模、程序化道具、快速变体、碰撞体生成它比来回导模型高效太多。理解这个边界后面的工具选型和使用方式才不会跑偏。2. Modeling Mode 工具集的真实能力边界2.1 工具分类与各自的适用场景打开 Modeling Mode 之后左侧面板会列出一大堆工具第一次看确实容易懵。我按实际使用频率和用途把它们归成几类这样你找工具的时候心里有数。工具类别代表工具典型用途是否常用形状创建Box、Cylinder、Sphere、PolyExt快速搭白模、占位体高频网格编辑Extrude、Inset、Bevel、Loop Cut局部结构调整高频布尔运算Boolean、Mesh Bool挖洞、合并、切割高频变形类Displace、Smooth、Lattice整体形变、表面起伏中频属性处理Simplify、Remesh、Project减面、重拓扑、投射中频UV 与材质UV Editor、Auto UVUV 展开与调整中频碰撞与转换Collision、Convert生成碰撞、静态网格转换高频这里要重点说一个很多人忽略的点Modeling Mode 里的操作默认是非破坏性的但一旦你点了 Accept改动就写进网格数据了。也就是说它不像 Houdini 那样有完整的节点历史可以回溯。所以我的习惯是对重要资产先复制一份再动手或者干脆在单独的测试关卡里改改满意了再应用到正式资产上。2.2 布尔运算最香也最容易翻车的工具布尔运算绝对是 Modeling Mode 里使用率最高的功能之一。挖个门洞、切个斜面、把几个零件合并成一个整体几秒钟的事。但它也是最容易出问题的。翻车的典型表现是布尔之后网格出现破面、法线翻转、或者面数暴涨。原因通常有两个——参与布尔的网格本身有非流形几何non-manifold或者两个网格的相交区域太复杂。我的实操经验是这样的做布尔之前先用 Remesh 工具把参与运算的网格处理一下让面分布均匀一些。如果只是简单的挖洞用 Mesh Bool 的减法模式并且勾选上尝试修复结果。如果结果还是有问题把布尔后的网格丢进 Simplify 降一下面数很多时候破面会在简化过程中被合并掉。提示布尔运算对网格的水密性watertight有要求。如果你的网格有开放边界布尔结果大概率会出问题。可以用 Modeling Mode 里的Fill Holes工具先补洞。2.3 动态网格编辑什么时候值得上动态网格这个词听起来很唬人其实核心就一句话网格的顶点数据可以在运行时被修改。UE5 里对应的概念是 Dynamic MeshUDynamicMeshComponent和 Dynamic Mesh Actor。那什么时候你需要运行时改网格我列几个真实场景程序化生成内容比如一个 Roguelike 游戏每次进房间地形都不一样需要运行时生成网格。玩家驱动的形变比如捏脸系统、可破坏场景、切割物体。工具链自动化编辑器里批量处理几百个网格用 Geometry Script 写个脚本一键跑完。如果你的需求只是编辑器里改改模型那用 Modeling Mode 手动操作就够了没必要上动态网格。动态网格的价值在于程序化和运行时这一点一定要分清楚否则容易过度设计。动态网格的性能开销是实打实的。每次修改顶点数据都涉及 CPU 到 GPU 的数据传输频繁修改会掉帧。所以我的建议是能预计算的就预计算运行时只做必要的增量修改。比如程序化地形可以分块生成只更新玩家附近的那几块。3. Geometry Script 与 Modeling Mode 的联动逻辑3.1 Geometry Script 是什么和 Modeling Mode 什么关系很多人搞不清这两者的关系。简单说Modeling Mode 是 Geometry Script 的图形界面版。你在 Modeling Mode 里点的每一个按钮底层调用的都是 Geometry Script 的函数。反过来说Geometry Script 能做的事比 Modeling Mode 面板上暴露出来的多得多。Geometry Script 提供了一套蓝图节点和 Python API核心函数库包括AppendBox、AppendSphere等基础形状生成ApplyMeshBoolean布尔运算ApplyMeshExtrude、ApplyMeshOffset等编辑操作RecomputeNormals、RecomputeUVs属性重算CopyMeshToMesh、SetDynamicMesh数据流转在蓝图里你通过Dynamic Mesh Component或者Dynamic Mesh Actor来承载这些操作。一个典型的流程是创建一个 Dynamic Mesh用 Geometry Script 生成或加载网格数据做一系列编辑最后输出到 Static Mesh 或者直接渲染。3.2 一个完整的联动案例批量生成带碰撞的台阶我拿一个实际做过的东西举例。需求是给一个关卡快速生成一组参数化的台阶每级台阶高度和宽度可调并且自动生成碰撞。手动做的话就是复制粘贴一堆 Box然后一个个调位置再手动加碰撞。用 Geometry Script 的话写一个函数就能搞定而且改参数立刻重新生成。核心逻辑分三步用循环生成每一级台阶的 Box通过AppendBox累加到一个 Dynamic Mesh 上每级的位置按高度递增。对合并后的网格调用RecomputeNormals保证法线正确。把 Dynamic Mesh 输出为 Static Mesh并在输出时勾选生成简单碰撞。这里有个细节AppendBox 生成的 Box 默认是独立的面片集合直接合并会有内部面。如果台阶之间是紧贴的内部面看不见但会增加面数。可以在合并后用ApplyMeshBoolean的并集模式处理一下或者干脆接受这点开销——对于台阶这种简单几何多出来的面可以忽略。3.3 蓝图节点 vs Python 脚本怎么选Geometry Script 同时支持蓝图和 Python选哪个取决于你的使用场景。维度蓝图Python上手难度低可视化连线需要编程基础编辑器批处理不方便非常适合运行时逻辑适合不推荐调试便利性直观需要打日志复用性中等高我的实际用法是运行时逻辑用蓝图编辑器批处理用 Python。比如批量给一个文件夹里的所有静态网格生成碰撞、批量简化面数、批量重算 UV这些用 Python 写个脚本挂在编辑器工具里一键跑完几百个资产效率比手动高几个数量级。Python 脚本的入口通常是 Editor Utility Widget 或者 Editor Utility Blueprint里面调用unreal.GeometryScriptLibrary下的函数。注意 Python 里的函数名和蓝图节点名不完全一样需要查一下 API 文档对应关系。4. 动态网格编辑的实战踩坑记录4.1 碰撞体不更新一个查了半天的坑这个坑我印象很深。当时做了一个运行时可切割的物体用 Dynamic Mesh 在运行时修改顶点。切割逻辑跑通了视觉上没问题但玩家角色走过去直接穿模——碰撞体还是原来的。排查过程是这样的先确认 Dynamic Mesh Component 的碰撞设置发现SetCollisionEnabled是开的。然后怀疑是碰撞数据没跟着网格更新。查了文档才明白Dynamic Mesh 修改后需要手动调用碰撞重建蓝图里对应的是UpdateCollision或者重新设置碰撞数据。具体做法是每次修改完网格调用一次碰撞更新函数。如果用的是简单碰撞盒体、球体需要重新计算包围盒如果用的是复杂碰撞凸包分解开销会大一些建议只在必要时更新。注意运行时频繁重建复杂碰撞非常耗性能。如果物体形状变化不大可以考虑用简单碰撞近似或者只在形变结束后更新一次。4.2 顶点数暴涨导致卡顿另一个常见问题是用 Geometry Script 做布尔或者细分操作时顶点数会失控。我做过一个测试一个简单的立方体做几次布尔之后面数从 12 涨到了几千。如果这个操作在运行时每帧执行帧率直接崩。解决办法有几个方向控制操作频率不要每帧都改网格用事件驱动只在必要时更新。及时简化操作完成后调用ApplySimplify降面把不必要的小面合并掉。分块处理大网格拆成多个小块只更新变化的部分。LOD 策略远处用低模近处才用高模。这里有个经验值可以参考单个 Dynamic Mesh 的三角面数控制在 5000 以内比较稳妥超过这个数在移动端就会明显吃力。桌面端可以放宽到几万但也要看同屏数量。4.3 多播委托在网格更新通知里的用法热词里提到了ue5多播委托这个在动态网格场景里确实用得上。场景是这样的多个系统需要知道网格什么时候被修改了——比如碰撞系统要重建碰撞、UI 要更新面数显示、存档系统要记录变化。这时候用多播委托Multicast Delegate就很合适。在 Dynamic Mesh Actor 里定义一个OnMeshUpdated的多播委托网格修改完成后广播一次所有订阅者各自响应。这样各个系统解耦不用互相直接引用。蓝图里创建多播委托的步骤是在 Actor 蓝图里添加一个 Event Dispatcher命名比如OnMeshUpdated然后在修改网格的函数末尾调用Call OnMeshUpdated。其他蓝图通过 Bind Event 节点订阅。这个模式在工具链开发里非常实用值得掌握。5. 把 Modeling Mode 用出效率的几个习惯5.1 快捷键与视口操作Modeling Mode 有一堆快捷键用熟了效率翻倍。我列几个最常用的Shift 1到Shift 5快速切换选择模式顶点、边、面、物体E挤出Ctrl G打组F聚焦选中物体Alt 拖动复制这些在官方文档里都有但很多人不知道的是Modeling Mode 的很多工具支持实时预览——你调参数的时候视口里直接看到结果点 Accept 才真正应用。这个特性在做微调的时候特别有用可以反复试参数直到满意。5.2 用 PolyExt 快速搭白模PolyExtPolygon Extrusion是我用得最多的工具之一。它的逻辑是先画一个多边形轮廓然后挤出成体。搭关卡白模的时候用 PolyExt 画地面轮廓、墙体走向比一个个摆 Box 快得多。具体操作选择 PolyExt 工具在视口里点击放置顶点围成一个闭合形状然后拖动挤出高度。生成的网格可以直接用其他工具继续编辑。这个流程做建筑白模特别顺手画完轮廓挤出墙体再挖门窗洞一个建筑体块几分钟就出来了。5.3 资产命名与组织这个听起来是小事但踩过坑的人都知道痛。Modeling Mode 生成的资产默认命名很随意如果你批量做了几十个变体回头根本分不清哪个是哪个。我的习惯是在 Modeling Mode 里创建资产时立刻重命名用类型_用途_变体的格式比如SM_Wall_A、SM_Wall_B。另外把生成的资产统一放在一个文件夹里不要散落在各处。如果用了 Geometry Script 批量生成在脚本里就把命名规则写好省得后面手动整理。6. 程序化内容生成里 Geometry Script 的进阶玩法6.1 用极坐标思路做环形阵列热词里有ue5极坐标这个在程序化生成里确实是个好思路。比如你要生成一圈柱子、一圈栅栏、或者环形分布的装饰物用极坐标角度 半径来算位置比用笛卡尔坐标直观得多。在 Geometry Script 里逻辑是这样的循环角度从 0 到 360步长决定数量每个角度算出对应的 X、Y 坐标X 半径 * cos(角度)Y 半径 * sin(角度)然后在该位置 Append 一个柱子网格。半径和数量作为参数暴露出来改一下就能重新生成。这个模式可以扩展到很多场景环形楼梯、螺旋结构、放射状布局。核心就是把位置计算和网格生成分开位置用数学公式算网格用 Geometry Script 拼。6.2 网格合并与材质槽处理程序化生成的时候一个绕不开的问题是材质。多个网格合并成一个 Dynamic Mesh 之后材质槽怎么处理Geometry Script 里每个 Append 操作可以指定材质 ID。合并后的网格会保留多个材质槽你需要在输出为 Static Mesh 的时候确保材质槽正确对应。如果材质丢了检查一下是不是在 Append 的时候没设置材质 ID或者输出时材质数组没传对。我的做法是在生成阶段就用统一的材质 ID 规划比如 0 号槽是主体材质1 号槽是装饰材质。这样合并后不用再手动调整。如果确实需要动态指定材质可以在输出 Static Mesh 之后用SetMaterial节点按槽位设置。6.3 和 PCG 的配合UE5 的 PCGProcedural Content Generation框架和 Geometry Script 是可以配合的。PCG 负责在哪里放Geometry Script 负责放什么、怎么变形。比如一个森林场景PCG 根据地形和密度规则撒点每个点触发一次 Geometry Script 生成一棵随机变形的树——树干粗细、树枝角度、树冠形状都不同。这样出来的森林比单纯复制粘贴同一棵树自然得多。这个组合的复杂度不低建议先把 Geometry Script 单独跑通再接入 PCG。调试的时候可以先把 PCG 的点可视化出来确认位置对了再挂生成逻辑。7. 性能与兼容性那些文档不会明说的细节7.1 移动端的限制如果你做的是移动端项目动态网格编辑要格外小心。移动端 GPU 对动态顶点缓冲的支持有限频繁更新会导致严重的性能问题。我的建议是移动端尽量用预生成的静态网格运行时只做必要的简单变换。如果确实需要运行时形变控制顶点数在 2000 以内并且避免每帧更新。7.2 和 Nanite 的关系Nanite 是 UE5 的虚拟几何体系统它和动态网格的关系有点微妙。Nanite 主要针对静态的高面数网格而动态网格是运行时可变形的。目前 Nanite 对动态网格的支持有限动态网格通常走的是传统渲染路径。所以如果你的场景大量使用 Nanite动态网格部分要单独考虑性能预算。7.3 资产打包注意事项用 Geometry Script 在编辑器里生成的资产打包的时候要确保它们被正确引用。如果资产是运行时生成的那没问题如果是编辑器生成后保存的 Static Mesh要检查一下有没有被关卡或蓝图引用否则打包后可能丢失。我遇到过一次打包后模型不见了的情况排查发现是生成的资产放在了一个没有被任何关卡引用的文件夹里打包时被剔除了。解决办法是在打包设置里把这个文件夹加入Additional Asset Directories to Cook或者确保资产被某个蓝图硬引用。8. 我个人的使用体会Modeling Mode 和 Geometry Script 这套组合我用了大概一年多最大的感受是它改变了我对引擎内能做什么的预期。以前觉得引擎就是组装的地方建模必须去 DCC现在很多中小规模的模型需求在引擎里就能闭环解决。但它也不是银弹。复杂的有机模型、高精度的角色、需要精细 UV 和贴图的资产还是得回 DCC。我的工作流现在是白模和程序化内容在引擎里做精细资产在 DCC 里做两边通过 FBX 和 Datasmith 互通。这个分工目前来看是最顺手的。最后分享一个小技巧如果你经常用 Geometry Script 写重复逻辑把它封装成蓝图函数库或者 Python 模块别每次都重新连线。我一开始图省事每次现连后来发现同样的逻辑连了十几遍改成函数库之后效率高太多了。工具链这东西前期多花点时间搭好后面省的是成倍的时间。
UE5 Modeling Mode与Geometry Script：引擎内网格编辑与程序化建模实战
1. 从改个模型要开三个软件说起Modeling Mode 到底解决了谁的痛点如果你做过 UE5 的场景搭建或者原型制作大概率经历过这种憋屈美术给了一个 FBX你只是想把它拉长一点、挖个洞、或者把几个静态网格拼成一个整体结果流程是——导出到 DCC 软件、改完、再导回来、重新指定材质、重新摆位置。一个五分钟的活硬生生拖成半小时。更别提那些需要反复迭代的关卡白模改一次导一次人都麻了。UE5 的Modeling Mode就是冲着这个痛点来的。它把一整套网格编辑工具直接塞进了引擎编辑器里让你在视口里就能对静态网格做拉伸、挤出、布尔、雕刻、简化、UV 调整这些操作。而Geometry Script则是把这套能力进一步开放成了蓝图和 Python 可调用的 API意味着你可以用程序化的方式批量处理网格、生成程序化内容、甚至做运行时Runtime的动态网格编辑。这篇内容我打算按一个实际使用者的视角来拆不搞官方文档那种功能罗列。我会讲清楚三件事Modeling Mode 的工具集到底怎么用、动态网格编辑在什么场景下值得上、以及 Geometry Script 怎么和前面两者联动起来解决真实问题。适合已经会基本 UE5 操作、想往程序化建模和工具链方向走的同学也适合被改模型这件事折磨过的场景美术和 TA。先说一个反直觉的结论Modeling Mode 不是用来替代 Blender 或 Maya 的它的定位是引擎内的快速迭代工具。你指望用它做高精度角色建模那肯定失望但你要做关卡白模、程序化道具、快速变体、碰撞体生成它比来回导模型高效太多。理解这个边界后面的工具选型和使用方式才不会跑偏。2. Modeling Mode 工具集的真实能力边界2.1 工具分类与各自的适用场景打开 Modeling Mode 之后左侧面板会列出一大堆工具第一次看确实容易懵。我按实际使用频率和用途把它们归成几类这样你找工具的时候心里有数。工具类别代表工具典型用途是否常用形状创建Box、Cylinder、Sphere、PolyExt快速搭白模、占位体高频网格编辑Extrude、Inset、Bevel、Loop Cut局部结构调整高频布尔运算Boolean、Mesh Bool挖洞、合并、切割高频变形类Displace、Smooth、Lattice整体形变、表面起伏中频属性处理Simplify、Remesh、Project减面、重拓扑、投射中频UV 与材质UV Editor、Auto UVUV 展开与调整中频碰撞与转换Collision、Convert生成碰撞、静态网格转换高频这里要重点说一个很多人忽略的点Modeling Mode 里的操作默认是非破坏性的但一旦你点了 Accept改动就写进网格数据了。也就是说它不像 Houdini 那样有完整的节点历史可以回溯。所以我的习惯是对重要资产先复制一份再动手或者干脆在单独的测试关卡里改改满意了再应用到正式资产上。2.2 布尔运算最香也最容易翻车的工具布尔运算绝对是 Modeling Mode 里使用率最高的功能之一。挖个门洞、切个斜面、把几个零件合并成一个整体几秒钟的事。但它也是最容易出问题的。翻车的典型表现是布尔之后网格出现破面、法线翻转、或者面数暴涨。原因通常有两个——参与布尔的网格本身有非流形几何non-manifold或者两个网格的相交区域太复杂。我的实操经验是这样的做布尔之前先用 Remesh 工具把参与运算的网格处理一下让面分布均匀一些。如果只是简单的挖洞用 Mesh Bool 的减法模式并且勾选上尝试修复结果。如果结果还是有问题把布尔后的网格丢进 Simplify 降一下面数很多时候破面会在简化过程中被合并掉。提示布尔运算对网格的水密性watertight有要求。如果你的网格有开放边界布尔结果大概率会出问题。可以用 Modeling Mode 里的Fill Holes工具先补洞。2.3 动态网格编辑什么时候值得上动态网格这个词听起来很唬人其实核心就一句话网格的顶点数据可以在运行时被修改。UE5 里对应的概念是 Dynamic MeshUDynamicMeshComponent和 Dynamic Mesh Actor。那什么时候你需要运行时改网格我列几个真实场景程序化生成内容比如一个 Roguelike 游戏每次进房间地形都不一样需要运行时生成网格。玩家驱动的形变比如捏脸系统、可破坏场景、切割物体。工具链自动化编辑器里批量处理几百个网格用 Geometry Script 写个脚本一键跑完。如果你的需求只是编辑器里改改模型那用 Modeling Mode 手动操作就够了没必要上动态网格。动态网格的价值在于程序化和运行时这一点一定要分清楚否则容易过度设计。动态网格的性能开销是实打实的。每次修改顶点数据都涉及 CPU 到 GPU 的数据传输频繁修改会掉帧。所以我的建议是能预计算的就预计算运行时只做必要的增量修改。比如程序化地形可以分块生成只更新玩家附近的那几块。3. Geometry Script 与 Modeling Mode 的联动逻辑3.1 Geometry Script 是什么和 Modeling Mode 什么关系很多人搞不清这两者的关系。简单说Modeling Mode 是 Geometry Script 的图形界面版。你在 Modeling Mode 里点的每一个按钮底层调用的都是 Geometry Script 的函数。反过来说Geometry Script 能做的事比 Modeling Mode 面板上暴露出来的多得多。Geometry Script 提供了一套蓝图节点和 Python API核心函数库包括AppendBox、AppendSphere等基础形状生成ApplyMeshBoolean布尔运算ApplyMeshExtrude、ApplyMeshOffset等编辑操作RecomputeNormals、RecomputeUVs属性重算CopyMeshToMesh、SetDynamicMesh数据流转在蓝图里你通过Dynamic Mesh Component或者Dynamic Mesh Actor来承载这些操作。一个典型的流程是创建一个 Dynamic Mesh用 Geometry Script 生成或加载网格数据做一系列编辑最后输出到 Static Mesh 或者直接渲染。3.2 一个完整的联动案例批量生成带碰撞的台阶我拿一个实际做过的东西举例。需求是给一个关卡快速生成一组参数化的台阶每级台阶高度和宽度可调并且自动生成碰撞。手动做的话就是复制粘贴一堆 Box然后一个个调位置再手动加碰撞。用 Geometry Script 的话写一个函数就能搞定而且改参数立刻重新生成。核心逻辑分三步用循环生成每一级台阶的 Box通过AppendBox累加到一个 Dynamic Mesh 上每级的位置按高度递增。对合并后的网格调用RecomputeNormals保证法线正确。把 Dynamic Mesh 输出为 Static Mesh并在输出时勾选生成简单碰撞。这里有个细节AppendBox 生成的 Box 默认是独立的面片集合直接合并会有内部面。如果台阶之间是紧贴的内部面看不见但会增加面数。可以在合并后用ApplyMeshBoolean的并集模式处理一下或者干脆接受这点开销——对于台阶这种简单几何多出来的面可以忽略。3.3 蓝图节点 vs Python 脚本怎么选Geometry Script 同时支持蓝图和 Python选哪个取决于你的使用场景。维度蓝图Python上手难度低可视化连线需要编程基础编辑器批处理不方便非常适合运行时逻辑适合不推荐调试便利性直观需要打日志复用性中等高我的实际用法是运行时逻辑用蓝图编辑器批处理用 Python。比如批量给一个文件夹里的所有静态网格生成碰撞、批量简化面数、批量重算 UV这些用 Python 写个脚本挂在编辑器工具里一键跑完几百个资产效率比手动高几个数量级。Python 脚本的入口通常是 Editor Utility Widget 或者 Editor Utility Blueprint里面调用unreal.GeometryScriptLibrary下的函数。注意 Python 里的函数名和蓝图节点名不完全一样需要查一下 API 文档对应关系。4. 动态网格编辑的实战踩坑记录4.1 碰撞体不更新一个查了半天的坑这个坑我印象很深。当时做了一个运行时可切割的物体用 Dynamic Mesh 在运行时修改顶点。切割逻辑跑通了视觉上没问题但玩家角色走过去直接穿模——碰撞体还是原来的。排查过程是这样的先确认 Dynamic Mesh Component 的碰撞设置发现SetCollisionEnabled是开的。然后怀疑是碰撞数据没跟着网格更新。查了文档才明白Dynamic Mesh 修改后需要手动调用碰撞重建蓝图里对应的是UpdateCollision或者重新设置碰撞数据。具体做法是每次修改完网格调用一次碰撞更新函数。如果用的是简单碰撞盒体、球体需要重新计算包围盒如果用的是复杂碰撞凸包分解开销会大一些建议只在必要时更新。注意运行时频繁重建复杂碰撞非常耗性能。如果物体形状变化不大可以考虑用简单碰撞近似或者只在形变结束后更新一次。4.2 顶点数暴涨导致卡顿另一个常见问题是用 Geometry Script 做布尔或者细分操作时顶点数会失控。我做过一个测试一个简单的立方体做几次布尔之后面数从 12 涨到了几千。如果这个操作在运行时每帧执行帧率直接崩。解决办法有几个方向控制操作频率不要每帧都改网格用事件驱动只在必要时更新。及时简化操作完成后调用ApplySimplify降面把不必要的小面合并掉。分块处理大网格拆成多个小块只更新变化的部分。LOD 策略远处用低模近处才用高模。这里有个经验值可以参考单个 Dynamic Mesh 的三角面数控制在 5000 以内比较稳妥超过这个数在移动端就会明显吃力。桌面端可以放宽到几万但也要看同屏数量。4.3 多播委托在网格更新通知里的用法热词里提到了ue5多播委托这个在动态网格场景里确实用得上。场景是这样的多个系统需要知道网格什么时候被修改了——比如碰撞系统要重建碰撞、UI 要更新面数显示、存档系统要记录变化。这时候用多播委托Multicast Delegate就很合适。在 Dynamic Mesh Actor 里定义一个OnMeshUpdated的多播委托网格修改完成后广播一次所有订阅者各自响应。这样各个系统解耦不用互相直接引用。蓝图里创建多播委托的步骤是在 Actor 蓝图里添加一个 Event Dispatcher命名比如OnMeshUpdated然后在修改网格的函数末尾调用Call OnMeshUpdated。其他蓝图通过 Bind Event 节点订阅。这个模式在工具链开发里非常实用值得掌握。5. 把 Modeling Mode 用出效率的几个习惯5.1 快捷键与视口操作Modeling Mode 有一堆快捷键用熟了效率翻倍。我列几个最常用的Shift 1到Shift 5快速切换选择模式顶点、边、面、物体E挤出Ctrl G打组F聚焦选中物体Alt 拖动复制这些在官方文档里都有但很多人不知道的是Modeling Mode 的很多工具支持实时预览——你调参数的时候视口里直接看到结果点 Accept 才真正应用。这个特性在做微调的时候特别有用可以反复试参数直到满意。5.2 用 PolyExt 快速搭白模PolyExtPolygon Extrusion是我用得最多的工具之一。它的逻辑是先画一个多边形轮廓然后挤出成体。搭关卡白模的时候用 PolyExt 画地面轮廓、墙体走向比一个个摆 Box 快得多。具体操作选择 PolyExt 工具在视口里点击放置顶点围成一个闭合形状然后拖动挤出高度。生成的网格可以直接用其他工具继续编辑。这个流程做建筑白模特别顺手画完轮廓挤出墙体再挖门窗洞一个建筑体块几分钟就出来了。5.3 资产命名与组织这个听起来是小事但踩过坑的人都知道痛。Modeling Mode 生成的资产默认命名很随意如果你批量做了几十个变体回头根本分不清哪个是哪个。我的习惯是在 Modeling Mode 里创建资产时立刻重命名用类型_用途_变体的格式比如SM_Wall_A、SM_Wall_B。另外把生成的资产统一放在一个文件夹里不要散落在各处。如果用了 Geometry Script 批量生成在脚本里就把命名规则写好省得后面手动整理。6. 程序化内容生成里 Geometry Script 的进阶玩法6.1 用极坐标思路做环形阵列热词里有ue5极坐标这个在程序化生成里确实是个好思路。比如你要生成一圈柱子、一圈栅栏、或者环形分布的装饰物用极坐标角度 半径来算位置比用笛卡尔坐标直观得多。在 Geometry Script 里逻辑是这样的循环角度从 0 到 360步长决定数量每个角度算出对应的 X、Y 坐标X 半径 * cos(角度)Y 半径 * sin(角度)然后在该位置 Append 一个柱子网格。半径和数量作为参数暴露出来改一下就能重新生成。这个模式可以扩展到很多场景环形楼梯、螺旋结构、放射状布局。核心就是把位置计算和网格生成分开位置用数学公式算网格用 Geometry Script 拼。6.2 网格合并与材质槽处理程序化生成的时候一个绕不开的问题是材质。多个网格合并成一个 Dynamic Mesh 之后材质槽怎么处理Geometry Script 里每个 Append 操作可以指定材质 ID。合并后的网格会保留多个材质槽你需要在输出为 Static Mesh 的时候确保材质槽正确对应。如果材质丢了检查一下是不是在 Append 的时候没设置材质 ID或者输出时材质数组没传对。我的做法是在生成阶段就用统一的材质 ID 规划比如 0 号槽是主体材质1 号槽是装饰材质。这样合并后不用再手动调整。如果确实需要动态指定材质可以在输出 Static Mesh 之后用SetMaterial节点按槽位设置。6.3 和 PCG 的配合UE5 的 PCGProcedural Content Generation框架和 Geometry Script 是可以配合的。PCG 负责在哪里放Geometry Script 负责放什么、怎么变形。比如一个森林场景PCG 根据地形和密度规则撒点每个点触发一次 Geometry Script 生成一棵随机变形的树——树干粗细、树枝角度、树冠形状都不同。这样出来的森林比单纯复制粘贴同一棵树自然得多。这个组合的复杂度不低建议先把 Geometry Script 单独跑通再接入 PCG。调试的时候可以先把 PCG 的点可视化出来确认位置对了再挂生成逻辑。7. 性能与兼容性那些文档不会明说的细节7.1 移动端的限制如果你做的是移动端项目动态网格编辑要格外小心。移动端 GPU 对动态顶点缓冲的支持有限频繁更新会导致严重的性能问题。我的建议是移动端尽量用预生成的静态网格运行时只做必要的简单变换。如果确实需要运行时形变控制顶点数在 2000 以内并且避免每帧更新。7.2 和 Nanite 的关系Nanite 是 UE5 的虚拟几何体系统它和动态网格的关系有点微妙。Nanite 主要针对静态的高面数网格而动态网格是运行时可变形的。目前 Nanite 对动态网格的支持有限动态网格通常走的是传统渲染路径。所以如果你的场景大量使用 Nanite动态网格部分要单独考虑性能预算。7.3 资产打包注意事项用 Geometry Script 在编辑器里生成的资产打包的时候要确保它们被正确引用。如果资产是运行时生成的那没问题如果是编辑器生成后保存的 Static Mesh要检查一下有没有被关卡或蓝图引用否则打包后可能丢失。我遇到过一次打包后模型不见了的情况排查发现是生成的资产放在了一个没有被任何关卡引用的文件夹里打包时被剔除了。解决办法是在打包设置里把这个文件夹加入Additional Asset Directories to Cook或者确保资产被某个蓝图硬引用。8. 我个人的使用体会Modeling Mode 和 Geometry Script 这套组合我用了大概一年多最大的感受是它改变了我对引擎内能做什么的预期。以前觉得引擎就是组装的地方建模必须去 DCC现在很多中小规模的模型需求在引擎里就能闭环解决。但它也不是银弹。复杂的有机模型、高精度的角色、需要精细 UV 和贴图的资产还是得回 DCC。我的工作流现在是白模和程序化内容在引擎里做精细资产在 DCC 里做两边通过 FBX 和 Datasmith 互通。这个分工目前来看是最顺手的。最后分享一个小技巧如果你经常用 Geometry Script 写重复逻辑把它封装成蓝图函数库或者 Python 模块别每次都重新连线。我一开始图省事每次现连后来发现同样的逻辑连了十几遍改成函数库之后效率高太多了。工具链这东西前期多花点时间搭好后面省的是成倍的时间。
