企业官网建设流程全解析

1. 从“能跑就行”到“几何可控”：GeometryCore 到底在解决什么问题

如果你在 UE5 里做过程序化建模、动态切割、地形雕刻或者运行时网格变形，大概率经历过这样的场景：蓝图里拖了一堆 ProceduralMeshComponent 节点，跑起来帧率直接腰斩；想对 StaticMesh 做布尔运算，发现引擎自带的工具要么在编辑器里才能用，要么精度一塌糊涂；好不容易用第三方库生成了顶点数据，往渲染管线里塞的时候又卡在法线、切线、UV 的重算上。

GeometryCore 就是在这个背景下进入视野的。它不是某个单一功能，而是 UE5 内部一套完整的几何处理引擎，核心围绕FDynamicMesh3这个动态网格数据结构展开。你可以把它理解成一个“网格操作系统”——顶点、边、三角形、属性层、空间查询、布尔运算、简化、细分、重映射，这些操作在 GeometryCore 里都有对应的模块和算法实现。

我第一次认真翻 GeometryCore 的源码是因为一个需求：在运行时对角色装备进行实时切割，切面要平滑、UV 要正确、法线要重算、切割后的碎片还要能独立参与物理模拟。用 ProceduralMeshComponent 试了一版，顶点数一多就崩，UV 接缝处全是拉伸。后来转到FDynamicMesh3+FDynamicMeshComponent这套组合，才真正把效果稳住。

这篇文章面向的是已经在 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 全部挤在一起。排查过程是这样的：

1. 先确认切割算法本身没有修改 UV 数据——用Mesh.GetUVLayer打印切割前后的 UV 值，发现切面附近的 UV 确实变了。
2. 检查SplitVertex的调用——发现切割时对切面顶点调用了SplitVertex，但没有同步调用属性层的SplitElement。
3. 修复方案是在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 网格简化的参数配置表

这个配置是我在多个项目里总结出来的，适用于大多数角色和道具的 LOD 生成。地形类网格需要把EdgeLengthThreshold调大一些，因为地形通常有大量细长三角形。

5.3 空间查询的性能对比

选择建议：如果主要是射线检测和最近点查询，用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())，出问题时能第一时间发现。