1. 为什么需要 GeometryCore 这样的几何处理引擎
1.1 从一次实际项目踩坑说起
去年接了一个室内设计工具的项目，需求听起来很朴素：让用户在运行时拖拽墙体、实时开洞、自动生成踢脚线。我一开始想得很简单，UE5 的 Static Mesh 组件加上一些 Transform 操作不就搞定了？结果第一版 Demo 交出去，客户拖了一面墙，整个场景卡了 3 秒。原因很直接——每次拖拽都在重建 Static Mesh，CPU 端重新生成碰撞、重新上传 GPU 顶点缓冲，这个开销在运行时是不可接受的。
那次之后我才真正开始认真研究 UE5 的 GeometryCore 模块。它不是一个“新功能”，而是 UE5 把过去散落在各种 Editor 工具里的几何算法统一抽象出来的一层引擎级基础设施。核心价值在于：它让 Mesh 从“静态资产”变成了“可编程的数据结构”。
具体来说，GeometryCore 提供了FDynamicMesh3这个核心数据结构，以及围绕它构建的一系列算法——布尔运算、简化、细分、UV 展开、法线重算、碰撞生成等等。而 Geometry Script 则是把这套 C++ 能力通过蓝图暴露出来的那一层封装。两者配合，你可以在运行时对 Mesh 做几乎任何 Editor 里能做的操作。
这篇文章适合谁看？如果你正在做以下任何一件事，那这篇内容应该能帮你省不少时间：
- 需要在运行时动态修改 Mesh 的工具类项目（建模工具、室内设计、角色自定义）
- 想理解 UE5 几何系统底层架构，而不是只会调蓝图节点
- 从其他引擎转过来，想搞清楚 UE5 的 Mesh 处理跟传统 Static Mesh 管线有什么区别
- 在做程序化生成，需要比 Procedural Mesh Component 更强大的几何操作能力
1.2 GeometryCore 在 UE5 架构中的位置
很多人第一次接触 GeometryCore 会困惑：它跟 Static Mesh、Procedural Mesh Component、Skeletal Mesh 到底是什么关系？
我用一个类比来解释。Static Mesh 像是“印刷好的书”——内容固定，渲染高效，但你不能改。Procedural Mesh Component 像是“活页笔记本”——你可以增删页，但每页的排版你得自己管，而且没有高级编辑功能。而FDynamicMesh3像是“Word 文档”——你可以任意编辑内容，有完整的编辑工具链，编辑完了可以“导出”成 Static Mesh 去印刷。
从模块依赖来看，GeometryCore 位于 Engine 层，不依赖 Editor。这意味着你可以在打包后的运行时使用它。但它确实会增加包体大小，因为里面包含了大量的几何算法实现。GeometryFramework 则是在 GeometryCore 之上提供了 Component 级别的封装（比如UDynamicMeshComponent），让你可以把FDynamicMesh3挂到 Actor 上参与渲染和碰撞。
这里有个关键点很多人会忽略：UDynamicMeshComponent和UProceduralMeshComponent是两套完全不同的东西。前者基于 GeometryCore 的FDynamicMesh3，支持完整的几何操作和碰撞生成；后者是更早期的方案，API 简单但功能有限。如果你在做需要复杂几何操作的项目，直接上UDynamicMeshComponent，不要走弯路。
1.3 FDynamicMesh3 的数据结构设计哲学
理解FDynamicMesh3的设计，是理解整个 GeometryCore 的钥匙。
它采用的是索引式半边结构（Indexed Half-Edge）的变体。简单说，它同时维护了顶点数组、三角形数组、边数组，以及它们之间的邻接关系。这跟渲染用的顶点缓冲（Vertex Buffer）是两回事——渲染缓冲为了 GPU 效率会做顶点拆分（比如一个位置被多个面共享但法线不同，就要拆成多个顶点），而FDynamicMesh3维护的是拓扑意义上的“唯一顶点”。
这个设计带来的直接好处是：当你做布尔运算、简化、平滑这些操作时，算法需要知道“哪些面共享这条边”“这个顶点的邻域有哪些”，索引式结构让这些查询是 O(1) 或接近 O(1) 的。代价是内存占用比纯渲染缓冲大，以及每次修改后需要重新构建渲染数据。
我实测过一个数据点：一个 5 万面的 Mesh，FDynamicMesh3的内存占用大约是同等 Static Mesh 渲染数据的 2.5 到 3 倍。所以如果你的场景里有几百个动态 Mesh，内存要提前算好账。
另一个重要特性是属性分离。FDynamicMesh3把拓扑（顶点、三角形、边）和属性（UV、法线、颜色、材质 ID）分开存储。这意味着你可以只修改拓扑而不动属性，或者只重算法线而不动拓扑。这个设计在做增量编辑时非常关键——比如你只想平滑一部分区域的法线，就不需要重建整个 Mesh。
2. Mesh 操作的核心能力与实操要点
2.1 布尔运算：最常用也最容易翻车的功能
布尔运算是 GeometryCore 里使用频率最高的功能之一，也是坑最多的。
先说你最可能用到的 API。在 C++ 层面，核心函数在GeometryAlgorithms命名空间下，比如ComputeMeshBoolean。在蓝图层面，Geometry Script 提供了Apply Mesh Boolean节点。基本用法很直观：给两个 Mesh 和一个操作类型（Union、Intersect、Subtract），输出结果 Mesh。
但实际用起来，以下这几个点必须注意：
第一，输入 Mesh 必须是流形（Manifold）的。什么叫流形？简单说就是每条边恰好被两个三角形共享，没有孤立的边、没有自交、没有非流形顶点。如果你的输入 Mesh 有这些问题，布尔运算的结果可能完全错误，甚至崩溃。我踩过的坑是：从外部导入的 OBJ 模型经常有非流形边，直接丢进布尔运算会得到一堆碎片。
解决方案是在布尔之前先做一次清理。Geometry Script 里有Apply Mesh Repair节点，可以自动修复常见的非流形问题。但要注意，修复不是万能的，复杂的自交模型修复后可能面目全非。我的经验是：对于工具类项目，尽量在资产导入阶段就做好 Mesh 清理，不要指望运行时修复。
第二，布尔运算的性能跟 Mesh 复杂度不是线性关系。两个 1000 面的 Mesh 做布尔，可能比两个 5000 面的 Mesh 还慢，因为性能瓶颈往往在相交检测和拓扑重建上，而不是单纯的三角形数量。我实测下来，对于实时交互场景，单个布尔操作的输入 Mesh 最好控制在 2000 面以内，否则帧率会明显下降。
第三，布尔结果的拓扑质量取决于输入。如果两个 Mesh 的相交面恰好跟三角形边对齐，结果会很干净；如果相交面穿过三角形内部，就会产生大量细碎三角形。这是布尔运算的固有特性，不是 UE5 的问题。缓解办法是在布尔之后接一个Apply Mesh Simplification，把那些细碎三角形合并掉。
注意：布尔运算的输出 Mesh 默认没有 UV。如果你需要 UV，要么在布尔之前确保输入有 UV 并且开启 UV 插值选项，要么在布尔之后用
Apply Mesh UV Projection重新投影。前者适合简单场景，后者适合对 UV 质量要求高的场景。
2.2 简化与重网格化：控制面数的艺术
运行时动态生成的 Mesh，面数很容易失控。一个布尔操作可能让面数翻三倍，几次操作下来就卡了。简化（Simplification）和重网格化（Remeshing）是控制面数的两个核心手段，但它们的适用场景完全不同。
简化是在保留原始拓扑结构的前提下，尽可能减少三角形数量。GeometryCore 用的是二次误差度量（Quadric Error Metric）算法，这是业界标准做法。它的优点是快、结果可控（你可以指定目标面数或目标边长），缺点是对于拓扑复杂的区域，简化后可能出现明显的形状失真。
实操中我常用的参数策略是：目标面数设为原始面数的 30% 到 50%，同时开启Preserve Boundary和Preserve UV。前者防止简化把边界搞变形，后者防止 UV 被破坏。如果简化后形状失真严重，说明原始 Mesh 的拓扑本身就不适合简化，这时候应该考虑重网格化。
重网格化是更激进的手段：它不管原始拓扑，直接根据形状重新生成一套均匀的三角形网格。GeometryCore 提供了各向同性重网格化（Isotropic Remeshing），你可以指定目标边长，算法会生成边长接近这个值的均匀网格。
重网格化的优势是结果质量高、三角形分布均匀，特别适合后续做平滑、细分或者物理模拟。缺点是慢——比简化慢一个数量级——而且会丢失原始 UV 和材质信息。所以我的建议是：如果只是要减面，用简化；如果是要为后续操作准备一个干净的 Mesh，用重网格化。
这里有个参数选择的经验公式：目标边长 ≈ sqrt(表面积 / 目标面数)。比如一个表面积 100 平方单位的 Mesh，你想要 5000 个面，那目标边长大约是 sqrt(100/5000) ≈ 0.14。这个公式不精确，但能给你一个合理的起点。
2.3 UV 展开与法线重算：容易被忽视的细节
动态生成的 Mesh 如果没有正确的 UV 和法线，渲染出来就是一团黑或者贴图乱飞。这两个问题看起来简单，但实际处理时有几个关键决策点。
UV 展开在 GeometryCore 里有几种方案。最简单的是平面投影（Planar Projection），适合地板、墙面这类平面或近似平面的几何。稍微复杂一点的是柱面投影和球面投影，适合管道、球体。最复杂的是自动展开（Auto Unwrap），它会根据 Mesh 的曲率自动切缝并展开，质量最高但最慢。
我的经验是：对于工具类项目，不要追求完美的自动展开。自动展开在复杂 Mesh 上可能耗时几秒甚至几十秒，而且结果不一定比简单投影好。更实用的做法是根据几何类型选择投影方式——墙面用平面投影，管道用柱面投影，然后手动调整接缝位置。Geometry Script 里的Apply Mesh UV Projection节点支持这些模式，用起来很直接。
法线重算看起来更简单，但有个关键选择：是重算顶点法线还是面法线？顶点法线让表面看起来平滑，面法线让每个三角形有独立的法线（硬边效果）。对于建筑类几何，通常需要混合方案——平面区域用面法线，曲面区域用顶点法线。
GeometryCore 提供了RecomputeNormals函数，你可以指定一个角度阈值：当相邻面的夹角小于这个阈值时，共享顶点法线（平滑）；大于阈值时，拆分顶点法线（硬边）。这个阈值通常设在 30 到 60 度之间。我一般用 45 度作为起点，然后根据实际效果调整。
提示：重算法线后，如果 Mesh 还要参与光照渲染，记得同时更新切线（Tangent）。切线影响法线贴图的正确性，如果切线不对，法线贴图会看起来很奇怪。Geometry Script 里的
RecomputeNormals节点有一个Recompute Tangents选项，记得勾上。
2.4 碰撞生成：运行时 Mesh 的物理化
动态生成的 Mesh 如果没有碰撞，玩家就会穿模。GeometryCore 提供了碰撞生成能力，但这里的选择比静态 Mesh 复杂得多。
首先是碰撞类型的选择。最简单的是凸包碰撞（Convex Hull），适合凸形状或近似凸形状的物体。对于复杂形状，可以用凸分解（Convex Decomposition），把 Mesh 拆成多个凸包。最精确的是三角形网格碰撞（Triangle Mesh Collision），直接用原始三角形做碰撞检测，但性能开销最大。
我的选择策略是这样的：
| 场景 | 推荐碰撞类型 | 理由 |
|---|---|---|
| 简单凸物体（箱子、球体） | 凸包碰撞 | 性能最好，精度足够 |
| 复杂静态物体（建筑、地形） | 凸分解 | 平衡精度和性能 |
| 需要精确碰撞的动态物体 | 三角形网格碰撞 | 精度最高，但面数要控制 |
| 仅用于触发检测 | 简单包围盒 | 性能最优，不需要精确形状 |
在 Geometry Script 里，Generate Collision节点可以生成这些碰撞。但要注意：碰撞生成是异步的，在大 Mesh 上可能需要几帧才能完成。如果你在生成后立即做物理查询，可能查不到。我的做法是生成后等一帧再启用碰撞，或者用回调确认生成完成。
另一个坑是碰撞的更新。当你修改了FDynamicMesh3之后，碰撞不会自动更新。你需要显式调用碰撞重建。如果每帧都在修改 Mesh，每帧都重建碰撞会非常卡。解决方案是：只在编辑操作结束时重建碰撞，编辑过程中用简化的碰撞或者暂时禁用碰撞。
3. 从零搭建一个运行时 Mesh 编辑工具
3.1 项目结构与模块配置
假设我们要做一个运行时墙体编辑工具：用户可以在场景里拖拽墙体顶点、在墙上开洞、自动生成踢脚线。这个需求覆盖了 GeometryCore 的大部分核心能力。
首先是模块配置。在你的项目.Build.cs文件里，需要添加以下依赖：
PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "GeometryCore", "GeometryFramework", "DynamicMesh", "GeometryScriptingCore" });这里解释一下每个模块的作用。GeometryCore是底层算法库，DynamicMesh是FDynamicMesh3的实现，GeometryFramework提供了UDynamicMeshComponent等组件，GeometryScriptingCore是蓝图节点的 C++ 实现。如果你只在 C++ 里用，可以不加GeometryScriptingCore，但加上也无妨，方便调试。
注意：
GeometryScriptingCore在打包版本里可能会被裁剪，如果你的项目需要在 Shipping 配置下使用 Geometry Script 的蓝图节点，需要在打包设置里显式保留这个模块。我踩过这个坑，Editor 里跑得好好的，打包后蓝图节点全变红了。
3.2 创建可编辑的 Dynamic Mesh Actor
接下来创建一个 Actor，它持有一个UDynamicMeshComponent，并提供编辑接口。
// EditableWallActor.h #pragma once #include "CoreMinimal.h" #include "GameFramework/Actor.h" #include "DynamicMesh/DynamicMesh3.h" #include "EditableWallActor.generated.h" class UDynamicMeshComponent; UCLASS() class AEditableWallActor : public AActor { GENERATED_BODY() public: AEditableWallActor(); UFUNCTION(BlueprintCallable, Category = "Wall") void InitializeWall(const TArray<FVector>& ProfilePoints, float Height); UFUNCTION(BlueprintCallable, Category = "Wall") void MoveVertex(int32 VertexIndex, FVector NewPosition); UFUNCTION(BlueprintCallable, Category = "Wall") void CutOpening(FVector Center, FVector Extent); UFUNCTION(BlueprintCallable, Category = "Wall") void RebuildCollision(); protected: UPROPERTY(VisibleAnywhere) TObjectPtr<UDynamicMeshComponent> DynamicMeshComponent; private: UE::Geometry::FDynamicMesh3 WorkingMesh; bool bMeshDirty = false; };这里的关键设计决策是：把FDynamicMesh3作为 Actor 的成员变量，而不是每次都从 Component 里取。原因是UDynamicMeshComponent的GetDynamicMesh()返回的是一个共享指针，频繁获取和修改会有额外开销。自己维护一份工作副本，编辑完成后一次性提交给 Component，效率更高。
3.3 从轮廓生成墙体 Mesh
InitializeWall函数的实现逻辑是：给定一组二维轮廓点（墙体的俯视轮廓）和一个高度，生成一个拉伸体。
void AEditableWallActor::InitializeWall(const TArray<FVector>& ProfilePoints, float Height) { WorkingMesh.Clear(); // 1. 创建底部和顶部顶点 TArray<int32> BottomVerts, TopVerts; for (const FVector& Point : ProfilePoints) { int32 BottomIdx = WorkingMesh.AppendVertex(FVector3d(Point.X, Point.Y, 0)); int32 TopIdx = WorkingMesh.AppendVertex(FVector3d(Point.X, Point.Y, Height)); BottomVerts.Add(BottomIdx); TopVerts.Add(TopIdx); } // 2. 创建侧面三角形 int32 NumPoints = ProfilePoints.Num(); for (int32 i = 0; i < NumPoints; i++) { int32 Next = (i + 1) % NumPoints; // 两个三角形组成一个四边形侧面 WorkingMesh.AppendTriangle(BottomVerts[i], BottomVerts[Next], TopVerts[Next]); WorkingMesh.AppendTriangle(BottomVerts[i], TopVerts[Next], TopVerts[i]); } // 3. 创建顶面和底面（简单扇形三角化） for (int32 i = 1; i < NumPoints - 1; i++) { WorkingMesh.AppendTriangle(BottomVerts[0], BottomVerts[i + 1], BottomVerts[i]); WorkingMesh.AppendTriangle(TopVerts[0], TopVerts[i], TopVerts[i + 1]); } // 4. 重算法线和 UV UE::Geometry::FMeshNormals::QuickComputeVertexNormals(WorkingMesh); // UV 投影略，实际项目中需要根据墙体朝向做平面投影 // 5. 提交给 Component DynamicMeshComponent->SetMesh(MoveTemp(WorkingMesh)); bMeshDirty = true; }这段代码有几个值得注意的点。第一，AppendTriangle的顶点顺序决定了法线方向，逆时针顺序产生朝外的法线。如果法线反了，渲染出来就是黑的。第二，顶面和底面的扇形三角化只适用于凸多边形，如果是凹多边形（比如 L 形墙体），需要更复杂的三角化算法。GeometryCore 提供了TriangulatePolygon函数可以处理凹多边形，实际项目中应该用它。
第三，SetMesh(MoveTemp(WorkingMesh))之后，WorkingMesh就空了。如果你需要继续编辑，需要重新从 Component 获取。我的做法是在 Actor 里保留一个EditMesh副本，每次编辑前从 Component 同步，编辑后提交回去。
3.4 实现顶点拖拽编辑
顶点拖拽是交互式编辑的核心。实现思路是：射线检测找到最近的顶点，拖拽时更新顶点位置，然后重建受影响的三角形。
void AEditableWallActor::MoveVertex(int32 VertexIndex, FVector NewPosition) { if (!WorkingMesh.IsVertex(VertexIndex)) return; // 更新顶点位置 WorkingMesh.SetVertex(VertexIndex, FVector3d(NewPosition)); // 重算法线（只重算受影响区域） UE::Geometry::FMeshNormals Normals(&WorkingMesh); Normals.RecomputeVertexNormals(); // 提交更新 DynamicMeshComponent->GetDynamicMesh()->SetMesh(WorkingMesh); bMeshDirty = true; }实际项目中，每次拖拽都全量重算法线会很慢。优化方案是只重算受影响顶点的邻域法线。FDynamicMesh3提供了顶点邻域查询接口，可以遍历一个顶点的所有相邻三角形，只重算这些三角形的法线。
另一个优化点是延迟提交。拖拽过程中，每帧都SetMesh会导致 GPU 缓冲频繁重建。更好的做法是拖拽过程中只更新 CPU 端数据，拖拽结束时才提交给 Component。UE5 的UDynamicMeshComponent支持FastNotifyPositionsUpdated这样的增量更新接口，可以只更新位置而不重建整个渲染数据。
3.5 在墙上开洞：布尔运算实战
开洞是布尔运算的典型应用。思路是：创建一个跟洞口形状匹配的 Mesh（比如一个圆柱体或长方体），然后从墙体 Mesh 中减去它。
void AEditableWallActor::CutOpening(FVector Center, FVector Extent) { // 1. 创建洞口 Mesh（一个长方体） UE::Geometry::FDynamicMesh3 OpeningMesh; // ... 生成长方体顶点和三角形 ... // 2. 执行布尔减法 UE::Geometry::FMeshBoolean BooleanOp( &WorkingMesh, &OpeningMesh, &WorkingMesh, UE::Geometry::FMeshBoolean::EBooleanOp::Difference ); BooleanOp.bSimplify = true; BooleanOp.SimplifyThreshold = 0.01; BooleanOp.Compute(); // 3. 检查结果 if (!BooleanOp.ResultMesh->IsCompact()) { // 结果有问题，可能需要修复 UE::Geometry::FMeshRepair Repair(WorkingMesh); Repair.Repair(); } // 4. 重算法线和 UV UE::Geometry::FMeshNormals::QuickComputeVertexNormals(WorkingMesh); // 5. 提交并重建碰撞 DynamicMeshComponent->SetMesh(WorkingMesh); RebuildCollision(); }这里有几个实战经验。第一，bSimplify = true会让布尔运算在结果上自动做简化，减少细碎三角形。SimplifyThreshold控制简化的激进程度，值越大简化越狠。我一般从 0.01 开始试，如果结果面数还是太多就加大。
第二，布尔运算后一定要检查IsCompact()。如果返回 false，说明 Mesh 有孤立顶点或退化三角形，需要修复。修复可以用FMeshRepair，但修复后的 Mesh 可能跟预期有偏差，最好在修复后做一次可视化检查。
第三，开洞后碰撞必须重建。如果不重建，玩家还是会被原来的墙体挡住。RebuildCollision的实现是调用DynamicMeshComponent->UpdateCollision()，但要注意这个操作是异步的，大 Mesh 上可能需要几帧。
3.6 自动生成踢脚线：沿边扫掠
踢脚线的生成思路是：找到墙体底部的边，沿着这些边扫掠一个矩形截面。
void AEditableWallActor::GenerateBaseboard(float Height, float Thickness) { // 1. 找到底部边（Z 坐标接近 0 的边） TArray<int32> BottomEdges; for (int32 EdgeId : WorkingMesh.EdgeIndices()) { UE::Geometry::FIndex2i EdgeVerts = WorkingMesh.GetEdgeV(EdgeId); FVector3d V0 = WorkingMesh.GetVertex(EdgeVerts.A); FVector3d V1 = WorkingMesh.GetVertex(EdgeVerts.B); if (FMath::Abs(V0.Z) < 0.01 && FMath::Abs(V1.Z) < 0.01) { BottomEdges.Add(EdgeId); } } // 2. 沿每条边扫掠矩形截面 UE::Geometry::FDynamicMesh3 BaseboardMesh; for (int32 EdgeId : BottomEdges) { // 获取边的两个端点 // 计算边的方向和外法线 // 生成矩形截面的四个顶点 // 连接成三角形 // ... 具体实现略 ... } // 3. 合并到主 Mesh UE::Geometry::FMeshBoolean UnionOp( &WorkingMesh, &BaseboardMesh, &WorkingMesh, UE::Geometry::FMeshBoolean::EBooleanOp::Union ); UnionOp.Compute(); DynamicMeshComponent->SetMesh(WorkingMesh); }这个功能的难点在于处理边的连接处。如果两条边共享一个顶点，扫掠出来的两个矩形截面会在顶点处重叠或产生缝隙。解决方案是在顶点处生成一个过渡段，或者直接用布尔并集把重叠部分合并掉。我选择的是后者，简单粗暴但有效。
另一个细节是踢脚线的法线方向。扫掠生成的 Mesh 法线可能朝内，需要根据墙体法线方向做翻转。判断方法是：取扫掠截面的中心点，跟墙体中心点比较，如果方向反了就翻转三角形顺序。
4. 性能优化与常见问题排查
4.1 性能瓶颈在哪里
GeometryCore 的性能瓶颈通常不在算法本身，而在数据在 CPU 和 GPU 之间的传输。每次SetMesh都会触发渲染数据的重建和上传，这个开销跟 Mesh 的面数成正比。
我实测过一组数据：一个 1 万面的 Mesh，SetMesh大约需要 2 到 3 毫秒；5 万面的 Mesh 需要 10 到 15 毫秒。如果每帧都调用，帧率直接掉到 60 以下。所以核心优化原则是：减少 SetMesh 的调用频率，增大每次调用的批量。
具体策略包括：
- 编辑过程中只更新 CPU 端数据，编辑结束后一次性提交
- 使用
FastNotifyPositionsUpdated等增量更新接口，只更新变化的部分 - 对于大 Mesh，考虑分块处理，只更新被修改的块
- 碰撞重建跟渲染更新分开，碰撞可以更低频
另一个容易被忽视的瓶颈是FDynamicMesh3的内存分配。频繁的 AppendTriangle 和 RemoveTriangle 会导致内存碎片，时间长了性能会下降。解决方案是定期调用CompactInPlace()整理内存，或者在编辑操作之间重建 Mesh。
4.2 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 布尔运算结果为空 | 输入 Mesh 非流形 | 用IsCompact()检查 | 先做 Mesh 修复 |
| 布尔运算崩溃 | 输入 Mesh 有自交 | 可视化检查 | 修复自交或换算法 |
| 渲染出来是黑的 | 法线方向反了 | 检查三角形顶点顺序 | 翻转三角形或重算法线 |
| 贴图乱飞 | UV 缺失或错误 | 检查 UV 通道 | 重新投影 UV |
| 碰撞不生效 | 碰撞未重建 | 检查碰撞状态 | 调用 UpdateCollision |
| 编辑后卡顿 | SetMesh 太频繁 | 性能分析 | 延迟提交或增量更新 |
| 简化后形状失真 | 拓扑不适合简化 | 对比简化前后 | 改用重网格化 |
| 重网格化太慢 | 目标边长太小 | 检查参数 | 增大目标边长 |
4.3 几个我踩过的坑
坑一：在 Editor 里正常，打包后崩溃。原因是GeometryScriptingCore模块在打包时被裁剪了。解决方案是在DefaultEngine.ini里添加+ModulesToPreserve=GeometryScriptingCore，或者在 Build.cs 里把模块类型设为Runtime。
坑二：布尔运算在 Mac 上结果跟 Windows 不一样。这是浮点精度差异导致的。GeometryCore 的布尔算法对浮点误差敏感，不同平台的浮点实现有细微差异，可能导致拓扑决策不同。解决方案是统一使用双精度（FVector3d而不是FVector），并且在布尔之前对顶点做量化（把坐标对齐到网格），减少浮点误差的影响。
坑三：动态 Mesh 的阴影闪烁。原因是每帧重建 Mesh 导致阴影贴图频繁更新。解决方案是给动态 Mesh 设置合适的阴影更新策略，比如只在编辑结束后更新阴影，或者使用距离场阴影代替传统阴影贴图。
坑四：大量动态 Mesh 导致内存暴涨。每个FDynamicMesh3都有固定的内存开销，即使面数很少。如果场景里有几百个动态 Mesh，内存会很快用完。解决方案是对于不再编辑的 Mesh，把它“烘焙”成 Static Mesh，释放FDynamicMesh3的内存。
4.4 什么时候不该用 GeometryCore
GeometryCore 很强大，但不是所有场景都适合。以下情况我建议用其他方案：
- 只需要简单的形状生成：用 Procedural Mesh Component 或者直接拼 Static Mesh 更轻量
- 需要极高性能的渲染：GeometryCore 的 Mesh 是动态的，渲染效率不如优化过的 Static Mesh
- 移动端项目：GeometryCore 在移动端的性能开销较大，而且会增加包体大小
- 只需要静态几何：在 Editor 里做好 Static Mesh，运行时直接用，不要动态生成
我的判断标准是：如果 Mesh 在运行时需要被修改超过 10 次，用 GeometryCore；否则用 Static Mesh 或 Procedural Mesh。这个阈值不是绝对的，但能帮你快速做决策。
5. 从 GeometryCore 延伸出去的可能性
5.1 跟 PCG 结合做程序化生成
UE5 的 PCG（Procedural Content Generation）框架跟 GeometryCore 是天然搭配。PCG 负责决定“在哪里生成什么”，GeometryCore 负责“生成什么样的几何”。比如你可以用 PCG 在场景里撒点，每个点用 GeometryCore 生成一个随机形状的石头或建筑模块。
这个组合的关键接口是UDynamicMeshComponent可以作为 PCG 的输出目标。PCG 的StaticMeshSpawner节点支持输出到 Dynamic Mesh，你可以在蓝图里进一步编辑这些 Mesh。
5.2 跟物理系统结合做破坏效果
Chaos Physics 提供了破坏系统，但它的碎片是预生成的。如果你想做“任意切割”的破坏效果，可以用 GeometryCore 在运行时切割 Mesh，然后把切割后的碎片交给物理系统。
实现思路是：碰撞发生时，用布尔运算把 Mesh 切成两块，给每块生成碰撞，然后应用物理冲量。这个方案的计算开销较大，适合对破坏效果要求高、但发生频率不高的场景。
5.3 跟 Nanite 的关系
Nanite 是 UE5 的虚拟化几何系统，它跟 GeometryCore 的关系是互补的。Nanite 擅长渲染超高面数的静态几何，但不支持运行时修改。GeometryCore 擅长运行时编辑，但渲染效率不如 Nanite。
目前的实践是：用 GeometryCore 做编辑，编辑完成后把结果烘焙成 Nanite Mesh。UE5 提供了BuildNanite相关的接口，可以在运行时把 Dynamic Mesh 转换成 Nanite 兼容的格式。但这个转换有开销，适合编辑频率低的场景。
5.4 后续可以深入的方向
如果你已经掌握了 GeometryCore 的基本用法，以下几个方向值得深入：
- 自定义几何算法：GeometryCore 的算法框架是可扩展的，你可以实现自己的 Mesh 操作算子
- 多线程编辑：
FDynamicMesh3的很多操作是线程安全的，可以利用多核做并行编辑 - Mesh 的序列化与网络同步：动态 Mesh 的网络同步是个难题，需要自定义序列化方案
- 跟 USD 格式的互操作：UE5 支持 USD 导入导出，GeometryCore 的 Mesh 可以跟 USD 数据互转
我个人在实际项目中的体会是，GeometryCore 最大的价值不是某个具体功能，而是它提供了一套完整的、可编程的几何处理框架。一旦你理解了FDynamicMesh3的数据模型和 Geometry Script 的节点体系，很多以前觉得很难的需求——比如运行时建模、程序化生成、动态破坏——都会变得有章可循。当然，性能优化和边界情况处理仍然需要大量的实践经验，这部分没有捷径，只能靠一个个项目踩出来。
