简介面向Unity URP开发者的GPU Driven地形渲染可运行源码包聚焦大世界开放场景中地形剔除、LOD选择与间接实例化渲染等核心难题。包内共3个文件以HTML演示页面、inscode工程配置及gitignore规则文件为主压缩包仅7KB轻量易部署适合已有一定渲染基础的开发者快速对照验证。目前已有104人学习下载。源码展示了地形分块与数据组织、GPU剔除与LOD选择、Indirect Instanced Rendering及URP自定义Pass集成的实现思路并通过伪代码与关键实现建议帮助读者理解Android适配要点、源码结构设计与性能优化方向。借助这份可运行示例开发者可边看边跑将理论落地到实际项目中少走弯路快速掌握GPU Driven地形渲染的完整流程。1. GPU Driven地形渲染在解决什么问题GPU Driven地形渲染不是某一个算法而是把地形调度权从CPU移交到GPU的一条完整管线。传统地形系统里CPU每一帧要遍历四叉树、对成百上千个地形块做视锥剔除、按距离切换LOD再逐个提交Draw Call到了几平方公里的场景一次地形Pass就是几千次提交CPU被地形调度拖慢GPU却时常闲着。GPU Driven的方向是反过来让GPU自己完成裁剪、选LOD并把结果写进间接绘制参数CPU每帧只提交一次绘制调用。这套方案适合被Draw Call和CPU调度帧时间卡住的大世界场景也适合想长期积累场景渲染能力的引擎底层开发者和图形程序。拿到可运行源码之后最容易踩的坑是“能跑就行”——Shader里的每段逻辑都关系到画面正确性参数写错就会出现接缝、漏画和性能回退。这篇会从数据组织讲到间接绘制命令生成再把参数和避坑点逐条摆出来让你可以照着推进。2. 核心思路从CPU调度到GPU调度的三层重构2.1 传统地形渲染的瓶颈到底在哪传统地形渲染大多是四叉树驱动。每一帧CPU先根据相机位置找到根节点递归往下遍历对每个节点做视锥剔除计算节点到相机的距离按距离选中一个LOD等级再把该节点对应的顶点索引拼进渲染命令最后提交图形API。节点数量按四叉树的层数指数膨胀一个8层四叉树有两万多个候选节点即使可见的只是其中一部分CPU每帧也要遍历全部候选才能得出答案这个成本会随着视野距离明显上升。更麻烦的是地形块通常不会只用一个LOD等级。每个块内部会预生成好几套不同分辨率的网格CPU要从中挑一个合适的。块多、遍历重再加上图形API对提交次数的限制地形就稳坐CPU耗时的前几名。移动端更明显——CPU核少、频率低一次地形Pass的CPU耗时经常能占到整帧的40%以上。我见过一些团队把Tile切得很小、LOD层次做得很细想靠更细腻的网格让画面更好看结果Draw Call暴涨画面确实细了帧率却没了。这里有个常被忽略的点GPU Driven解决的是提交次数和CPU调度不是三角形数量本身。如果三角形本来就不是瓶颈它的价值会打折扣。所以动手之前先确认当前地形Pass确实CPU受限再决定走这条路。2.2 地形离线数据Tile高度图与节点StructuredBufferGPU能在端侧做裁剪前提是地形在离线阶段被切成固定尺寸的Tile并且每个Tile的元数据全部压进一个StructuredBuffer让Compute Shader可以直接读。常见做法是把地形高度场切成正方形PatchPatch边长通常取32到128个世界单位每块内部再预生成一组LOD网格。每个地形节点的元数据至少要包含下面这些字段缺一个后面写Shader都要补字段含义center节点中心的世界坐标extent半边长用来快速构建包围球minHeight / maxHeight节点的垂直范围做包围盒与遮挡剔除时要算lodBase节点在LOD索引缓冲里的起始位置meshIndex该节点使用的网格资源IDparent父节点索引GPU端由子找父时要用高度图本身按Tile存储每个Tile一张高度纹理必要时再生成法线和AO。节点里的minHeight/maxHeight不是每帧去采样高度图而是离线阶段由高度图降采样得到的。这样遮挡剔除不用访问高度图直接拿一个轴向包围盒就能算。很多刚上手的人会把节点数组放在CPU可读的内存里每帧再上传结果GPU虽然在做剔除数据却要从CPU搬运损耗立刻就回来了。正确做法是初始化阶段一次性建好StructuredBuffer之后每帧只更新视锥体平面、相机位置等几个常量节点数据本身保持不变。这一层的组织决策会直接影响后面所有Shader的写法也是最值得先花时间想清楚的地方。2.3 间接绘制如何把Draw Call削下来理解数据组织之后再看间接绘制逻辑就顺了。间接绘制Indirect Draw的意思是渲染命令的参数不再由CPU在调用时给出而是放在GPU侧的缓冲里由GPU自己填写。地形渲染里CPU每一帧只调用一次DrawIndexedIndirect传一个参数缓冲和一个实例缓冲参数缓冲Indirect Args告诉图形API要画多少个实例、每个实例用多少索引、从哪里开始实例缓冲Instance Buffer每个实例的变换信息、LOD等级、节点索引等数据。GPU端跑两个Compute Shader前一个负责裁剪和选LOD把可见节点写进一个VisibleList后一个根据VisibleList生成上面两个缓冲。最后CPU提交一次间接绘制调用。整个地形Pass的CPU提交成本基本恒定跟场景里有多少块地形无关。听起来简单但有一个容易踩的细节间接绘制要求参数缓冲里的内容在正确的时间点对后续阶段可见。前一个Compute Shader写完参数后必须先通过Memory Barrier让后续Draw阶段能读到它否则画出来的内容要么缺块要么是上一帧的旧数据。这类Bug在帧调试器里通常表现为“画面缺一块动一下又好了”排查起来很烧时间。2.4 什么时候不该用GPU Driven这套方案不是银弹。如果你的地形范围只有几百米见方可见Tile可能不到一百个CPU四叉树遍历原本就只用不到一毫秒那GPU Driven带来的收益就非常有限反而要承担额外的Dispatch和Barrier开销。或者你的地形里大量区域是平的三角形数极少瓶颈在填充率而非提交次数这种情况下优化方向应该转向纹理和着色器复杂度而不是调度方式。还有一个实际问题移动端对StructuredBuffer和间接绘制的支持层次不齐部分GPU驱动对间接绘制的优化并不到位。团队里如果缺少会用图形调试器的人建议先在PC端验证收益再决定是否下沉到移动端。总之先量瓶颈再选方案比选完方案再找理由更重要。3. 把可运行源码跑起来从工程结构到间接绘制命令3.1 拿到源码后先看哪三个文件一份以可运行源码为目标的地形Demo无论底层用哪套图形API工程结构通常都绕不开三块地形数据生成部分、Compute Shader目录、提交渲染命令的主循环。我拿到手之后不急着编译先找这三个位置看一遍。地形数据生成代码决定Tile怎么切、高度图怎么进缓冲Shader目录里必然有一个裁剪用的Compute Shader和一个生成间接命令用的Compute Shader主渲染循环里能看到CPU提交路径和Memory Barrier的布局。跑第一次之前建议先把当前版本的Draw Call数量、三角形数量和GPU帧时间记录下来后面所有调整都拿这三个数据做基准。没有基准就调参基本等于玄学。3.2 四叉树节点缓冲的构建方式节点数组在离线阶段生成之后一次性上传给GPU。下面这段构建逻辑不依赖任何第三方库核心是“按深度平铺数组”每一层的节点在内存里连续存放// 按深度平铺的四叉树节点生成示意 std::vectorPatchInfo nodes; nodes.reserve((1u (2 * (MaxDepth 1))) / 3); PatchInfo root; root.center float3(0.f, 0.f, 0.f); root.extent worldSize * 0.5f; root.minHeight 0.f; root.maxHeight GetTerrainHeight(worldSize * 0.5f); root.parent 0xFFFFFFFFu; // 根节点没有父节点 nodes.push_back(root); for (uint depth 1; depth MaxDepth; depth) { uint parentStart (1u (2 * (depth - 1))) - 1; uint parentCount 1u (2 * (depth - 1)); for (uint p 0; p parentCount; p) { PatchInfo pa nodes[parentStart p]; float he pa.extent * 0.5f; float3 offsets[4] { float3(-he, -he, 0.f), float3( he, -he, 0.f), float3(-he, he, 0.f), float3( he, he, 0.f) }; for (uint q 0; q 4; q) { PatchInfo child; child.center pa.center offsets[q]; child.extent he; child.parent parentStart p; child.minHeight QueryMinHeight(child.center, he); child.maxHeight QueryMaxHeight(child.center, he); nodes.push_back(child); } } }把节点按层连续存放的原因很直接GPU端的线程ID可以直接映射到数组下标并且不需要链表指针。四叉树每一层的节点数量可以用公式 4 的 depth 次方直接算出来完全不需要遍历上级节点。如果改用链表布局线程访问时缓存命中率会变差移动端尤其明显。参数说明MaxDepth 决定四叉树深度根节点表示整个地形范围每个子节点范围是父节点的一半。MaxDepth 一档多约四倍节点不是线性增长所以别为了远景细节无限加深。worldSize 不要小于Tile边长的两倍否则根节点范围过小LOD切分失去意义。这段代码里的 QueryMinHeight / QueryMaxHeight 是离线降采样函数不要在每帧调用否则又绕回了CPU瓶颈。3.3 GPU端裁剪与LOD选择节点数组上传后就可以在Compute Shader里做裁剪和选LOD了。下面是一段示意性质的Shader逻辑关键步骤是视锥剔除、距离式LOD选择、以及可选的Hi-Z遮挡剔除// 每个线程处理一个四叉树节点 StructuredBufferPatchInfo NodeBuffer; RWStructuredBufferVisibleNode VisibleList; RWStructuredBufferuint CountBuffer; // 可见列表计数 float4 frustumPlanes[6]; // 视锥体平面CPU每帧上传 float3 camPos; float LODDistanceScale; // 距离与LOD的换算比例 uint NodeCount; int MaxLOD; bool InFrustum(float3 center, float radius) { for (uint i 0; i 6; i) { if (dot(frustumPlanes[i].xyz, center) frustumPlanes[i].w -radius) return false; } return true; } [numthreads(64, 1, 1)] void CS(uint3 id : SV_DispatchThreadID) { uint n id.x; if (n NodeCount) return; PatchInfo node NodeBuffer[n]; float radius length(float3(node.extent, 0.f, (node.maxHeight - node.minHeight) * 0.5f)); if (!InFrustum(node.center, radius)) return; // 简化LOD选择用距离换算真实项目会换成屏幕空间误差 float dist distance(camPos, node.center) - radius; uint lod (uint)ceil(log2(max(1.f, dist / LODDistanceScale))); lod min(lod, (uint)MaxLOD); // 遮挡剔除查上一帧Hi-Z if (IsOccluded(node.center, radius, PrevHiZ)) return; uint slot; InterlockedAdd(CountBuffer[0], 1, slot); VisibleList[slot].nodeIndex n; VisibleList[slot].lod lod; }逻辑说明先做视锥剔除。CPU端把视锥体六个平面打包成float4数组上传Shader里逐平面做点积判断节点包围球与平面相交则继续。之后按距离粗略选LODdist / LODDistanceScale越小说明离相机越近LOD等级越低。这里的距离式选择只是示意真正的项目建议改用下一章讲的屏幕空间误差避免近处LOD过高或远处LOD过低。遮挡剔除放在视锥剔除之后因为Hi-Z查询比平面点积贵先视锥后遮挡能省下一批无效查询。IsOccluded可以是查上一帧深度降采样得到的Hi-Z纹理传包围球中心和半径进去返回是否被完全遮挡。如果节点刚从视锥外进入它的上一帧深度可能不存在此时最好直接放行这个细节放在避坑章节展开。参数说明LODDistanceScale越小切换LOD的距离越近远处走向低模越早MaxLOD决定最高细节等级一般取3到5就足够。CountBuffer[0]在每帧开始必须清零否则可见列表会越写越满最后写入到越界内存。3.4 生成间接绘制参数与实例数据剔除完成后还需要一个Shader把可见节点转换成间接绘制参数和实例数据RWStructuredBufferIndirectArgs Args; RWStructuredBufferInstanceData InstanceBuf; StructuredBufferVisibleNode VisibleList; uint VisibleCount; [numthreads(64, 1, 1)] void CS(uint3 id : SV_DispatchThreadID) { uint i id.x; if (i VisibleCount) return; VisibleNode v VisibleList[i]; PatchInfo n NodeBuffer[v.nodeIndex]; InstanceData inst; inst.nodeIndex v.nodeIndex; inst.lod v.lod; inst.worldOffset ComputePatchOffset(n.center); uint slot; InterlockedAdd(Args[0].instanceCount, 1, slot); InstanceBuf[slot] inst; }调用顺序很重要先跑裁剪Shader再跑参数生成Shader最后CPU提交间接绘制。两次Dispatch之间必须插入Memory Barrier确保第一次写出的VisibleList在第二次可读同时第二次写入的Args缓冲对后续Draw命令可见。OpenGL里是glMemoryBarrier(GL_COMMAND_BARRIER_BIT | GL_SHADER_STORAGE_BARRIER_BIT)换一套图形API时这部分写法差异很大最容易漏的就是这一步。注意不同图形API的内存屏障口径完全不同。Vulkan要同时指定SourceStage和DestStage其他图形API则有自己的UAV屏障别拿OpenGL的习惯直接套。CPU一帧的提交路径被压缩成三段// 帧开始时清空计数缓冲 glClearBufferSubData(GL_SHADER_STORAGE_BUFFER, 0, 0, sizeof(GLuint), GL_R32UI, GL_INT, 0, nullptr); glDispatchCompute((nodeCount 63) / 64, 1, 1); // 裁剪与选LOD glMemoryBarrier(GL_SHADER_STORAGE_BARRIER_BIT); glDispatchCompute((visibleCount 63) / 64, 1, 1); // 生成间接参数 glMemoryBarrier(GL_COMMAND_BARRIER_BIT); glDrawElementsIndirect(GL_TRIANGLES, GL_UNSIGNED_INT, 0); // 提交地形这里唯一的动态数据是可见计数但对CPU来说它仍然是GPU侧生成的。CPU不再知道这帧画了哪些块调度真正交还给了GPU。需要留意的是间接绘制和实例缓冲的绑定设置如果实例缓冲的stride和Shader里声明的不一致画面会出现三角形缺失或花屏后面避坑章节会专门说。3.5 从编译到看到渲染效果的四个步骤拿到源码后按固定顺序推进先跑通再改逻辑编译原版。确认没有报错记录帧时间和Draw Call作为基线。用GPU帧调试工具抓一帧。确认地形Pass只出现一次间接绘制实例数量符合预期。改裁剪参数比如最大深度、距离阈值观察帧率和画面的变化趋势。最后再改Shader算法每次只改一个变量记录对比数据。这个流程的核心是让改动可验证。GPU Driven的渲染结果不像CPU遍历那样直观帧调试工具是必需品。特别是第一次接入间接绘制时用它确认每次Draw的Instance数量是否由GPU正确生成。4. 参数怎么调Tile大小、LOD阈值、遮挡剔除三件套4.1 Tile大小决定了剔除粒度和Draw Call下限Tile大小是最先要定的参数因为它同时影响剔除粒度和GPU端节点数。Tile偏小视锥剔除的粒度细能裁掉更多三角形但GPU端要处理的节点数也多裁剪Shader的开销上升Tile偏大节点数少裁剪开销低但一些远离相机的块因为包围盒太大无法被剔除overdraw变多。我一般用两条经验规则来定单个Tile的三角形数控制在2k到8k之间可见Tile数量维持在几百到一两千的量级。以32×32网格算一个64世界单位的Tile大概产生1984个三角形比较合适。移动端可以把Tile再收小一点但不要低于32世界单位否则裁剪Shader的调度开销会反超收益。场景规模Tile边长建议说明2km×2km移动端32~64世界单位控制内存和裁剪开销8km×8km桌面端64~128世界单位优先压裁剪Shader时间超远视野20km128~256世界单位远处用低模近处单独加密Tile变大之后近景的细节可能会不够常见做法是把近处的Tile在离线阶段再细分一层而不是把全部Tile都切小。也就是混合分辨率近距Tile 32单位中距Tile 64单位远距Tile 128单位。这样既保住近景细节又控制总的节点数量。4.2 屏幕空间误差才是LOD切换的正解距离式选LOD在这个方案里够用但画面质量想再上一步就得换成屏幕空间误差。原理很简单地形网格的简化误差在屏幕上的像素数小于某个阈值时视觉上几乎看不出切换于是可以放心选更粗的网格。计算方法是对每个候选LOD求出世界空间误差再投影到屏幕像素选第一个低于阈值的等级float ComputeLodDistance(float worldError, float screenError, float tanHalfFov, uint viewportHeight) { // 屏幕像素误差 worldError * projectionScale / dist float projectionScale (viewportHeight * 0.5f) / tanHalfFov; return worldError * projectionScale / screenError; }世界误差是离线预计算好的可以存在PatchInfo里。每一帧按节点到相机的距离去查对应LOD比手动调log2系数精确很多。阈值建议从1.0像素起步调到0.5像素能明显减少边缘闪烁但可见三角形数也会同步上涨。我在一个模拟项目里把屏幕误差阈值从1.5像素收到0.75像素可见三角形从15万涨到28万帧时间从8ms升到11ms观感提升却很有限。所以阈值从1.0像素开始调根据自己项目的屏幕尺寸和GPU性能慢慢收不要一上来就追求最精细。4.3 Hi-Z遮挡剔除的Mip选择与滞后遮挡剔除值得做但前提是地形遮挡关系确实丰富。一望无际的平原显然不需要做。开启后有三个参数必须调查询的Hi-Z Mip等级、膨胀半径、是否使用上一帧深度。Mip等级取决于节点包围盒在屏幕上的投影大小。投影越大应该在越低的Mip里查询否则会漏掉本应被遮挡的节点。常见做法是估算包围盒的屏幕半径再选择对应的Mip等级。膨胀半径用来抵消半像素误差和深度偏移一般取1到2个像素。使用上一帧深度可以省掉额外的深度预Pass但会引入一帧延迟。快速转镜头时新进入视野的节点可能在上一帧深度里没有记录被误判为遮挡。这时需要在Shader里补一个保护条件上一帧不在视锥内的节点跳过遮挡测试。这个处理不能省省了就会遇到“转头时远处地形消失一瞬”的经典问题。4.4 三个观测指标Draw Call、三角形数、GPU耗时调参过程中最该看的是下面三个数据而不是最终帧率指标怎么看调参方向Draw Call帧调试工具正常应稳定在个位或十位可见三角形数帧调试工具过高则收紧LOD或加大Tile裁剪Shader耗时GPU时间戳超过0.5ms则应减少节点数这三个指标在调参之前必须记录。很多团队的GPU Driven优化最后没有被采纳是因为只看“帧率高了几帧”却没有记录可见三角形数和裁剪耗时导致后面出问题根本判断不了卡在哪。帧率是结果不是过程指标。4.5 一个具体调参顺序从10ms压到6ms假设基线是地形Pass 10ms网格点满帧调试器显示Draw Call有3400次。第一步把Tile从32单位放大到64单位节点数降低四倍Draw Call降到1000次地形Pass降到7ms。第二步把屏幕误差阈值从1.0像素放宽到1.5像素可见三角形数下降约三成Pass降到6.2ms。第三步开启Hi-Z遮挡剔除远近分层明显的地形通常能再省0.3到0.5ms。整个过程中每步只动一个参数记录一次三角形数和GPU耗时。如果某一步帧时间没有变化先不要继续往下调回头检查这一步是否真的对瓶颈产生了影响。这个习惯能帮你在团队里少背很多锅。5. GPU Driven地形渲染的避坑清单从接缝闪烁到间接绘制炸掉5.1 块间裂缝与边缘闪烁现象相邻地形块之间出现细细的黑缝相机移动时接缝处的像素不停变化远看像地形在闪。原因相邻块使用了不同LOD等级边界上的顶点位置不一致网格边界产生T形裂缝。距离式LOD很容易触发这个问题同一深度的相邻块可能因为距离差一点点就选了不同等级。解决最简单是给每个块边缘加一圈垂直的“裙边”裙边顶点沿法线向外偏移几个单位即使LOD不一致垂下的三角形也能遮住裂缝。另一个可靠做法是约束LOD选择让相邻块的LOD等级相差不超过1或者规定子节点的LOD必须大于父节点。可运行源码里如果默认没带裙边这一步补上优先于其他一切调整。5.2 快速转镜头时地形块消失一两帧现象镜头快速旋转或拉远后屏幕上明显有几块地形不见了等一两帧后又自动出现。原因遮挡剔除使用了上一帧的深度缓冲而新进入视野的节点在上一帧深度里是空白或旧数据被Hi-Z查询误判为被遮挡。解决对上一帧深度做膨胀把深度纹理的周边像素一并算进去同时对“上一帧在视锥外、这一帧刚进入”的节点跳过遮挡剔除直接标记可见。另一个做法是给Hi-Z查询加保护期前几帧不剔除新节点只记录可见性。这个保护逻辑通常放在裁剪Shader的入口处用一个PerFrameCounter判断当前帧与节点首次可见帧的间隔。5.3 间接绘制参数错位导致花屏或缺失现象屏幕上出现不连续的三角形残片或多个地形块重叠有些块画了有些没画移动视角后错误位置跟着变。原因IndirectArgs的实例数、索引缓冲起始位置和InstanceBuffer的实际内容不匹配。常见原因包括结构体对齐、缓冲Stride设置错误或写Args时用错了偏移。这个Bug的特点是难复现调试器里看起来像随机花屏。解决第一时间用CPU回退路径做对照。让CPU把这一帧的可见节点和LOD选出来打印到日志再跟GPU产生的VisibleList逐条对比。另外检查图形API里缓冲的Stride结构体的内存布局必须和Shader声明完全一致。特别要注意float3在传入GPU缓冲时经常要做16字节对齐char数组和bool也要换成uint否则Stride对不上运行时不报错但画出来就是花的。这个坑我在自己项目里踩过两次一次是少算了8字节Stride一次是忘了float3的padding。5.4 性能没提升反而下降现象接入GPU Driven后帧时间不仅没降反而比CPU四叉树还高尤其在小地图或节点数少时特别明显。原因CPU四叉树遍历在小场景里本来就不贵几千个节点的每帧遍历就是一两毫秒的事GPU Driven虽然每帧只跑一次Dispatch却要处理上万个节点还要额外承担Memory Barrier和间接绘制开销。当地形块本身不高模、绘制时间很短时GPU端的调度开销就占了大头。解决换更大的Tile减少节点总数或者只在远场启用GPU Driven近场保持CPU直接提交。记住这套方案优化的是Draw Call和CPU调度如果原方案已经只有一两百次Draw Call那瓶颈就不在这里别硬上。5.5 阴影或深度Pass与地形LOD不一致现象阴影边缘和地形实际网格对不上主视角渲染正常阴影里出现皱褶或缺口。原因主Pass采用GPU Driven的动态LOD而阴影Pass仍然沿用CPU端的固定LOD网格两套逻辑产出的网格形状不一致。更常见的是阴影Pass没有接入间接绘制只渲染了一个粗LOD版本。解决让所有需要地形几何的Pass共用同一份InstanceBuffer和IndirectArgs。深度prepass、阴影Pass、G-Buffer Pass应该消费完全相同的实例列表只是各自换Shader。这样不仅解决视觉不一致顺带把阴影Pass的Draw Call也压下来了。5.6 Memory Barrier缺失的随机漏块现象第一帧正常后面开始出现零星块丢失重新调整视角后又恢复找不到规律。原因Dispatch和Draw之间缺少Memory Barrier图形API执行顺序没有保证GPU读到了上一帧或未写完的间接参数。这个Bug专治各种侥幸心理因为它不会每次都出现换一个GPU驱动可能立刻触发。解决在每次Dispatch、Draw之间显式加上Memory Barrier并使用正确的Stage位。不要寄希望于“实测没出问题”就省略移动端GPU驱动的调度策略各异这类问题在PC上复现不了到移动端就冒出来了。最稳妥的做法是把Barrier封装成一个工具函数强制每次Dispatch后调用从流程上堵住遗漏。6. 进阶把间接命令复用到深度与阴影Pass当主Pass已经能用一次间接绘制跑起来下一步值得做的是把深度prepass和阴影Pass也收编进来。深度prepass的开销往往比主Pass还高因为地形会挡住大量后面的物体不做prepass会产生大量无用着色计算。如果GPU Driven只优化了主Pass等于少拿了一半收益。做法是把两次Compute Shader共用的Args和InstanceBuf再绑定给阴影Pass和深度prepass。代码结构大致是先跑同一份GPU裁剪和参数生成然后用不同Shader绑定同一份实例列表分别输出深度、颜色和ShadowMap。Shader内部可以通过一个标记区分当前Pass决定走哪段输出逻辑。这样整个地形系统的可见性决定只算一次所有Pass共享结果画面一致性和性能一起得到。验证手段也有一条值得养成习惯的做一个Debug Pass把VisibleList里的节点包围盒全部画成线框颜色按LOD等级来分。比如LOD 0亮红、LOD 4亮蓝调阈值时只需要看屏幕上红蓝交织的程度比盯帧时间直观得多。再把被遮挡剔除的节点也画成半透明灰色线框用来确认遮挡剔除没有把不该裁的节点吃掉。我还习惯在调参数时把结果写进一张简单表格三角形数、Draw Call、裁剪Shader耗时、主Pass耗时四列。不只是为了汇报是因为隔几周回来改代码时只有这些记录能告诉你当初为什么那么调。这套管线跑通之后真正拉开差距的往往不是Shader写得多花哨而是参数选得对不对、数据验证做得勤不勤。如果你正被大世界地形的Draw Call追着走希望这篇笔记能帮你少走一段弯路。GPU Driven地形渲染的入门门槛不低但打通整条链路之后收益会一直在那里。希望帮到你。本文还有配套的精品资源点击获取
