1. 从“能跑就行”到“几何可控”GeometryCore 到底在解决什么问题如果你在 UE5 里做过程序化建模、动态切割、地形雕刻或者运行时网格变形大概率经历过这样的场景蓝图里拖了一堆 ProceduralMeshComponent 节点跑起来帧率直接腰斩想对 StaticMesh 做布尔运算发现引擎自带的工具要么在编辑器里才能用要么精度一塌糊涂好不容易用第三方库生成了顶点数据往渲染管线里塞的时候又卡在法线、切线、UV 的重算上。GeometryCore 就是在这个背景下进入视野的。它不是某个单一功能而是 UE5 内部一套完整的几何处理引擎核心围绕FDynamicMesh3这个动态网格数据结构展开。你可以把它理解成一个“网格操作系统”——顶点、边、三角形、属性层、空间查询、布尔运算、简化、细分、重映射这些操作在 GeometryCore 里都有对应的模块和算法实现。我第一次认真翻 GeometryCore 的源码是因为一个需求在运行时对角色装备进行实时切割切面要平滑、UV 要正确、法线要重算、切割后的碎片还要能独立参与物理模拟。用 ProceduralMeshComponent 试了一版顶点数一多就崩UV 接缝处全是拉伸。后来转到FDynamicMesh3FDynamicMeshComponent这套组合才真正把效果稳住。这篇文章面向的是已经在 UE5 里做过一定网格操作、但还没系统用过 GeometryCore 的开发者。我会从FDynamicMesh3的数据组织方式讲起拆解 Mesh 操作的核心 API补充实际项目里踩过的坑最后给出几个可以直接抄的代码片段。不会涉及引擎编译层面的东西重点放在“怎么用”和“为什么这么用”上。提示GeometryCore 模块在 UE5 中默认是启用的但部分功能如布尔运算、Remesh依赖 GeometryScripting 或 MeshModelingToolset 插件需要在 .uproject 或插件面板中手动开启。2. FDynamicMesh3 的数据组织为什么它比 ProceduralMesh 更适合动态操作2.1 顶点-边-三角形三层索引结构FDynamicMesh3最核心的设计是它同时维护了顶点数组、边数组和三角形数组并且三者之间通过索引互相引用。这和 ProceduralMeshComponent 只维护顶点和三角形索引的做法有本质区别。在 ProceduralMesh 里你给一组顶点和三角形索引它就直接往渲染缓冲里塞。顶点之间有没有共享边、哪些三角形邻接、某条边属于哪两个面这些信息全靠你自己算。一旦要做局部操作——比如删除一个三角形后修补孔洞、或者沿着一条边做细分——你就得遍历整个索引数组去重建拓扑关系。FDynamicMesh3在插入三角形时会自动建立边表。每条边记录两个端点顶点 ID 和相邻的两个三角形 ID边界边只有一个相邻三角形。这个边表是后续所有拓扑操作的基础。比如GetEdgeOppositeVertex、GetTriangleEdges、GetVtxEdges这些查询底层都是直接查边表不需要遍历。// 创建一个动态网格并插入一个三角形 FDynamicMesh3 Mesh; int32 V0 Mesh.AppendVertex(FVector3d(0, 0, 0)); int32 V1 Mesh.AppendVertex(FVector3d(100, 0, 0)); int32 V2 Mesh.AppendVertex(FVector3d(0, 100, 0)); int32 T0 Mesh.AppendTriangle(V0, V1, V2); // 查询三角形的三条边 FIndex3i Edges Mesh.GetTriangleEdges(T0); // 查询某条边的两个相邻三角形 FIndex2i Tris Mesh.GetEdgeT(Edges.A);这段代码看起来简单但背后发生的事不少AppendTriangle会检查三条边是否已存在不存在就创建新边并记录邻接关系存在就更新边的邻接三角形列表。这个自动维护机制让后续的CollapseEdge、SplitEdge、FlipEdge等操作变得非常直接。2.2 属性层与重叠顶点UV 接缝和硬边的处理逻辑FDynamicMesh3的另一个关键设计是属性层Attribute Layer和重叠顶点Overlay Vertex的概念。在渲染网格里一个位置上的顶点可能因为 UV 接缝或硬边法线而需要拆分成多个渲染顶点。ProceduralMesh 的做法是让你直接提供拆分后的顶点数组而FDynamicMesh3用属性层来管理这种拆分。具体来说FDynamicMesh3的顶点位置是唯一的但每个三角形可以引用不同的 UV 和法线属性。当需要拆分时通过SplitVertex或属性层的AppendElement来创建重叠顶点。这样做的好处是拓扑操作始终在唯一的顶点集合上进行不会因为 UV 接缝导致拓扑断裂。我踩过的一个坑早期直接用FDynamicMesh3的顶点位置去算邻接关系忽略了属性层拆分结果在做平滑操作时接缝处的顶点被当成两个独立顶点处理平滑后接缝裂开。后来改用FDynamicMesh3::GetVtxConnectedTriangles配合属性层的GetParentVertex来统一处理才解决这个问题。2.3 与渲染管线的对接FDynamicMeshComponent 的角色FDynamicMesh3本身只是数据容器要渲染出来需要FDynamicMeshComponent或UDynamicMeshComponent。这个组件负责把FDynamicMesh3的数据转换成渲染线程可用的缓冲。和 ProceduralMeshComponent 不同FDynamicMeshComponent支持增量更新——你修改了网格的某一部分它只重建受影响区域的缓冲而不是整个网格。这个增量更新机制在频繁修改网格的场景下非常关键。我实测过一个 5 万面的网格用 ProceduralMeshComponent 每次修改全量重建需要 8-12ms而FDynamicMeshComponent的增量更新可以压到 1-3ms。差距主要来自它内部的FDynamicMeshChangeTracker和渲染缓冲的局部更新逻辑。注意FDynamicMeshComponent的增量更新需要你通过EditMesh或ApplyChange接口来修改网格直接操作FDynamicMesh3的底层数组不会触发增量更新会导致渲染不同步。3. Mesh 操作的核心 API从布尔运算到 Remesh 的实战拆解3.1 布尔运算MeshBoolean 的输入输出与精度控制GeometryCore 的布尔运算实现在MeshBoolean命名空间下支持并集、交集、差集三种操作。输入是两个FDynamicMesh3输出是结果网格。和编辑器里的布尔工具不同这套 API 可以在运行时调用而且对非流形网格有一定的容错能力。#include MeshBoolean.h FDynamicMesh3 MeshA, MeshB; // ... 填充两个网格 ... FGeometryResult Result; MeshBoolean::ComputeBoolean( MeshA, MeshB, MeshBoolean::EBooleanOperation::Difference, Result ); if (Result.HasResult()) { FDynamicMesh3 OutputMesh Result.GetResultMesh(); // 处理输出网格 }布尔运算的精度控制主要通过FMeshBooleanOptions来设置。关键参数包括SnapTolerance顶点吸附容差和WindingThreshold环绕数阈值。SnapTolerance决定了多近的顶点会被合并设得太小会导致布尔结果出现裂缝设得太大又会把本该分开的细节粘在一起。我的经验值是取网格平均边长的 0.1%-1%具体要看模型尺度。WindingThreshold控制的是内外判定。对于封闭网格0.5 是标准值对于有开口的网格可能需要调低到 0.3 左右才能得到合理结果。这个参数在差集运算中尤其敏感设错了会出现“该挖掉的面没挖掉”或者“挖过头”的情况。3.2 网格简化与重网格化Reduce 和 Remesh 的适用场景网格简化FMeshSimplification和重网格化FRemesher是两个容易混淆的操作。简化是在保留原始拓扑结构的前提下减少三角形数量适合 LOD 生成重网格化是重新生成一套均匀的拓扑适合修复扫描数据或做均匀细分。FMeshSimplification的核心参数是TargetTriangleCount和EdgeLengthThreshold。前者是目标三角形数后者控制边长的最小阈值——低于这个值的边不会被折叠。实际用的时候我一般先设TargetTriangleCount为目标值的 1.1 倍然后让EdgeLengthThreshold自动计算这样能在保证简化率的同时避免过度折叠导致形状失真。FMeshSimplification Simplifier; Simplifier.TargetTriangleCount 5000; Simplifier.EdgeLengthThreshold 0.01; Simplifier.Simplify(Mesh);FRemesher的用法更复杂一些需要设置目标边长TargetEdgeLength和迭代次数。它的优势是能生成质量更高的三角形分布但计算量比简化大得多。我一般只在离线处理或加载阶段用 Remesh运行时还是以简化为主。3.3 空间查询与碰撞MeshAABBTree 和 MeshSpatial 的配合GeometryCore 提供了MeshAABBTree3和MeshSpatial3两套空间查询结构。MeshAABBTree3基于 AABB 树做射线检测和最近点查询MeshSpatial3基于哈希网格做范围查询和邻域搜索。MeshAABBTree3的典型用法是射线检测MeshAABBTree3 Spatial(Mesh, true); FRay3d Ray(Origin, Direction); int32 HitTriangleID; double HitDistance; if (Spatial.FindNearestHitTriangle(Ray, HitDistance, HitTriangleID)) { FVector3d HitPoint Ray.PointAt(HitDistance); // 处理命中 }MeshSpatial3更适合做“找出某点周围 N 米内的所有三角形”这类查询。它的构建成本比 AABB 树高但范围查询效率更好。在实际项目里我通常两个都建AABB 树用于精确射线检测Spatial 用于粗筛和邻域操作。提示MeshAABBTree3的构建是惰性的第一次查询时才会真正构建。如果网格在构建后发生了修改需要调用Rebuild或重新创建实例否则查询结果会基于旧数据。4. 实际项目中的踩坑记录那些文档里不会写的问题4.1 顶点法线重算的时机与陷阱FDynamicMesh3在修改后不会自动重算法线。如果你删除了一个三角形相邻三角形的法线可能已经不对了但FDynamicMesh3不会主动更新。需要手动调用MeshNormals::ComputeVertexNormals或MeshNormals::ComputeOverlayNormals。这里有个坑ComputeVertexNormals会覆盖所有顶点的法线包括那些你手动设置过的硬边法线。如果网格里有硬边比如立方体的棱直接调用这个函数会把硬边平滑掉。正确的做法是用ComputeOverlayNormals它会尊重属性层的拆分只在同一平滑组内计算平均法线。我遇到过一个更隐蔽的问题在增量更新模式下如果只重算了部分区域的法线但渲染缓冲的更新范围没覆盖到相邻三角形会出现“法线接缝”——两个相邻三角形一个用了新法线一个用了旧法线光照下明显有一条亮线。解决办法是在修改后把受影响区域向外扩展一圈再重算法线。4.2 属性层索引错位UV 和法线不同步的排查过程属性层的索引管理是FDynamicMesh3里最容易出错的地方。每个属性层UV、法线、颜色都有自己的元素数组和索引映射。当你做SplitVertex或CollapseEdge时属性层的索引需要同步更新否则会出现 UV 错位或法线指向错误。我排查过一个 UV 错位问题现象是切割后的网格大部分 UV 正常但切面附近的 UV 全部挤在一起。排查过程是这样的先确认切割算法本身没有修改 UV 数据——用Mesh.GetUVLayer打印切割前后的 UV 值发现切面附近的 UV 确实变了。检查SplitVertex的调用——发现切割时对切面顶点调用了SplitVertex但没有同步调用属性层的SplitElement。修复方案是在SplitVertex后手动调用AttributeLayer-SplitElement把原顶点的 UV 复制到新顶点上。这个问题的根因是FDynamicMesh3的SplitVertex只处理拓扑层面的拆分属性层的拆分需要单独处理。文档里没有明确说明这一点我是翻了源码才确认的。4.3 大网格操作的性能瓶颈与分块策略FDynamicMesh3虽然比 ProceduralMesh 高效但面对十万面以上的网格单次全量操作仍然可能卡顿。我做过一个测试对 20 万面的网格做一次布尔差集耗时约 450ms其中大部分时间花在 AABB 树的构建和三角形相交测试上。优化策略是分块处理。把大网格按空间位置切成若干块每块单独建 AABB 树布尔运算时只处理与切割体相交的块。这样能把单次操作时间压到 50ms 以内。代价是需要维护块之间的边界一致性切割后要处理跨块的裂缝。另一个优化点是延迟法线重算。如果连续做多次网格修改不要每次修改后都重算法线而是等所有修改完成后统一重算。我实测过连续 10 次修改后统一重算比每次修改后重算快 3-4 倍。5. 可复用的代码片段与配置建议5.1 运行时网格切割的最小实现下面是一个运行时切割的最小实现基于平面切割保留了切面的 UV 和法线#include DynamicMesh/DynamicMesh3.h #include MeshCutting.h void CutMeshWithPlane(FDynamicMesh3 Mesh, const FPlane3d Plane) { FMeshPlaneCut Cutter(Mesh, Plane); Cutter.Cut(); // 重算切面法线 MeshNormals::ComputeOverlayNormals(Mesh); // 更新渲染 if (FDynamicMeshComponent* Comp GetComponent()) { Comp-EditMesh([](FDynamicMesh3 EditMesh) { EditMesh MoveTemp(Mesh); }); } }这段代码的关键点是FMeshPlaneCut会自动处理切面的三角形重建和属性层拆分。但切面的 UV 需要你手动指定——默认情况下它会用平面投影生成 UV如果需要保留原始 UV 的连续性需要在Cut之前设置UVLayer和投影参数。5.2 网格简化的参数配置表参数推荐值说明TargetTriangleCount原始面数的 10%-30%根据 LOD 级别调整EdgeLengthThreshold平均边长的 0.5-2 倍太小会导致过度折叠bPreserveBoundarytrue保留边界边避免开口变形bPreserveUVtrue保留 UV 接缝MaxIterations10-20迭代次数太多会变慢这个配置是我在多个项目里总结出来的适用于大多数角色和道具的 LOD 生成。地形类网格需要把EdgeLengthThreshold调大一些因为地形通常有大量细长三角形。5.3 空间查询的性能对比查询类型MeshAABBTree3MeshSpatial3射线检测快O(log n)慢最近点查询快中等范围查询中等快构建成本低高内存占用中等高动态更新需重建支持增量选择建议如果主要是射线检测和最近点查询用MeshAABBTree3如果需要频繁做范围查询和邻域操作用MeshSpatial3如果两者都需要可以同时建但要注意内存开销。6. 从 GeometryCore 延伸出去还能怎么玩FDynamicMesh3的能力远不止上面提到的这些。它还可以和 GeometryScripting 配合在蓝图里直接调用网格操作可以和 ModelingTools 配合做编辑器内的交互式建模可以和 Chaos 物理配合做实时破碎。我最近在尝试的一个方向是用FDynamicMesh3做运行时地形变形——玩家走过的地方地面凹陷爆炸后地面出现弹坑。核心思路是把地形网格转成FDynamicMesh3用MeshSpatial3做范围查询找出受影响区域然后对区域内的顶点做位移。这个方案比用高度图更灵活因为可以处理悬垂和洞穴结构。另一个方向是网格的 LOD 自动生成。用FMeshSimplification配合MeshAABBTree3做视距判断运行时动态切换不同精度的网格。这个方案在开放世界项目里很有价值能显著降低渲染开销。提示FDynamicMesh3的序列化格式和 StaticMesh 不同如果需要持久化保存建议用FDynamicMesh3::Serialize或导出为 OBJ/FBX。直接保存二进制数据在不同引擎版本间可能不兼容。最后分享一个调试技巧FDynamicMesh3提供了CheckValidity方法可以在每次操作后调用检查拓扑一致性。虽然会拖慢性能但在开发阶段能帮你快速定位问题。我一般在关键操作后加一个check(Mesh.CheckValidity())出问题时能第一时间发现。
1. 从“能跑就行”到“几何可控”GeometryCore 到底在解决什么问题如果你在 UE5 里做过程序化建模、动态切割、地形雕刻或者运行时网格变形大概率经历过这样的场景蓝图里拖了一堆 ProceduralMeshComponent 节点跑起来帧率直接腰斩想对 StaticMesh 做布尔运算发现引擎自带的工具要么在编辑器里才能用要么精度一塌糊涂好不容易用第三方库生成了顶点数据往渲染管线里塞的时候又卡在法线、切线、UV 的重算上。GeometryCore 就是在这个背景下进入视野的。它不是某个单一功能而是 UE5 内部一套完整的几何处理引擎核心围绕FDynamicMesh3这个动态网格数据结构展开。你可以把它理解成一个“网格操作系统”——顶点、边、三角形、属性层、空间查询、布尔运算、简化、细分、重映射这些操作在 GeometryCore 里都有对应的模块和算法实现。我第一次认真翻 GeometryCore 的源码是因为一个需求在运行时对角色装备进行实时切割切面要平滑、UV 要正确、法线要重算、切割后的碎片还要能独立参与物理模拟。用 ProceduralMeshComponent 试了一版顶点数一多就崩UV 接缝处全是拉伸。后来转到FDynamicMesh3FDynamicMeshComponent这套组合才真正把效果稳住。这篇文章面向的是已经在 UE5 里做过一定网格操作、但还没系统用过 GeometryCore 的开发者。我会从FDynamicMesh3的数据组织方式讲起拆解 Mesh 操作的核心 API补充实际项目里踩过的坑最后给出几个可以直接抄的代码片段。不会涉及引擎编译层面的东西重点放在“怎么用”和“为什么这么用”上。提示GeometryCore 模块在 UE5 中默认是启用的但部分功能如布尔运算、Remesh依赖 GeometryScripting 或 MeshModelingToolset 插件需要在 .uproject 或插件面板中手动开启。2. FDynamicMesh3 的数据组织为什么它比 ProceduralMesh 更适合动态操作2.1 顶点-边-三角形三层索引结构FDynamicMesh3最核心的设计是它同时维护了顶点数组、边数组和三角形数组并且三者之间通过索引互相引用。这和 ProceduralMeshComponent 只维护顶点和三角形索引的做法有本质区别。在 ProceduralMesh 里你给一组顶点和三角形索引它就直接往渲染缓冲里塞。顶点之间有没有共享边、哪些三角形邻接、某条边属于哪两个面这些信息全靠你自己算。一旦要做局部操作——比如删除一个三角形后修补孔洞、或者沿着一条边做细分——你就得遍历整个索引数组去重建拓扑关系。FDynamicMesh3在插入三角形时会自动建立边表。每条边记录两个端点顶点 ID 和相邻的两个三角形 ID边界边只有一个相邻三角形。这个边表是后续所有拓扑操作的基础。比如GetEdgeOppositeVertex、GetTriangleEdges、GetVtxEdges这些查询底层都是直接查边表不需要遍历。// 创建一个动态网格并插入一个三角形 FDynamicMesh3 Mesh; int32 V0 Mesh.AppendVertex(FVector3d(0, 0, 0)); int32 V1 Mesh.AppendVertex(FVector3d(100, 0, 0)); int32 V2 Mesh.AppendVertex(FVector3d(0, 100, 0)); int32 T0 Mesh.AppendTriangle(V0, V1, V2); // 查询三角形的三条边 FIndex3i Edges Mesh.GetTriangleEdges(T0); // 查询某条边的两个相邻三角形 FIndex2i Tris Mesh.GetEdgeT(Edges.A);这段代码看起来简单但背后发生的事不少AppendTriangle会检查三条边是否已存在不存在就创建新边并记录邻接关系存在就更新边的邻接三角形列表。这个自动维护机制让后续的CollapseEdge、SplitEdge、FlipEdge等操作变得非常直接。2.2 属性层与重叠顶点UV 接缝和硬边的处理逻辑FDynamicMesh3的另一个关键设计是属性层Attribute Layer和重叠顶点Overlay Vertex的概念。在渲染网格里一个位置上的顶点可能因为 UV 接缝或硬边法线而需要拆分成多个渲染顶点。ProceduralMesh 的做法是让你直接提供拆分后的顶点数组而FDynamicMesh3用属性层来管理这种拆分。具体来说FDynamicMesh3的顶点位置是唯一的但每个三角形可以引用不同的 UV 和法线属性。当需要拆分时通过SplitVertex或属性层的AppendElement来创建重叠顶点。这样做的好处是拓扑操作始终在唯一的顶点集合上进行不会因为 UV 接缝导致拓扑断裂。我踩过的一个坑早期直接用FDynamicMesh3的顶点位置去算邻接关系忽略了属性层拆分结果在做平滑操作时接缝处的顶点被当成两个独立顶点处理平滑后接缝裂开。后来改用FDynamicMesh3::GetVtxConnectedTriangles配合属性层的GetParentVertex来统一处理才解决这个问题。2.3 与渲染管线的对接FDynamicMeshComponent 的角色FDynamicMesh3本身只是数据容器要渲染出来需要FDynamicMeshComponent或UDynamicMeshComponent。这个组件负责把FDynamicMesh3的数据转换成渲染线程可用的缓冲。和 ProceduralMeshComponent 不同FDynamicMeshComponent支持增量更新——你修改了网格的某一部分它只重建受影响区域的缓冲而不是整个网格。这个增量更新机制在频繁修改网格的场景下非常关键。我实测过一个 5 万面的网格用 ProceduralMeshComponent 每次修改全量重建需要 8-12ms而FDynamicMeshComponent的增量更新可以压到 1-3ms。差距主要来自它内部的FDynamicMeshChangeTracker和渲染缓冲的局部更新逻辑。注意FDynamicMeshComponent的增量更新需要你通过EditMesh或ApplyChange接口来修改网格直接操作FDynamicMesh3的底层数组不会触发增量更新会导致渲染不同步。3. Mesh 操作的核心 API从布尔运算到 Remesh 的实战拆解3.1 布尔运算MeshBoolean 的输入输出与精度控制GeometryCore 的布尔运算实现在MeshBoolean命名空间下支持并集、交集、差集三种操作。输入是两个FDynamicMesh3输出是结果网格。和编辑器里的布尔工具不同这套 API 可以在运行时调用而且对非流形网格有一定的容错能力。#include MeshBoolean.h FDynamicMesh3 MeshA, MeshB; // ... 填充两个网格 ... FGeometryResult Result; MeshBoolean::ComputeBoolean( MeshA, MeshB, MeshBoolean::EBooleanOperation::Difference, Result ); if (Result.HasResult()) { FDynamicMesh3 OutputMesh Result.GetResultMesh(); // 处理输出网格 }布尔运算的精度控制主要通过FMeshBooleanOptions来设置。关键参数包括SnapTolerance顶点吸附容差和WindingThreshold环绕数阈值。SnapTolerance决定了多近的顶点会被合并设得太小会导致布尔结果出现裂缝设得太大又会把本该分开的细节粘在一起。我的经验值是取网格平均边长的 0.1%-1%具体要看模型尺度。WindingThreshold控制的是内外判定。对于封闭网格0.5 是标准值对于有开口的网格可能需要调低到 0.3 左右才能得到合理结果。这个参数在差集运算中尤其敏感设错了会出现“该挖掉的面没挖掉”或者“挖过头”的情况。3.2 网格简化与重网格化Reduce 和 Remesh 的适用场景网格简化FMeshSimplification和重网格化FRemesher是两个容易混淆的操作。简化是在保留原始拓扑结构的前提下减少三角形数量适合 LOD 生成重网格化是重新生成一套均匀的拓扑适合修复扫描数据或做均匀细分。FMeshSimplification的核心参数是TargetTriangleCount和EdgeLengthThreshold。前者是目标三角形数后者控制边长的最小阈值——低于这个值的边不会被折叠。实际用的时候我一般先设TargetTriangleCount为目标值的 1.1 倍然后让EdgeLengthThreshold自动计算这样能在保证简化率的同时避免过度折叠导致形状失真。FMeshSimplification Simplifier; Simplifier.TargetTriangleCount 5000; Simplifier.EdgeLengthThreshold 0.01; Simplifier.Simplify(Mesh);FRemesher的用法更复杂一些需要设置目标边长TargetEdgeLength和迭代次数。它的优势是能生成质量更高的三角形分布但计算量比简化大得多。我一般只在离线处理或加载阶段用 Remesh运行时还是以简化为主。3.3 空间查询与碰撞MeshAABBTree 和 MeshSpatial 的配合GeometryCore 提供了MeshAABBTree3和MeshSpatial3两套空间查询结构。MeshAABBTree3基于 AABB 树做射线检测和最近点查询MeshSpatial3基于哈希网格做范围查询和邻域搜索。MeshAABBTree3的典型用法是射线检测MeshAABBTree3 Spatial(Mesh, true); FRay3d Ray(Origin, Direction); int32 HitTriangleID; double HitDistance; if (Spatial.FindNearestHitTriangle(Ray, HitDistance, HitTriangleID)) { FVector3d HitPoint Ray.PointAt(HitDistance); // 处理命中 }MeshSpatial3更适合做“找出某点周围 N 米内的所有三角形”这类查询。它的构建成本比 AABB 树高但范围查询效率更好。在实际项目里我通常两个都建AABB 树用于精确射线检测Spatial 用于粗筛和邻域操作。提示MeshAABBTree3的构建是惰性的第一次查询时才会真正构建。如果网格在构建后发生了修改需要调用Rebuild或重新创建实例否则查询结果会基于旧数据。4. 实际项目中的踩坑记录那些文档里不会写的问题4.1 顶点法线重算的时机与陷阱FDynamicMesh3在修改后不会自动重算法线。如果你删除了一个三角形相邻三角形的法线可能已经不对了但FDynamicMesh3不会主动更新。需要手动调用MeshNormals::ComputeVertexNormals或MeshNormals::ComputeOverlayNormals。这里有个坑ComputeVertexNormals会覆盖所有顶点的法线包括那些你手动设置过的硬边法线。如果网格里有硬边比如立方体的棱直接调用这个函数会把硬边平滑掉。正确的做法是用ComputeOverlayNormals它会尊重属性层的拆分只在同一平滑组内计算平均法线。我遇到过一个更隐蔽的问题在增量更新模式下如果只重算了部分区域的法线但渲染缓冲的更新范围没覆盖到相邻三角形会出现“法线接缝”——两个相邻三角形一个用了新法线一个用了旧法线光照下明显有一条亮线。解决办法是在修改后把受影响区域向外扩展一圈再重算法线。4.2 属性层索引错位UV 和法线不同步的排查过程属性层的索引管理是FDynamicMesh3里最容易出错的地方。每个属性层UV、法线、颜色都有自己的元素数组和索引映射。当你做SplitVertex或CollapseEdge时属性层的索引需要同步更新否则会出现 UV 错位或法线指向错误。我排查过一个 UV 错位问题现象是切割后的网格大部分 UV 正常但切面附近的 UV 全部挤在一起。排查过程是这样的先确认切割算法本身没有修改 UV 数据——用Mesh.GetUVLayer打印切割前后的 UV 值发现切面附近的 UV 确实变了。检查SplitVertex的调用——发现切割时对切面顶点调用了SplitVertex但没有同步调用属性层的SplitElement。修复方案是在SplitVertex后手动调用AttributeLayer-SplitElement把原顶点的 UV 复制到新顶点上。这个问题的根因是FDynamicMesh3的SplitVertex只处理拓扑层面的拆分属性层的拆分需要单独处理。文档里没有明确说明这一点我是翻了源码才确认的。4.3 大网格操作的性能瓶颈与分块策略FDynamicMesh3虽然比 ProceduralMesh 高效但面对十万面以上的网格单次全量操作仍然可能卡顿。我做过一个测试对 20 万面的网格做一次布尔差集耗时约 450ms其中大部分时间花在 AABB 树的构建和三角形相交测试上。优化策略是分块处理。把大网格按空间位置切成若干块每块单独建 AABB 树布尔运算时只处理与切割体相交的块。这样能把单次操作时间压到 50ms 以内。代价是需要维护块之间的边界一致性切割后要处理跨块的裂缝。另一个优化点是延迟法线重算。如果连续做多次网格修改不要每次修改后都重算法线而是等所有修改完成后统一重算。我实测过连续 10 次修改后统一重算比每次修改后重算快 3-4 倍。5. 可复用的代码片段与配置建议5.1 运行时网格切割的最小实现下面是一个运行时切割的最小实现基于平面切割保留了切面的 UV 和法线#include DynamicMesh/DynamicMesh3.h #include MeshCutting.h void CutMeshWithPlane(FDynamicMesh3 Mesh, const FPlane3d Plane) { FMeshPlaneCut Cutter(Mesh, Plane); Cutter.Cut(); // 重算切面法线 MeshNormals::ComputeOverlayNormals(Mesh); // 更新渲染 if (FDynamicMeshComponent* Comp GetComponent()) { Comp-EditMesh([](FDynamicMesh3 EditMesh) { EditMesh MoveTemp(Mesh); }); } }这段代码的关键点是FMeshPlaneCut会自动处理切面的三角形重建和属性层拆分。但切面的 UV 需要你手动指定——默认情况下它会用平面投影生成 UV如果需要保留原始 UV 的连续性需要在Cut之前设置UVLayer和投影参数。5.2 网格简化的参数配置表参数推荐值说明TargetTriangleCount原始面数的 10%-30%根据 LOD 级别调整EdgeLengthThreshold平均边长的 0.5-2 倍太小会导致过度折叠bPreserveBoundarytrue保留边界边避免开口变形bPreserveUVtrue保留 UV 接缝MaxIterations10-20迭代次数太多会变慢这个配置是我在多个项目里总结出来的适用于大多数角色和道具的 LOD 生成。地形类网格需要把EdgeLengthThreshold调大一些因为地形通常有大量细长三角形。5.3 空间查询的性能对比查询类型MeshAABBTree3MeshSpatial3射线检测快O(log n)慢最近点查询快中等范围查询中等快构建成本低高内存占用中等高动态更新需重建支持增量选择建议如果主要是射线检测和最近点查询用MeshAABBTree3如果需要频繁做范围查询和邻域操作用MeshSpatial3如果两者都需要可以同时建但要注意内存开销。6. 从 GeometryCore 延伸出去还能怎么玩FDynamicMesh3的能力远不止上面提到的这些。它还可以和 GeometryScripting 配合在蓝图里直接调用网格操作可以和 ModelingTools 配合做编辑器内的交互式建模可以和 Chaos 物理配合做实时破碎。我最近在尝试的一个方向是用FDynamicMesh3做运行时地形变形——玩家走过的地方地面凹陷爆炸后地面出现弹坑。核心思路是把地形网格转成FDynamicMesh3用MeshSpatial3做范围查询找出受影响区域然后对区域内的顶点做位移。这个方案比用高度图更灵活因为可以处理悬垂和洞穴结构。另一个方向是网格的 LOD 自动生成。用FMeshSimplification配合MeshAABBTree3做视距判断运行时动态切换不同精度的网格。这个方案在开放世界项目里很有价值能显著降低渲染开销。提示FDynamicMesh3的序列化格式和 StaticMesh 不同如果需要持久化保存建议用FDynamicMesh3::Serialize或导出为 OBJ/FBX。直接保存二进制数据在不同引擎版本间可能不兼容。最后分享一个调试技巧FDynamicMesh3提供了CheckValidity方法可以在每次操作后调用检查拓扑一致性。虽然会拖慢性能但在开发阶段能帮你快速定位问题。我一般在关键操作后加一个check(Mesh.CheckValidity())出问题时能第一时间发现。
