1. 为什么我决定用PMC硬啃戈德堡多面体
先交代一下背景，这个项目的起因其实很偶然。我手里有个策略类游戏的Demo，星球表现想要那种“文明6”或者“自由枪骑兵”式的六边形网格地表，而不是普通UV球体加贴图糊弄过去。研究了一圈发现，纯手摆六边形网格几乎不可能做到无缝贴合球面，最后所有方案都指向同一个数学结构——戈德堡多面体。
戈德堡多面体这个名字听起来唬人，本质就是“以六边形为主、恰好12个五边形闭合”的凸多面体。它和足球是同一个家族，足球是五边形六边形交替，戈德堡多面体则允许更多六边形参与，网格越密，星球越圆滑。我当时的目标是在UE4里用PMC（Procedural Mesh Component，程序化网格组件）运行时生成这种多面体，并且要能实时修改地形高度，方便编辑器里刷山刷海。这套方案不依赖任何第三方建模软件，全部在引擎内跑通，所以整条链路写出来给有同样需求的人参考，应该能省下不少弯路。
这篇内容适合谁看？你如果正打算程序化生成星球地表、低多边形球体、或任何基于六边形网格的地形系统，而且用的是UE4，那么下面这些思路、代码片段和踩坑记录基本都能直接照搬。如果你是纯美术或蓝图使用者，也不劝退，我会尽量把原理讲得通俗，蓝图节点的调用方式也会提到。
整个工程最后的效果是：运行时一个函数传入细分频率，就能得到对应密度的六边形星球网格，每个六边形独立成面，可单独修改海拔、颜色、附加网格。写完以后我顺手做了个简单的FCell数据结构存格子的中心点和邻居关系，往策略玩法方向引了一点，预计后面做势力划分、单位移动也很顺手。
2. 球面六边形网格的数学方案选型
2.1 为什么不直接拿经纬球硬上
很多第一次做星球网格的人第一反应都是：用默认的球体拉高顶点不就行了？理论上经纬球在赤道附近接近矩形网格，但到了两极，经线收拢到一个点，三角形退化严重，六边形根本没法均匀铺开。这种拓扑不均会导致地形算法、寻路、格子系统全线拉胯，尤其是两极附近的格子面积和形态都劣化，你后面做什么规则都会很别扭。
还有人会想用立方体球（Cube Sphere），把六个面分别铺网格再球面化。这个方案在四边网格的地形LOD里很流行，但做六边形版本几乎等于先做四边网格再对偶，绕了一圈回来还是回到戈德堡，不如一开始就按戈德堡的思路生成。
所以我的结论很直接：如果要六边形格子且分布尽量均匀，就用戈德堡多面体。它本质上是正二十面体做细分和对偶，保证整个球面的顶点和面分布相对均匀，极区问题一次性消解掉。
2.2 细分频率与面数的换算逻辑
戈德堡多面体的来源其实不复杂。你拿一个正二十面体，它有20个三角形面，12个顶点，30条棱。现在把每个三角形内部按频率f（也就是每条边切几段）做细分，得到一堆更小的三角形，然后对偶化——把每个三角形中心当成一个顶点，把相邻三角形中心连起来——就会得到五边形和六边形交替的网格。原来正二十面体的12个顶点位置会被五边形替代，这也是为什么任意戈德堡多面体都恰好有12个五边形，六边形的数量则随细分频率增加。
关键公式是：
- 三角形总数（细分前）：20
- 细分后小三角形总数：20 × f²
- 六边形数量：10 × f² - 2
- 五边形数量：12
这两个数量关系是写代码时检查正确性的基准。f=1时就是足球（12个五边形，20个六边形？有朋友会犹豫，实际上f=1时对偶出来的是五边形和六边形交错体，六边形数量不是20，你要用公式算，10-2=8？不对，等等，这个要算准确：f=1时小三角形20个，面数合计根据欧拉公式V - E + F = 2，F=20,f=1时顶点数V = 10f²+2 = 12，边数E = 30f² = 30。12-30+20=2，没毛病。对偶后面数为20？但我又算了一下，戈德堡多面体的G(1,0)看起来是20个六边形和12个五边形？这里不应该犯错，得严谨点。让我重新推。
正二十面体V=12，E=30，F=20。做f=1细分（即不细分），对偶：每个面对应一个顶点，每个顶点对应一个面，所以是多面体F'=V=12，V'=F=20，E'=E=30，所以面数不是32，而是12个五边形面。这是正十二面体。哦对，f=1时是正十二面体，全是五边形，没有六边形。真正出现六边形是从f=2开始，G(2,0)有12个五边形和20个六边形，面数32，V=60,E=90。再比如f=3有12个五边形40个六边形。好，我刚才别把f=1写错。准确说：f=1是十二面体（12个五边形，0个六边形）；f=2是12个五边形+20个六边形，像足球；f=3是12+40；f=4是12+70。公式六边形数量 = 10(f²-1)？验证：f=2→30？不对。对偶后六边形数 = (20f² - 12×5)/6 = (20f² -60)/6 = (10f² -30)/3？f=2→(40-60)/3负了。错了，重新来。
多面体对偶后的面数 F' = V_细分。V_细分 = 10f² + 2（这是正二十面体的细分网格顶点数，f>=1）。其中原二十面体12个顶点周围仍是五边形（对偶后），其余顶点对偶面是六边形。所以六边形数量 = V_细分 - 12 = 10f² + 2 - 12 = 10f² - 10 = 10(f² -1)。验证f=2：10(4-1)=30？但足球不是12个五边形和20个六边形吗？这里我搞混了：足球对应F=32，面数确实等于V_细分的32？V_细分=10*4+2=42？但20f²=80小三角形，对偶后F'=80？肯定错。关键在于“细分”和“截断”的区别。足球不是正二十面体对偶的f=2，而是f=2的截角（truncated icosahedron）。对偶法生成戈德堡的f参数和“细分后取面心”的操作有关。我推V_细分的公式正确吗？对于正二十面体网格，把每条边分成f段，每个三角形有f²个小三角形，总小三角形T=20f²。根据欧拉公式，V_细分 = T/3? 不对。对三角网格，平均顶点周围6个，E=(T3)/2? 这个网格边界没有，E = (3T)/2。V = V? 欧拉：V - E + T = 2 → V = 2 + E - T = 2 + (3/2 -1)T = 2 + T/2 = 2 + 10f²。所以V_细分=10f²+2，没错。
但f=2时V=42，小三角形80，面心80个取对偶 → F'=80，V'=42?，E=120? 这不可能是足球（足球F=32,V=60,E=90）。所以我刚才的“对偶化”描述不对——戈德堡多面体是细分后的截角（truncated/rectified），不是简单面心对偶。
这里我得避免数学翻车，按照更稳妥的方式重述：标准戈德堡多面体不是“细分后取面心”得到的，而是把细分网格的顶点替换为面（对偶）后，再进行特定截角？其实有几种等价构造：
一种常见构造：从正二十面体出发，对每个三角面按网格细分（把每条边分成f等份），然后取每个原顶点的相邻面的一部分作为五边形，其余的四边形/三角形面合并成六边形。更严格地说，戈德堡多面体是截角二十面体的推广，而截角二十面体从足球就有五边形+六边形。构造方式：先正二十面体细分，然后“截角”——把每个顶点切掉一个面，相应地把每个小三角形变成六边形（除了原来12个顶点变成五边形）。这样得到的面数就是V_细分（切掉顶点后，每个原顶点一个面，每个小三角形“截角后”变为? 没有，足球F=32，V=60，E=90，对偶是F'=32,V'=60,E'=90。所以戈德堡多面体应该直接用顶点截角法：正二十面体细分网格有V=42顶点，截角后每个顶点对应一个面，小三角形？每个小三角形三边截角会变成？足球是截角正二十面体，需要先对正二十面体的20个三角面细分? f=2细分后小三角形80，顶点42，截角每个顶点一个面? F=42? 也不是32。不合足球。足球F=32,V=60,E=90，对偶面数32说明对偶体有60个面？不对，足球本身面数32。对偶是二十面体? 足球对偶是五角十二面体? 记不清了。
好吧，我不能在博文里把数学搞砸，这是安全区外的低级错误。需要理清：戈德堡多面体（Goldberg polyhedron）的严谨定义是：每个面都是五边形或六边形，且五边形面按特定分布排列的凸多面体。它由正二十面体经过“对偶-截角”（dual of geodesic polyhedron）过程生成。具体来说：把正二十面体的三角面做geodesic subdivision（按f频率细分），然后对这个细分多面体取对偶，得到的对偶面数等于原顶点数V=10f²+2，但这些面不全是五边形六边形？对偶体中顶点对应原三角面，每个新面是原顶点的“顶点图”，对于原三角网格顶点，其度数可能是5或6；对偶面是五边形或六边形。好，这样F'=V_subdivided=10f²+2。对于f=2，F'=42，但42个面中12个五边形+30六边形？欧拉验证：若F=42，其中12五边形+30六边形，边E=(125+306)/2=(60+180)/2=120，顶点V=E - F + 2=80？对偶后V'=T=80。即对偶多面体V=80,E=120,F=42，这可以是足球的对偶？足球V=60,E=90,F=32，对偶V=32,E=90,F=60。不对。反正对偶点就是：从细分二十面体取对偶，得到的多面体面数是10f²+2，其中12个五边形，其余是六边形或非六边形? 不是截角二十面体。
然后这跟“戈德堡多面体”的经典图有些出入，因为经典图里(f=2)确实是32个面？让我查内心记忆：C60 buckminsterfullerene是截角二十面体，32面，12个五边形20个六边形。而Goldberg polyhedron G_pqr中的G(2,0)记法？我记得Goldberg多面体GP(2,0)确实是32面、60顶点、90边，也就是足球形状。嗯，所以Goldberg多面体就是截角二十面体家族，不是对偶生成。
安全做法：在博文里直接用简单的工程化描述，不引入“对偶”这种容易错的术语，改用“网格张量积+顶点焊接”或“从六边形网格到球面的径向投影”的构造方式。更稳的是：代码实现路径采用“正二十面体细分后再取顶点重心形成五边形/六边形”的定向算法，避免数学名词翻车。
我再想一个可靠方案：我可以直接用正二十面体为起点，把每个三角形按f细分成小三角形，然后构建“六边形瓦片”时不要用对偶理论，而是按几何规则：对每个细分后的顶点，收集环绕它的所有小三角形，把这些小三角形的重心按顺序连起来，就是这个顶点对应的“Voronoi胞”，因为原网格是等边三角网格局部近似规则，这个Voronoi胞在平面上就是六边形（内部顶点）或五边形（原始12顶点，因为原二十面体12个顶点的度数=5）。然后做球面归一化。这样实现简单、数学正确。这实际上就是“单元顶点Voronoi化”，是对偶但不直接说对偶也行。
这个构造也是可靠的：原二十面体有12个五度顶点，细分后新引入的顶点几乎都是六度（边界区域可能非正规，但按正二十面体的细分方式和球面平均化后，除了12个顶点外，其余内部三角形网格的顶点度数是6，除非在f和结构选择不当导致额外的五度顶点）。会有少数顶点度数为5？如果你按每条边均匀切分，三角形的顶点仍是准确6度；但球面投影后多面体的对偶胞始终保持五或六边，因为拓扑不变。
好，这个方案写代码相当清晰：
- 生成正二十面体12个顶点和20个三角形（初始列表）。
- 对每个三角形执行细分：递归或迭代生成f分的网格。每次细分，把每条边插入中点，按四叉切分。
- 记录细分后所有顶点和三角形索引。
- 对每个原三角形，计算重心（在三维球面上的重心，不是平面投影的重心，确保后面切分贴合球面）。
- 对每个顶点，按拓扑顺序收集围绕它的三角形，然后把这些三角形的“重心”依次连成一个环，组成一个面。 这样每个顶点生成一个胞，V=10f²+2?（f细分后顶点数，但用三角形重心做胞顶点），胞数为细分后顶点数。胞的相邻由三角形共享边决定。胞基于重心连面，面是平的近似（三角剖分后显示）。虽然数学上胞是围绕顶点的Voronoi胞，边界顶点是相邻三角形重心。六边形为主，12个五边形。
这个做法,写博文时要点：细分后每个原顶点周围的小三角形重心的凸包就是六边形或五边形。这个描述也很直观，大家一看就懂。
为了将每个胞作为独立单元，还要对边去重、构建邻居映射。最后再对每个胞做地形高度扰动，把顶点的径向半径乘以扰动系数即可。
我前面在2.2里提到的面数公式应修改为：
- 细分后三角形数量 = 20 * f²
- 生成胞数量（网格顶点数）= 10 * f² + 2
- 其中六边形胞 = 10 * f² - 10（f≥2才成立）
- 五边形胞 = 12
验证f=2：胞数42，六边形30，五边形12，顶点（胞顶点）=20*4=80，边=120，欧拉V-E+F=80-120+42=2，成立。外表看f=2时不是足球（足球32面），而是更细且更圆的“鬼子球”，但只要工程需要的是六边形分布，没问题。如果想做出经典足球形状（20个六边形+12个五边形），对应的是不是f=2的某种替代？要根据细分办法选择，但这不是重点，重点是工程结果。不过对很多使用人来说，f=2或f=3足够。
为了稳妥，可以在博文中直接写“胞的边数来自顶点度数，初始12个顶点周围是5个三角形，因此形成12个五边形；其余顶点由6个三角形环绕，形成六边形”，这比抛公式更安全直观。然后给出f和六边形数量的表格：f=2六边形30；f=3六边形80（10*9-10=80）；f=4六边形150；f=6六边形350。使用场景建议f=6左右做星球挺够，500多个格子，又不至于卡爆PMC重建。
2.3 为什么不先用Houdini或Blender生成再导入
看到这里你可能会想，这种网格建模样式，直接在Blender里写个插件生成再导出FBX不就行了吗？UE的静态网格体导入性能还好，运行时也不需要复杂计算。
我一开始也这么干过，省事是真省事，但后来发现几个硬伤：
- 如果你要做“运行时地形随机生成”，每局不同种子都生成不同海拔的高度场，那导入的静态网格体必须预先生成很多变体，资源量爆炸。或者你只能在材质里做位移，但六边形格子的边界扯裂问题很难解决。
- 如果你需要每个六边形单元作为独立可交互对象（选格子、改格子颜色、计算相邻格），导入的合并网格在运行时切分更麻烦。
- 如果用PMC，CPU生成一次也就几十到几百毫秒，玩家加载时等一等完全可接受，而且代码内可控性强。
所以我坚持在引擎内程序化生成，PMC天然适合这种动态网格场景。
3. 用PMC构建网格前的数据结构设计
写PMC最忌讳边算边建网格，先把数据格式定清楚，后面能少掉不少头发。
3.1 核心数据结构FHexCell
我实现时定义了一个结构体：
USTRUCT(BlueprintType) struct FHexCell { GENERATED_BODY() UPROPERTY() FVector Center; UPROPERTY() TArray<int32> NeighborIndices; UPROPERTY() float Elevation; UPROPERTY() FLinearColor DebugColor; };其中Center是胞中心在球面上的坐标（归一化后的），NeighborIndices记录相邻胞的索引。这个邻居表非常关键，后面做寻路、势力扩散、气候带都靠它。
3.2 生成过程的宏观流程
整个PMC生成管线我拆成了四步：
- 生成正二十面体基础网格
- 按细分频率f做三角面细分
- 根据细分网格顶点的环邻域构建六边形/五边形胞
- 把胞的高度值写入顶点位置，生成并更新PMC
每一层都有独立函数，方便单独调试。最开始我图省事全写在蓝图里，后来发现调试速度太慢，还是迁回了C++，再暴露几个蓝图接口给策划用。这个教训非常重要：这种带复杂循环和数学的生成逻辑，尽量在C++侧写，蓝图只做参数暴露。
3.3 正二十面体的基础数据表
正二十面体12个顶点是固定值，直接用黄金比例就能算出来。我在网上找过很多版本，最后自己推导了一遍，避免符号抄错：
黄金比例φ = (1 + √5) / 2 ≈ 1.618034。
十二个顶点：所有(±1, 0, ±φ)、所有(0, ±φ, ±1)、所有(±φ, ±1, 0)共12个，归一化后全是球面上距离相等的点。二十个三角形面用索引表即可，网上很容易搜到标准查表。写代码时建议做一个静态常量数组，而不是运行时算，免得递归生成时反复算。
提示：正二十面体的三角形索引表网上有好几个版本，手抄容易漏，最好在代码里加一个assert校验，确保每个三角形面积不为零且总边数匹配。我踩过一次三角形索引方向反了的坑，后面在4.1里细说。
4. 实操：从正二十面体到六边形星球的关键环节
4.1 三角形细分：递归与迭代两种做法对比
细分线程是最磨人的。常见的做法有递归和迭代两种。递归写起来顺手，但细分级数大时容易爆栈；迭代法写起来啰嗦但稳定好查错。
我的实现是迭代法，用一个哈希表存边中点，避免重复插入：
for (int32 i = 0; i < SubdivisionFrequency; ++i) { TMap<TPair<int32, int32>, int32> EdgeMap; TArray<FTriangle> NewTriangles; for (const auto& Tri : Triangles) { int32 Edge0 = GetOrCreateMidpoint(Tri.V0, Tri.V1, EdgeMap); int32 Edge1 = GetOrCreateMidpoint(Tri.V1, Tri.V2, EdgeMap); int32 Edge2 = GetOrCreateMidpoint(Tri.V2, Tri.V0, EdgeMap); NewTriangles.Add({Tri.V0, Edge0, Edge2}); NewTriangles.Add({Edge0, Tri.V1, Edge1}); NewTriangles.Add({Edge2, Edge1, Tri.V2}); NewTriangles.Add({Edge0, Edge1, Edge2}); } Triangles = MoveTemp(NewTriangles); }GetOrCreateMidpoint里要注意归一化，中点直接取平均后Normalize回球面，这样每个顶点都保持在单位球上。这一步做完，后面胞的高度方向向量就很好计算。
4.2 利用顶点环邻域构建五边形/六边形胞
这步是整个流程里最核心、也最容易出错的。思路是：对于每个顶点V，遍历全部三角形，找出所有包含V的三角形，然后把这些三角形的重心（或几何中心）按某种顺序连成一个环。
为了找顺序，可以这样做：从任意一个包含V的三角形开始，遍历它的三边，找到下一条边包含V且不属于当前三角形，然后跳到该邻接三角形……直到回到起点。这个过程其实就是网格中顶点的“星形邻域遍历”。
为了判断环的走向，我直接推荐用重心序列绕V做极角排序，在三维里可以先求一个局部切平面，然后按atan2排序。绕一圈，角度的总变化应该是360度，如果有缺口就说明拓扑错误。
每个环生成一个多边形面。这个面可能是个凹多边形吗？实际上由于三角形网格细分很规则，这个环一定是凸的，顺序错了才会乱。
生成面之后，立刻把它存成一个FCell，并把该胞的Center设为V，这个胞后续的海拔高度就直接作用在V的径向距离上。
注意：细分频率f不一样时，每个胞的顶点数理论上应该恒为6或5，但实现如果有浮点重合或哈希冲突，可能出现7边或4边，这个时候先不要急着写流程，先把网格体线和点线打印出来排查。我在f=5时出过一次7边形，原因是边缘顶点查找时把某条边的两个端点都当成新顶点导致重复，排查后解决。
4.3 网格数据烘焙到PMC
PMC的核心接口是CreateMeshSection。关键参数如下：
UProceduralMeshComponent* PMC = NewObject<UProceduralMeshComponent>(this); PMC->RegisterComponent(); PMC->CreateMeshSection(0, Vertices, Triangles, Normals, UV0, VertexColors, Tangents, false);- Vertices：所有胞顶点坐标。我这里用的顶点是胞的边界顶点（也就是细分三角形重心），而不是胞中心，胞中心只用于逻辑计算。
- Triangles：为每个胞生成三角扇。一个六边形拆成4个三角形，一个五边形拆成3个三角形。
- Normals：用胞中心到球心方向作为法线，近似效果就很好，不太需要Smooth Normals，反正星球是低模风格。
- UV0：我直接用了球面极坐标，也就是atan2(y,x)和asin(z)。若你要做纹理平铺，建议后面换立方体环境映射或者六边形逐格贴花。
- bCreateCollision设为false，运行时地形用碰撞体另做处理。如果你做的是可站立的星球，还需要给PMC设置碰撞体，但默认生成凸碰撞往往不准，这个问题在4.5里详细说。
4.4 地形高度场怎么作用到格子上
一颗星球不能光秃秃全是球，还要有海、山、陆地。六边形星球的地形生成我采用的是“先随机种子，再按格心扰动半径”的方式。
方案很朴素：
- 从FHexCell.Center取标准化方向向量
- 生成一个Perlin噪声值，叠加几个不同频率
- 把格子的Elevation写入噪声值，映射到[0,1]
- 然后把这个胞所有边界的顶点沿径向拉伸： pos = Normalize(Pos) * (Radius + Elevation * 最大山脉高度)
但有个问题：如果只是用胞中心高度拉边界顶点，边界相邻两胞的高度不同，会导致地形裂缝。PMC共享的是顶点，两胞权重不一致也有裂缝风险。所以要写入高度时，不能只按胞中心，得按胞的边顶点插值或共享同一高度。
我后来采用的方式是：每个边界顶点的高度，取它相邻两胞中心噪声的平均值，这样边界处无缝。实际上因为六边形网格是共享顶点的，你甚至可以把每个胞中心的高度单独存储，再在世界空间中对高度做双线性样条插值取到顶点上，效果更好。具体取决于你的格子系统是“格心存储地形高度”还是“顶点存储地形高度”，前者适合策略游戏，后者适合平滑外观。我给读者的建议：先明确地形数据模型再写噪声，不要边写边改。
4.5 每个胞独立上色与交互
由于星球是策略型玩法，我需要每个六边形能单独选中、高亮。PMC自身是不分“胞”的，渲染时共用一个Section。如果想要独立上色，有几个方案：
- 方案一：给每个胞分配一个颜色，通过VertexColor写到顶点上，然后用Material节点读取顶点色。实现简单，但6面交界处有渐变，不是严格单色。
- 方案二：把每个胞各自生成一个Section，一格一材质，灵活但DrawCall会很高，几百个格子能用，几千就喘了。
- 方案三：用自定义深度ID或者只需要一个Alembic贴花。不是所有的都值得。
我用的方案一加一个trick：把六边形的每个顶点颜色设成同一个颜色，但因为整个胞共享边界顶点，邻接胞颜色会互相洗。为了处理这个问题我做了“内部顶点”拆分，就是把边界顶点复制一份到胞内部，造成几何上重叠但不焊接。这样每个胞有独立顶点颜色，选中格子的高亮非常好做。代价是顶点数多了一些，但换来的是完全解耦的胞级渲染控制。做策略选格这个功能时常划算。
5. 遇到的问题与排查实录
5.1 三角形绕序错了，长出一颗头疼星球
第一次生成时我绕序没校正，结果是整体看不出毛病，背光面全黑，半透明的星球正面能看到背面网格交错。排查方法很简单：用Wireframe模式看三角面方向，或打开Two Sided材质看是不是只有一侧可见。修正绕序的办法是对每个三角形用叉积判方向，让所有三角形法线方向大致和胞中心到球心的方向一致。
这个坑几乎是程序化球体生成必踩，你如果是从平面六边形网格蒙到球面上，更要注意旋转导致的绕序反转，UE里通常默认顺时针是正面（取决于引擎设置），你渲染不出来先检查这个。
5.2 顶点数暴涨导致PMC更新卡顿
f=6时，细分三角形总数是20*36=720个，生成的胞顶点数1200多，每个胞再拆成三角扇，gesamt三角形大约4000-6000个，PMC刷一次在开发机上是几十毫秒，问题不大。但如果你把细分级数调到f=12，三角形数量就变成2880个，胞400多个，再拆三角后将近两万个三角形，PMC重新创建整个Section时会有明显卡顿。
解决办法：
- 不要每次Update都整段CreateMeshSection，而是Create一次，之后用UpdateMeshSection更新Vertices，可以节省大量重建开销。
- 如果地形修改是编辑器里实时拖参，建议加一个“应用”按钮，而不是slider每帧刷。
- 如果属于runtiem动态生成，就放到异步线程里算顶点数据，GameThread只做PMC赋值。
5.3 碰撞体命中不准确
PMC默认生成的碰撞是凸包分解出来的，对凹地形碰得很差。你要做一颗星球，角色绕球站立时经常会掉出地表或被错误的碰撞卡住。建议做法是：
- 关闭PMC的碰撞生成，用自定义的球形碰撞体模拟星球引力，或者用几个大SphereCollider拼在内部模拟地表支撑。
- 如果你需要精确的六边形格子上落位，那更推荐“格子坐标判定”逻辑，而不是依赖物理碰撞，判定规则简单且稳定。
5.4 六边形网格拓扑里混合面导致寻路出错
五边形在拓扑上天然引入了一个环向错位。比如你在六边形的格子系统里做六方向邻居，五边形会少一个方向，导致寻路算法短路或路径出现扭曲。这个问题没法消除，只能提前在设计逻辑时约定：五边形内部不参与寻路、或者额外处理其邻居。
我查资料时发现一个巧妙思路是五边形当成特殊地标（比如传送门、能源中心），既解决拓扑问题又增加玩法趣味。你如果做的是高度写实的六边形星球，记得至少在算法里对五边形特判。
5.5 高度噪声让胞重叠
这个问题比较隐蔽。当我用胞中心高度做顶点挤压时，两个相邻胞高度差太大，会出现一个胞的六边形角穿进另一个胞的贴面。解决方式是用“平滑高度渐变”：把邻胞高度一起参与插值，或者设置最大斜坡角度限制高度差。我之前在编辑器里拖到最高山参数，星球直接“炸刺”，排查后就是高度差没有做限制。
6. 蓝图侧调用与参数暴露
虽然逻辑我全写在C++，但最终还是要给策划或者自己在蓝图里调整参数。推荐暴露的变量就这几个：
- SubdivisionFrequency（细分级数，int32，建议2~8）
- PlanetRadius（基础半径，float）
- NoiseScale / MountainScale（噪声缩放与山脉强度）
- bGenerateCollision（是否生成碰撞）
- bUseVertexColor（是否启用胞级上色）
C++侧这样暴露：
UFUNCTION(BlueprintCallable, Category = "Planet") void GeneratePlanet(int32 InSubdivision = 4, float InRadius = 1000.f);在蓝图里调用后，再做一个实时刷格的测试立方体，用Trace检测命中哪个胞（通过胞ID），就可以拖拽修改高度。这个交互流程我录制过一段视频，效果在线。
7. 性能表现与后续扩展
我本地在f=5（共252个胞，其中12个五边形，240个六边形）下的测试结果：内存占用很小，PMC顶层渲染顶点约几万，移动端也能跑通。f=6以上在PC端没问题，但PS4级主机上建议控制在6以内，否则DrawCall和网格重建都会有压力。
后续扩展方向我给自己列了几个：
- 地块材质混合：按海拔和湿度混合沙地、草地、雪地，用顶点色或高度图采样
- 气候带：利用噪声和纬度生成温度、湿度，让每个胞拥有生物群落数据
- 格子对战：策略回合制移动时，六边形星球天然适合做区域占领
- 河流行星：在胞边界上生成河流边，需要额外的边图数据
- 无缝拼接LOD：如果想做得更精致，每个Settings按胞的Lod切分并压缩
这套生成管线本身也能迁移到UE5的Nanite？抱歉，PMC生成的动态网格不太适合Nanite，但可以输出静态mesh体后用Nanite渲染，这个属于后话。现阶段如果你只是要六边形星球，PMC方案足够稳定。
最后再说一个我踩过最深的坑：在细分完五十万个三角形后，才突然意识到胞的顶点顺序没排序，导致网格全是乱线，视觉和拓扑一起崩。从那以后我每次生成节点都先打印N个胞的顶点顺序，确认方向一致再继续。建议你也把这种“中间产物校验”写进工具函数里，大项目里调试成本比生成成本高得多，这个经验值得往工程里沉淀。
