UE5 HLOD分层LOD优化大场景：从卡成PPT到4K稳帧的实战复盘

项目背景：一场被逼出来的优化战役

去年接手了一个智慧城市可视化项目，甲方要求在一个超大的城市场景里同时展示建筑、道路、植被和动态车流，初始场景面数超过2亿，直接让演示用的RTX 3090败下阵来——帧率只有个位数，操作延迟明显，活脱脱一个PPT。这并非硬件不够，而是场景管理方式出了问题。在UE5里，Nanite能处理高模静态网格体，但面对海量的非Nanite资产、植被、程序化生成内容，传统的单物体LOD依然会带来巨大的Draw Call和渲染负担。于是，我把目光投向了HLOD（Hierarchical Level of Detail，层次细节），这成了整个项目的救星。

这篇文章不是泛泛而谈HLOD的用法，而是想通过这次项目，复盘我们踩过的坑、摸索出的方法论和最终的交付效果。如果你是做大型开放世界、数字孪生或虚拟制片的，希望这篇实战复盘能帮你少走弯路。

为什么需要HLOD：从Draw Call说起

在进入技术细节前，先聊聊HLOD存在的意义。传统LOD是针对单个Actor在不同距离切换不同精度的模型，但当一个场景里有成千上万个Actor时，即使每个Actor都做了LOD，渲染线程依然要遍历所有Actor的可见性，向GPU提交成千上万个Draw Call。每一次Draw Call都有固定开销，CPU一旦成为瓶颈，帧率就上不去。

HLOD的思路是：把空间上相邻的一簇Actor合并成一个整体，生成一个简化的代理网格（Proxy Mesh），并烘焙出对应的纹理。当摄像机离得远时，直接渲染代理网格，大大减少了Draw Call和三角形数量；当摄像机靠近时，再用原始Actor替换。这本质上是一种空间换时间的策略，用内存和预处理时间换取运行时的高效渲染。

在UE5中，HLOD系统与World Partition（世界分区）紧密集成。World Partition把大世界切成一个个网格单元，每个单元可以独立加载和卸载，而HLOD则对这些单元内的Actor进行合并。理解了这一点，后续的很多设置就顺理成章了。

第一步：场景准备与工作流构建

项目启动阶段，我们没有急着开HLOD，而是先做了一件最重要的事：资产规范。所有静态网格体必须按模块化思想设计，且要保证原点一致、比例统一。植被和分散的小物件（如石子、路灯）最好用Instanced Static Mesh（ISM）或Hierarchical ISM（HISM）来生成，这样在HLOD合并时能大幅减少代理网格的复杂度。

随后，我们启用了World Partition。在UE5中，将场景转为World Partition后，每个Actor都会根据其位置被分配到对应的网格单元。我们设置了网格大小为256米，这样每个单元内的Actor数量相对可控。HLOD层则建了两层：第一层负责把每个单元内的静态网格体合并成一个简化网格，第二层再把相邻单元的合并结果进一步合并，形成一个更大的代理。层级过多反而会降低效率，两层在这个场景中刚好。

// 伪代码示意：在项目设置中启用HLOD并配置层级
// 1. 开启World Partition
// 2. 在World Partition面板中，添加HLOD Layer
// 3. 设置HLOD级别：Level0（单元内合并），Level1（跨单元合并）
// 4. 为每个HLOD级别指定建造算法（如MeshMerge，SimplifyMesh）

技巧提示：HLOD的建造算法选择很关键。对于建筑类，使用MeshMerge（网格合并）能保留整体轮廓；但对于植被，简单的网格合并会保留大量细节，不如使用SimplifyMesh（简化网格）并大幅降低三角形数量。我们的经验是：建筑用MeshMerge，植被用SimplifyMesh，效果最平衡。

核心配置：手把手教你搭建HLOD系统

在UE5编辑器中，HLOD的配置主要涉及三个地方：项目设置、World Partition设置和HLOD Layer的蓝图。

项目设置中，需要开启Support World Partition和Enable HLOD。然后，在World Partition窗口中，我们为HLOD Layer指定了合并算法。UE5内置了多个HLOD模块，比如MeshMergeModule、InstancingModule等，我们选的是MeshMergeModule并自定义了简化设置。

关键参数有三个：Simplification Setting（简化设置）、Material Merging（材质合并）、Texture Size（纹理大小）。简化设置我们用了Screen Size模式，设定代理网格的屏幕尺寸阈值，当小于该阈值时切换为代理。材质合并选了MergeMaterial，它会将多种材质合成一张图集，但需要注意的是，如果材质中有动态参数或动画，合并后会丢失，所以要确保合并的对象都是静态的。纹理大小我们设为2048，足够远距离观察，且内存占用可控。

另一个重要参数是HLOD Level。我们设置了两个Level，Level0的建造范围是单个网格单元，Level1则覆盖2×2个单元。这样当摄像机从高空俯瞰时，能看到Level1的巨大代理网格，画面依然完整。

下面是我们在Level0的HLOD层蓝图中设置的配置：

// 伪代码：HLOD层设置示例
UHLODLayer* Layer0 = CreateHLODLayer();
Layer0->LoadStrategy = EHLODLayerLoadStrategy::AlwaysLoaded;
Layer0->BuildSettings->bUsedForNanite = false;
Layer0->BuildSettings->MergeDistance = 0; // 合并距离设为0表示在该层级内全部合并
Layer0->BuildSettings->SimplificationSettings->ScreenSize = 0.1f; // 屏幕尺寸阈值
Layer0->BuildSettings->MaterialSettings->MaterialMergeType = EMaterialMergeType::Merge;
Layer0->BuildSettings->TextureSize = 2048;

这里的ScreenSize是相对值，需要根据场景规模和摄像机距离反复测试。我们最初设0.1，结果代理网格在稍远处就切换了，导致边缘闪烁；调小到0.05后，切换距离变远，但代理网格更复杂，Draw Call下降不明显。最终通过多次试错，找到0.08这个平衡点。

踩坑实录：那些年我们翻过的车

HLOD配置看似简单，实际运行时问题不少。我们踩过最大的坑是材质合并导致的漏光。当时为了追求极致的合并率，我们启用了所有物体的材质合并，结果建筑模型的窗户部分出现了奇怪的黑色块，远处看像是楼房破了个洞。排查后发现，是材质合并时，半透明材质（如玻璃）被错误地合并到了不透明图集中，导致透明部分渲染异常。解决方案是：在构建HLOD前，将所有半透明材质的Actor排除在合并范围之外，或者为它们单独设置一个HLOD层。

另一个坑是HLOD代理网格的碰撞。默认情况下，HLOD生成的代理网格没有碰撞体，这本来没问题，但我们的场景需要支持飞行相机碰撞检测。一开始没关碰撞，导致相机撞上了代理网格，镜头乱晃。后来我们在HLOD的构建设置中，将Collision Complexity设为None，代理网格不再参与碰撞，问题解决。

还有一次，我们发现HLOD构建完成后，某些物体在远处显示正常，但靠近时却消失了。后来了解到，这是World Partition的加载机制导致的。当摄像机移入单元时，HLOD代理会卸载，而原始Actor尚未加载完成，就会出现短暂的空白。解决办法是使用World Partition的HLOD Streaming策略，设置过渡区域，让HLOD和原始Actor有一个重叠的加载范围，确保平滑过渡。

注意事项：HLOD构建会消耗大量时间和内存，尤其是对于大场景。我们当时构建一次要跑将近2小时，占内存20GB。建议在专用机器上运行构建，并且定期清理缓存。另外，构建后的HLOD数据会存放在Content目录下，注意项目备份。

性能对比：数字说话的交付报告

经过三轮迭代，最终性能数据令人满意。以下是优化前后的关键指标对比：

可以看到，Draw Call下降了94%，这是帧率提升的最大功臣。三角形数量也大幅减少，但得益于Nanite和虚拟纹理，视觉质量几乎无损。显存占用降低得益于HLOD代理网格的纹理合并，以及World Partition的按需加载。

除了帧率，场景加载速度也快了不少。World Partition配合HLOD，使得初始加载只需加载远景的代理网格，进入区域后再逐步加载高精度资产，用户体验流畅了许多。

美术表现：让优化不背锅

很多开发者担心HLOD会牺牲画质。的确，如果粗糙地降低细节，远景会显得很“假”。我们在构建HLOD时，特意保留了代理网格的法线贴图和粗糙度贴图，并用了高质量的简化算法（如Mesh Reducer），让建筑轮廓在远处依然锐利。同时，我们为HLOD代理网格单独制作了基于物理的材质，甚至用贴花模拟了窗户和细节，这样即使模型面数减少，视觉效果依然在线。

另外，我们还利用了UE5的Lumen全局光照。由于HLOD代理网格是静态合并的，Lumen照常工作，而且因为代理网格数量少，全局光照计算更高效，最终画面的光影质量甚至比之前逐物体渲染时更稳定。

最终交付的项目，甲方评价“比竞品流畅太多”，而我们也从中学到了HLOD的巨大潜力。这次经验后来也被我们用在了另一个开放世界项目中，效果同样出色。

总结：HLOD的适用边界与我们的方法论

这次实战让我们坚定了：HLOD是UE5大场景优化的基石，但并非万能。它最适合具有大量静态资产、场景规模宏大的项目，比如城市、山川、森林。对于动态物体（如角色、载具），传统LOD和Culling依然必要。HLOD的构建时间、内存消耗和美术工作量也需要纳入项目计划。

我们的方法论可以浓缩为三点：资产规范先行、层级设置克制、美术表现兜底。希望这篇复盘能给你的项目带来启发。如果你也在HLOD上遇到过奇怪的问题，不妨在评论区聊聊，我们共同探讨。