自动关联目录：Landscape

官方依据：Landscape Outdoor Terrain（UE 5.8 Documentation，官方定位为"用于创建大型开放户外环境的工具集合：雕刻 Landscape Actors、创建自定义材质并把材质绘制到 Landscape 上"）。官方文档子页面无法完整枚举，本篇按引擎模块组织。

1. 定位

Landscape 是 UE 的地形系统：一套用于创建大型开放户外环境的工具集合——雕刻地形 Actor、创建自定义材质、并把材质绘制到地形上。

一句话定位：地形是开放世界里最大的单个 Asset之一，它的分辨率、材质复杂度与阴影设置，直接决定开放世界的底线性能。

和 World Partition 的关系：World Partition 的 Open World 默认地图就自带一个 2km × 2km 的 Landscape；地形本身也会被切成组件参与流式。

2. 结构：组件与分辨率

Landscape Actor
   └── 若干 Landscape Component（流式与渲染的基本单元）
          └── 若干 Landscape Quad（顶点网格）

概念	说明
Component	加载/卸载与渲染的基本单位
Resolution	每个 Component 的顶点数，决定精度
Section	Component 内的子块
Heightmap	高度数据
Weightmap	图层混合权重（绘制材质用）

分辨率是地形的第一成本项：分辨率翻倍，顶点数四倍。官方默认地图 2km×2km 的地形已经是相当可观的数据量。

3. 材质

要点	说明
Landscape Material	特殊的材质，用 `Landscape Layer Blend` 等节点混合多个图层
Layer（图层）	每层一个 Weightmap；层数越多，开销与内存越大
Layer Info	每层的配置（物理材质、混合方式）
Virtual Texturing	大地形应配合虚拟纹理（World Partition 的 Minimap 也依赖它）

层数控制是地形材质优化的第一刀：每层都要存一份权重贴图，且着色时要采样多次。

4. 性能要点

项	影响
分辨率	顶点数、内存、构建时间
图层数	采样次数与内存
材质复杂度	每像素成本，全屏覆盖时尤其明显
阴影	地形参与 VSM 的成本；Nanite 地形可改善（见 Nanite）
LOD	远处地形的简化
Nanite 地形	官方提到 Nanite 可用于地形以改善性能，尤其配合虚拟阴影

5. 与 WP 的配合要点（已核实）

编辑器里世界初始未加载，只有 Is Spatially Loaded = false 的 Actor 会加载——地形通常应按空间加载
地形不支持延迟 proxy 创建的替代方案，因此 PSO 预缓存阶段必须等它加载完（见 PSO 预缓存中提到 landscape 不适合换默认材质或不渲染）
生成 HLOD 与导航数据可用 Builder commandlet，不必整体加载世界

6. 代价与权衡

设计	收益	代价	什么时候不该用
高分辨率	地形起伏精细	顶点、内存、构建时间	平缓地形不需要高分辨率
多图层	视觉丰富	采样与内存	层数应控制在必要范围
复杂材质	效果好	全屏覆盖时成本极高	远处应简化
Nanite 地形	免 LOD、配合 VSM 更好	平台限制（见 Nanite 篇）	移动端不可用
虚拟纹理	支持超大纹理	额外配置与内存	小地形不必

7. 踩坑与排查

坑	现象	怎么验证
地形很卡	分辨率/图层/材质过高	逐项降级对比
内存高	分辨率与图层数	检查 Weightmap 数量
远处地形闪烁/走样	LOD 或材质采样问题	调整 LOD 与纹理设置
阴影异常	VSM 缓存作废	见虚拟阴影贴图
首次进场景卡	地形加载 + PSO	见 PSO 篇（地形不支持换默认材质的延迟策略）
多人编辑冲突	地形不是 OFPA 友好的	地形通常整块，需规划编辑权限
材质绘制丢失	Layer Info 引用丢失	检查 Layer Info 资产
打包后地形不对	Cook 问题	WP 地图要用 Cook commandlet

8. 排查顺序

1. 卡？→ 降分辨率 → 降图层 → 降材质复杂度（按此顺序对比）
2. 内存高？→ 分辨率 + Weightmap 数量
3. 远景问题？→ LOD / 材质 LOD / 虚拟纹理
4. 阴影？→ VSM 篇
5. 加载卡？→ PSO 预缓存 + WP 流式

参考

World Partition · HLOD · Foliage 与植被
Nanite · 虚拟阴影贴图 · PSO 预缓存