做关卡的同学大概都遇到过这种拉扯：美术想要起伏有节奏的悬崖和怪石，程序想要可预测的碰撞和稳定的帧率，而地形系统往往只能满足其中一边。传统高度图地形在表现力上总会撞到天花板，而在大世界项目里，地形又必须和流式加载、渲染批次、物理精度绑在一起考虑。围绕 Unreal Fest Chicago 上「Introducing Mesh Terrain」这个主题，本文把网格化地形相关的概念、原理、落地流程和踩坑点整理成一套可以照着做的技术笔记，覆盖从数据准备、网格生成、材质分层到性能验收的完整链路。不管你是刚接触 UE 地形的新手，还是已经在做开放世界的开发者，读完之后都应该能独立搭出一块自己的网格地形，并且知道该在哪里设预算、在哪里留后手。

需要先说明一点：引擎的地形相关功能迭代很快，具体菜单路径、参数名称、模块开关注定会随版本变化。本文重点讲的是思路和可复用的实现方式，代码示例以通用 API 为主，落到你的工程里时请按实际引擎版本核对。

1. Mesh Terrain 是什么：从高度图地形到网格化地形的转变

1.1 传统 Landscape 的工作方式与局限

Unreal 的 Landscape 系统本质上是「规则网格 + 高度图」。它把一块地形切分成固定大小的组件（Component），每个组件记录一张高度图，渲染时根据距离选择不同的 LOD 层级。这套方案的优点是内存占用可控、编辑起来直观、碰撞生成成熟，很多项目用它做几十平方公里的野外场景都没问题。

但局限也很明显。第一是拓扑固定：整块地形永远是规则的四边形网格，你没法让悬崖底部自动加密、让平缓草地自动稀疏，想要表现倒悬的岩壁、洞穴顶面、桥洞这类非高度场结构，高度图本身表达不了。第二是精度上限：高度图是 16 位左右的采样，垂直分辨率有限，做几十米高的垂直落差时容易出现台阶感。第三是渲染路径独立：Landscape 有自己的着色器和 LOD 机制，和 Nanite、虚拟纹理这些新渲染特性配合时需要额外适配，材质复杂度一高就容易掉帧。

正因为这些限制，很多团队在做岩层、峡谷、废墟这类「靠造型吃饭」的场景时，会绕开 Landscape，改用静态网格体（Static Mesh）手工摆放。代价是工作量大、无法程序化、后期改地形等于重做。

1.2 Mesh Terrain 的核心思路

Mesh Terrain 的思路可以概括成一句话：把地形从「一张高度图」变成「一组可渲染的网格」，让地形重新回到几何体的范畴里。

这样一来，地形就继承了网格体的全部能力：可以用 Nanite 做高密度渲染，可以用顶点色做混合遮罩，可以用任意拓扑表达非高度场结构，可以按需加密或稀疏三角形。同时它还保留了地形系统该有的东西——程序化生成、分层混合、流式加载、碰撞生成。

这里需要区分两个容易混淆的概念。一个是「网格化地形数据」，指的是地形在内存中的表达方式，可能是高度场转出来的网格，也可能是体素、稀疏体素八叉树或者直接建模得到的网格。另一个是「网格地形渲染」，指的是这些网格怎么画出来。两者可以独立选择：你可以用高度场生成数据，但用 Nanite 渲染；也可以用体素生成数据，退回传统静态网格体渲染。搞清这层关系，后面配置参数时就不容易懵。

1.3 适用场景与选型建议

不是所有项目都需要 Mesh Terrain。下面这张表可以作为选型参考：

从影响范围看，切到 Mesh Terrain 之后，受影响的不只是渲染。美术的工作流会从「刷地形笔刷」变成「调参数 + 修网格」，关卡设计需要重新学习流式加载单元（Cell）的划分逻辑，程序则要接手地形生成管线、碰撞策略和性能监控。也就是说，这是一次跨岗位的流程调整，不只是换个组件那么简单。

2. 环境准备与版本说明

2.1 引擎版本与硬件要求

网格地形依赖 Nanite、虚拟纹理、World Partition 这几套能力，所以引擎版本不能太老。本文示例基于 UE5 系列的通用 API 编写，具体小版本请以你团队实际使用的版本为准，不要照抄某个版本号。如果你的项目还在 UE4，建议先确认 Nanite 是否可用，否则要退回传统渲染路径，性能收益会打折扣。

硬件方面，编辑期生成网格地形对内存和 CPU 压力较大。建议：

• 内存 32GB 起步，做十平方公里级别的场景建议 64GB。
• 显卡支持 DX12 或 Vulkan，且显存 8GB 以上，Nanite 和虚拟纹理都吃显存带宽。
• 固态硬盘，地形数据和虚拟纹理缓存频繁读写。
• CPU 核心数对程序化生成速度影响明显，多线程采样能省下大量等待时间。

2.2 必开插件与项目设置

创建项目后，先在「编辑 → 插件」里确认几个能力已开启。不同版本的名字可能略有差异，按功能搜索即可：

• Geometry Script（几何脚本）：用于在编辑器或运行时程序化构建网格。
• Modeling Tools Editor Mode：方便手动修补生成结果。
• Water / Landmass 相关插件：如果地形要和水面、生物群系配合，按需开启。

项目设置里，渲染部分建议确认以下几项。可以直接改Config/DefaultEngine.ini：

[/Script/Engine.RendererSettings] ; 开启 Nanite，网格地形的高密度渲染依赖它 r.Nanite=True r.Nanite.ProjectEnabled=True ; 开启虚拟纹理，用于大面积地表分层混合 r.VirtualTextures=True ; 生成网格距离场，用于 Lumen 的软阴影和环境光遮蔽 r.GenerateMeshDistanceFields=True ; 允许在静态网格体上使用虚拟纹理 r.VirtualTexture=True

改完重启编辑器生效。这里每一项都不是「开了就更好」，比如距离场会显著增加构建时间和内存占用，如果你的项目不用 Lumen，可以先关掉。

2.3 示例项目结构

为了让后面的代码有明确落点，先约定一个最小工程结构：

MeshTerrainDemo/ ├── Config/ │ ├── DefaultEngine.ini │ └── DefaultGame.ini ├── Content/ │ ├── Meshes/ │ │ └── SM_TerrainTile.uasset │ ├── Materials/ │ │ └── M_TerrainLayer.uasset │ └── Maps/ │ └── L_TerrainDemo.umap ├── Source/ │ ├── MeshTerrainDemo.Target.cs │ ├── MeshTerrainDemoEditor.Target.cs │ └── MeshTerrainDemo/ │ ├── Public/ │ │ └── MeshTerrainGenerator.h │ └── Private/ │ └── MeshTerrainGenerator.cpp └── MeshTerrainDemo.uproject

SM_TerrainTile就是一块基础地形瓦片，本文示例用一个 100×100 单位、带轻微起伏的平面网格体代替，重点是演示拼接逻辑，实际项目中你可以换成任意形状。

3. 核心原理拆解：网格地形的五个关键环节

3.1 数据源：高度场、遮罩与分层信息

不管最终表现成什么样，地形总得有个数据来源。常见的有三类：

第一类是高度场。用噪声函数、真实高程数据或者美术手绘的高度图，得到每个采样点的高度值。这是最接近传统地形思维的方式，迁移成本最低。

第二类是分层遮罩。除了高度，还需要知道「这块地方是草地还是岩石」「这里坡度多大」「离水多远」。这些信息通常用多张遮罩图或者顶点属性存储，材质里拿来做混合。

第三类是结构信息。悬崖、洞穴、桥洞这类非高度场结构，需要额外的描述数据，比如一段样条曲线加一个剖面，或者一块手工雕刻的网格。

工程上比较务实的做法是：高度场和遮罩用程序化生成加手动修整，结构体用手工建模穿插进去。不要指望全程序化能一次到位，那类项目最后往往卡在美术验收上。

3.2 网格化：从高度场到 Nanite 网格

有了高度场，下一步是把它变成网格。最直接的方法是规则网格三角化：把地形切成 N×N 的格子，每个格子的四个角采样高度，生成两个三角形。伪代码如下：

for y in 0..N-1: for x in 0..N-1: h00 = Height(x, y) h10 = Height(x + 1, y) h01 = Height(x, y + 1) h11 = Height(x + 1, y + 1) 生成三角形 (h00, h10, h11) 和 (h00, h11, h01)

这种方法简单可靠，但三角形数量随分辨率平方增长。64×64 的格子就有 8192 个三角形，256×256 就是 13 万个。这时候 Nanite 就派上用场了：它可以在渲染时自动做层级剔除和几何压缩，把远距离的三角形开销压下去。

真正需要动脑筋的是「自适应细分」。平坦区域可以用大三角形，起伏剧烈的区域需要小三角形。判断依据通常是曲率或者高度差，超过阈值的格子递归四分。这本质上是四叉树细分，实现时要控制最大深度，否则悬崖附近可能生成几十万个三角形。

3.3 材质与分层混合

网格地形的材质和普通模型材质没有本质区别，区别在于混合逻辑。因为你可能只有一张材质，却要表现草地、岩石、沙地三种表面。

主流做法是用虚拟纹理做运行时混合。思路是：把地形高度、法线、若干遮罩渲染到一张运行时虚拟纹理（Runtime Virtual Texture）里，材质采样这张纹理得到混合权重，再叠细节贴图。好处是混合成本与地形面积无关，只看屏幕像素，大场景下非常划算。

需要注意的坑是虚拟纹理的分辨率和覆盖范围要匹配。范围设得太大分辨率跟不上，地表会糊；太小又会出现明显的块状边界。经验值是按「每米 1 到 4 个纹素」估算，先粗后细调。

3.4 碰撞与物理

这是最容易被低估的环节。渲染用的是 Nanite 高模，物理不可能也用同一份数据，否则内存和 CPU 都撑不住。

常见的分层策略是：

• 渲染层：Nanite 网格，三角形数量可以很高。
• 碰撞层：简化后的凸包或者低模，用简单碰撞（Simple Collision）代替复杂碰撞。
• 查询层：如果需要精确的射线检测（比如子弹落点），单独维护一份中等精度网格，走LineTraceSingleByChannel时命中它。

如果你发现角色会陷进地面或者悬空，第一反应应该是检查碰撞层和渲染层是否错位，而不是去调渲染参数。

3.5 流式加载与大世界

大世界项目里，地形不可能一次性全部加载。World Partition 会把世界切分成格子（Cell），按玩家位置流式加载。网格地形要接入这套机制，需要保证两点：生成逻辑是幂等的（同样的输入永远得到同样的输出），以及每个格子的数据能独立加载。

幂等性靠固定随机种子实现。如果你用FMath::Rand()之类的全局随机，格子重新加载后地形会变形，这种 bug 极难排查。统一用基于坐标的确定性噪声，问题就没了。

4. 完整实战：用 C++ 生成一块程序化网格地形

这一节我们把上面的思路落地。目标是用一个 Actor 在编辑器里一键生成网格地形，并且能实时调整参数看到效果。

4.1 创建 C++ Actor 类

在编辑器里选择「工具 → 新建 C++ 类」，父类选 Actor，命名为MeshTerrainGenerator。生成后你会得到头文件和源文件，下面直接给出完整内容。

先看头文件：

// 文件路径：Source/MeshTerrainDemo/Public/MeshTerrainGenerator.h #pragma once #include "CoreMinimal.h" #include "GameFramework/Actor.h" #include "MeshTerrainGenerator.generated.h" class UInstancedStaticMeshComponent; class UStaticMesh; UCLASS() class MESHTERRAINDEMO_API AMeshTerrainGenerator : public AActor { GENERATED_BODY() public: AMeshTerrainGenerator(); /** 地形格子的行列数，64 表示 64x64 个瓦片 */ UPROPERTY(EditAnywhere, Category = "MeshTerrain|Grid", meta = (ClampMin = "2", ClampMax = "512")) int32 GridSize = 64; /** 单个瓦片的世界尺寸，单位厘米 */ UPROPERTY(EditAnywhere, Category = "MeshTerrain|Grid", meta = (ClampMin = "50.0")) float CellSize = 200.f; /** 整体高度缩放，值越大起伏越夸张 */ UPROPERTY(EditAnywhere, Category = "MeshTerrain|Height") float HeightScale = 2000.f; /** 噪声频率，值越小地形越平缓 */ UPROPERTY(EditAnywhere, Category = "MeshTerrain|Height", meta = (ClampMin = "0.0001")) float NoiseScale = 0.03f; /** 噪声偏移，用于生成不同但可复现的地形 */ UPROPERTY(EditAnywhere, Category = "MeshTerrain|Height") float NoiseSeed = 0.f; /** 用来铺地的瓦片网格体，建议开启 Nanite */ UPROPERTY(EditAnywhere, Category = "MeshTerrain|Assets") TObjectPtr<UStaticMesh> TileMesh; UPROPERTY(VisibleAnywhere, Category = "MeshTerrain|Components") TObjectPtr<UInstancedStaticMeshComponent> TileInstances; UFUNCTION(CallInEditor, Category = "MeshTerrain") void GenerateTerrain(); UFUNCTION(CallInEditor, Category = "MeshTerrain") void ClearTerrain(); protected: virtual void BeginPlay() override; private: float SampleHeight(float X, float Y) const; };

几个设计点说明一下。GridSize限制了上限 512，防止有人在编辑器里手滑填个 4096 直接把编辑器卡死。CallInEditor让这两个函数出现在细节面板上，不用运行游戏就能触发生成。TileInstances作为根组件，这样生成的所有瓦片都挂在同一个组件下，方便统一管理。

4.2 实现生成逻辑

源文件如下：

// 文件路径：Source/MeshTerrainDemo/Private/MeshTerrainGenerator.cpp #include "MeshTerrainGenerator.h" #include "Components/InstancedStaticMeshComponent.h" #include "Engine/StaticMesh.h" AMeshTerrainGenerator::AMeshTerrainGenerator() { PrimaryActorTick.bCanEverTick = false; TileInstances = CreateDefaultSubobject<UInstancedStaticMeshComponent>(TEXT("TileInstances")); RootComponent = TileInstances; // 静态移动性让实例可以被静态合批，减少 DrawCall TileInstances->SetMobility(EComponentMobility::Static); TileInstances->SetCollisionEnabled(ECollisionEnabled::QueryAndPhysics); } void AMeshTerrainGenerator::BeginPlay() { Super::BeginPlay(); } float AMeshTerrainGenerator::SampleHeight(float X, float Y) const { // 基于世界坐标采样噪声，保证同一位置永远得到同一高度 const float NoiseX = (X + NoiseSeed) * NoiseScale; const float NoiseY = (Y + NoiseSeed) * NoiseScale; // PerlinNoise2D 返回值范围约为 -1 到 1 const float Base = FMath::PerlinNoise2D(FVector2D(NoiseX, NoiseY)); // 叠加一层高频细节，避免大块地形过于圆滑 const float Detail = FMath::PerlinNoise2D(FVector2D(NoiseX * 4.f, NoiseY * 4.f)) * 0.25f; return (Base + Detail) * HeightScale * 0.5f; } void AMeshTerrainGenerator::ClearTerrain() { if (TileInstances) { TileInstances->ClearInstances(); } } void AMeshTerrainGenerator::GenerateTerrain() { if (!TileInstances || !TileMesh) { UE_LOG(LogTemp, Warning, TEXT("MeshTerrainGenerator: 请先指定 TileMesh")); return; } TileInstances->ClearInstances(); TileInstances->SetStaticMesh(TileMesh); // 让地形以 Actor 原点为中心分布 const float HalfExtent = (GridSize - 1) * CellSize * 0.5f; for (int32 Y = 0; Y < GridSize; ++Y) { for (int32 X = 0; X < GridSize; ++X) { const float WorldX = X * CellSize - HalfExtent; const float WorldY = Y * CellSize - HalfExtent; const float WorldZ = SampleHeight(WorldX, WorldY); const FVector Location(WorldX, WorldY, WorldZ); const FRotator Rotation = FRotator::ZeroRotator; // 瓦片原始尺寸按 100 单位见方设计，这里按 CellSize 缩放 const float UniformScale = CellSize / 100.f; const FVector Scale(UniformScale, UniformScale, 1.f); TileInstances->AddInstance(FTransform(Rotation, Location, Scale)); } } UE_LOG(LogTemp, Log, TEXT("MeshTerrainGenerator: 已生成 %d 个瓦片"), TileInstances->GetInstanceCount()); }

几个关键细节有必要展开：

SampleHeight用的是世界坐标而不是局部索引。区别很重要：用索引的话，两块相邻地形拼接时边界处噪声不连续，会出现明显断层；用世界坐标则天然连续。

垂直缩放固定为 1，水平缩放按CellSize变化。这是为了让瓦片保持真实高度，避免地形被压扁。如果你希望瓦片在垂直方向也跟着拉伸，可以改成CellSize / 100.f，但那样噪声高度就要相应减小。

AddInstance每调用一次就多一个实例。实例化静态网格体的优势是把几百上千个相同网格合并成一次绘制调用，代价是所有实例共享同一份材质参数，没法给单个瓦片单独换材质。如果你的地形需要逐块换材质，得换成多个组件。

4.3 在编辑器中运行验证

编译完成后，把 Actor 拖进关卡，在细节面板里指定TileMesh，然后点GenerateTerrain。预期结果是场景中心出现一片由瓦片拼成、高低起伏的地形。

如果瓦片之间有缝隙，通常是两个原因：一是瓦片网格体本身不是严格 100 单位见方，缩放后尺寸对不上；二是CellSize设置和瓦片实际尺寸的比例不匹配。排查方法是把所有瓦片缩放临时设成 1，用正交视图放大看边界。

如果地形看起来「太光滑」，把NoiseScale调大，或者增加噪声叠加层数。反过来觉得太碎，就调小。NoiseSeed换个值就能得到完全不同但同样可复现的地形，适合快速出多个方案。

4.4 从瓦片拼接升级到连续网格

上面的做法适合快速验证，但要做正式地形，最好直接生成一整块连续网格。思路是用UDynamicMesh配合 Geometry Script 构建三角形，再转换成动态网格组件。核心逻辑是把 3.2 节里的三角化伪代码翻译成循环：

// 核心片段示意：构造连续地形网格的顶点与三角形 // 需引入 GeometryFramework 与 GeometryScriptingCore 模块 void BuildTerrainMesh(UDynamicMesh* TargetMesh, int32 Resolution, float CellSize) { TArray<FVector> Vertices; TArray<FIndex3i> Triangles; // 顶点：多生成一行一列，保证最后一行/列也有闭合点 for (int32 Y = 0; Y <= Resolution; ++Y) { for (int32 X = 0; X <= Resolution; ++X) { const float WX = X * CellSize; const float WY = Y * CellSize; const float WZ = SampleHeight(WX, WY); Vertices.Add(FVector(WX, WY, WZ)); } } const int32 RowStride = Resolution + 1; for (int32 Y = 0; Y < Resolution; ++Y) { for (int32 X = 0; X < Resolution; ++X) { const int32 I00 = Y * RowStride + X; const int32 I10 = I00 + 1; const int32 I01 = I00 + RowStride; const int32 I11 = I01 + 1; // 注意三角形绕序，逆时针为正面 Triangles.Add(FIndex3i(I00, I10, I11)); Triangles.Add(FIndex3i(I00, I11, I01)); } } // 实际项目中通过 Geometry Script 的 AppendTriangles 等接口写入 TargetMesh }

这段是核心片段，需要放进你实际的构建函数里，并补充 Geometry Script 的写入调用。绕序（Winding Order）是最容易出错的地方，绕反了会出现地形整体不可见或者法线朝内，表现为「从上面看得见、从下面也看得见」的诡异现象。

5. 材质与渲染要点

5.1 分层材质的设计原则

材质设计要优先级明确：先定颜色基调，再加细节，最后加特效应答。顺序反了会导致后期改一个参数引发连锁反应。

实践中比较稳的结构是三层：

第一层是基础色，用虚拟纹理采样得到草地、岩石、沙地的权重，混合出底色。第二层是细节法线，按屏幕空间或者世界空间叠加，避免近距离看地图像塑料布。第三层是特殊材质，比如湿润反光、积雪光泽，用遮罩控制范围。

关键参数是虚拟纹理的分辨率和覆盖范围。原则是让一个纹素对应 25 到 100 平方厘米，太粗会糊，太细显存吃紧。

5.2 Nanite 与地形网格的配合

Nanite 对地形这类大面积、高密度的几何体收益非常明显，但有几个限制要提前知道。

一是材质不能随意用顶点位移来改变轮廓，Nanite 的几何是预处理的，运行时的顶点动画支持有限。如果你的地形需要风吹草动那种逐顶点动画，建议拆成两层：地形本体用 Nanite，植被用实例化网格体。

二是遮蔽剔除的精度。Nanite 自带的剔除基于软件光栅，开启后要注意阴影的出现与消失是否有跳变。如果在开阔场景里看到阴影突然切块，先检查阴影缓存和级联阴影的配置。

三是显存占用。高密度网格 + 虚拟纹理 + 距离场三者叠加，显存消耗会成倍上升。做性能验收时要把这三项一起压测，不要单独看。

5.3 光照与阴影的注意事项

网格地形的表面法线比高度图地形更尖锐，光照结果会更「硬」。这不是 bug，但美术往往需要时间适应。缓解方式是给材质加一层法线平滑，或者用更柔和的光照方案。

阴影方面，地形是最容易暴露出阴影瑕疵的几何体，因为它面积大、起伏多、观察角度刁钻。常见的三个问题：

• 阴影痤疮（Shadow Acne）：表面出现条纹状自阴影。解决思路是调大阴影偏移，或者缩小阴影贴图覆盖范围。
• 阴影漏光（Peter Panning）：物体和地面接触处阴影断开。和上一条是矛盾关系，需要找平衡点。
• 远处阴影闪烁：级联阴影的过渡区间没调好，或者距离场精度不够。

6. 常见问题与排查清单

6.1 地形出现接缝或裂缝

现象是相邻瓦片之间有细缝，凑近看能看到背景。常见原因有三个：瓦片网格体的边界不是严格对齐的、缩放计算有浮点误差、或者瓦片的枢轴点（Pivot）不在几何中心。

排查顺序建议：先把所有瓦片的缩放统一改成整数倍，观察缝隙是否消失；如果还在，用几何体对齐工具检查瓦片的本地包围盒是否从 -50 到 +50；最后检查位置计算里的HalfExtent有没有算错。浮点误差在坐标超过十万单位后会变得明显，超大世界要考虑用世界原点偏移（World Origin Rebasing）。

6.2 角色穿模或悬空

这几乎总是碰撞层的问题。先确认渲染网格体上有没有启用碰撞，再看碰撞复杂度是「使用简单碰撞作为复杂碰撞」还是「使用复杂碰撞作为简单碰撞」。前者性能好但精度差，后者精度高但开销大。

排查技巧：在视口里打开碰撞可视化（Show Collision），角色脚下的碰撞体会直接画出来，一眼就能看出是悬空还是下陷。如果碰撞体明显比视觉模型粗糙，说明用了简化碰撞，这时候要么调精细度，要么接受这个精度。

6.3 帧率骤降或显存飙红

网格地形最容易在三处出问题：三角形数量、材质指令数、虚拟纹理分辨率。

用stat unit看瓶颈在 Game、Draw 还是 GPU。如果是 GPU，再开stat gpu看具体是 Base Pass、Shadow 还是 Lumen。这种分层排查能省下大量瞎猜时间。

显存用stat memory或者编辑器里的 MemReport 看。虚拟纹理的显存占用和它的分辨率直接相关，如果发现几 GB 的占用，先把虚拟纹理尺寸降一半试试。

6.4 常见问题速查表

7. 最佳实践与工程建议

7.1 参数集中管理与数据驱动

地形生成的参数（分辨率、噪声种子、高度缩放、遮罩分布）不要散落在几十个 Actor 实例上。推荐抽成一个UPrimaryDataAsset子类，集中配置，Actor 只负责读取并执行。这样做的好处是换方案只需要换一个资产，版本对比时也能清楚看到改了哪个参数。

同时，所有参数都应该有合理默认值和范围限制。ClampMin和ClampMax这类元数据看着不起眼，实际上能挡掉大量「编辑器崩了」的工单。

7.2 命名与资产规范

地形资产建议按类型_场景_细分命名，例如SM_TerrainTile_Cliff、M_TerrainLayer_Grass。前缀保持和团队现有规范一致，别为了这事另起一套。

版本控制方面，地形生成参数、噪声种子、遮罩图都要进仓库。最容易出的事故是「美术本地调了个参数觉得好看，但没提交，别人拉下来生成的地形完全不同」。解决办法是把参数资产和预览图一起提交，并且在构建流程里加一步自动生成截图做对比。

7.3 团队协作中的分工边界

网格地形落地后，程序、美术、关卡三方的职责需要重新划一下，否则很容易互相等待。

程序负责：生成管线、参数接口、碰撞策略、性能监控。美术负责：材质分层、遮罩绘制、网格修补。关卡负责：地形分块规划、远景和近景的衔接、流式加载单元划分。

一个实用的做法是提供「一键生成 + 一键对比」工具，让关卡设计能在不改代码的前提下调整参数看效果。这类工具投入产出比很高，能显著减少美术和程序之间的来回沟通成本。

7.4 性能预算与验收标准

上线前最好明确几条硬性指标，让优化有依据。参考数值如下，具体按目标平台调整：

• 地形在任意视角下的三角形数量不超过预设上限，超出时用 Nanite 或降精度解决。
• 地形相关的 DrawCall 控制在合理范围，瓦片拼接方案要确保静态合批生效。
• 显存占用给虚拟纹理和距离场留出明确配额，超出即视为不合格。
• 最低配置设备上，地形区域的平均帧时间不超过整帧预算的三成。

这些指标应该在项目中期就定下来，而不是等到上线前才发现没法优化。地形是最难「事后优化」的模块，因为它的性能问题和内容制作深度绑定。

8. 写在最后：下一步可以做什么

把上面的内容串起来，其实就是一条完整的链路：用确定性噪声生成高度场，用三角化或自适应细分把高度场变成网格，用实例化或 Nanite 把网格高效渲染出来，用虚拟纹理做分层混合，用简化碰撞体承接物理查询，最后用性能预算把这套东西约束在可交付范围内。每一步单独看都不复杂，难的是让它们协同工作，并且在团队里形成可重复的流程。

如果想继续深入，有三个方向值得投入时间。一是研究四叉树细分算法，搞清楚曲率驱动的自适应细分怎么实现，这决定了悬崖和洞穴的表现上限。二是动手写一版地形编辑笔刷，理解从「程序化生成」到「手工修整」的数据回流方式，这是实际项目里绕不开的环节，因为纯程序化几乎不可能直接过美术验收。三是把性能分析工具用熟，尤其是 GPU 侧的分项统计，网格地形的问题往往藏得很深，靠猜往往徒劳无功。

最后提醒一句：如果你打算在现有项目里引入网格地形，先在独立的测试关卡里跑通全流程，验证碰撞、光照、流式加载、性能都符合预期，再考虑迁移正式场景。地形系统的改动影响面大，且一旦出问题会在所有场景里同时暴露，稳妥推进比一步到位更重要。