1. 项目概述从“渲染”到“剔除”的效能革命在实时渲染的世界里性能是永恒的追求。想象一下你正站在一个繁华的虚拟城市中央眼前是鳞次栉比的高楼大厦、川流不息的车流和熙熙攘攘的人群。对于渲染引擎而言它需要处理的是构成这个场景的成千上万个模型、数百万个三角形。然而你的视野是有限的很多建筑被前面的高楼挡住很多人被墙壁隔开。如果引擎傻乎乎地把所有东西都画出来再让GPU去判断哪些像素最终不可见那无疑是巨大的资源浪费。这就是“遮挡剔除”技术存在的根本意义它像一个聪明的舞台总监在演员渲染对象上台前就判断出哪些演员会被幕布或其他演员完全挡住从而根本不让他们进入后台准备区直接节省了化妆、换装和上台的整个流程开销。在UE5中遮挡剔除系统是渲染管线中至关重要的一环它直接决定了每一帧需要提交给GPU的绘制指令数量。我们今天要深入源码阅读的正是UE5渲染线程中负责执行遮挡查询的核心模块之一其代码位于Engine/Source/Runtime/Renderer/Private/Occlusion.cpp的第206行附近。这行代码及其上下文是理解UE5如何高效管理“硬件遮挡查询”这一关键技术的绝佳切入点。对于任何希望深入引擎底层、优化项目性能或是对计算机图形学中空间数据结构与可见性判断算法感兴趣的开发者来说剖析这段代码都极具价值。它不仅仅是几行C更是UE5应对复杂场景、实现稳定高帧率的智慧结晶。2. 核心原理硬件遮挡查询与层次深度缓冲在深入代码之前我们必须先建立遮挡剔除的核心概念框架。现代GPU提供了一种称为“硬件遮挡查询”的功能。其基本思想是我们先用一个极其简化的几何体通常是一个包围盒来“试探性”地绘制到深度缓冲区。这个绘制过程只进行深度测试不输出任何颜色并且速度极快。GPU会返回一个结果有多少个像素的深度测试通过了。如果通过的数量为0那就意味着这个简化几何体在当前视角和深度缓冲状态下完全不可见那么它所代表的复杂原始物体自然也就可以安全地跳过了。2.1 层次深度缓冲的妙用然而逐一对场景中成千上万的物体发起遮挡查询其本身的开销也可能变得不可忽视。UE5采用了一种更高级的策略层次深度缓冲。它不是对每个物体都进行查询而是自底向上地构建一棵空间层次结构树例如BVH包围盒层次树。查询从根节点开始如果根节点代表整个场景或一大片区域被判定为不可见那么其下的所有子节点都可以立即被剔除无需进一步查询。这种“早期跳出”机制极大地减少了查询次数。2.2 查询的异步性与延迟处理另一个关键点是查询的异步性。当你发起一个遮挡查询时GPU并不会立刻给你结果因为命令还在队列中。UE5的遮挡系统需要管理这种“延迟”。它在一帧中发起查询然后在后续的帧中获取之前查询的结果并用这个“历史结果”来指导当前帧的剔除决策。这就引入了一个“帧延迟”但通过巧妙的预测和缓冲机制系统能在绝大多数情况下做出正确的判断。我们即将阅读的源码正是管理这个“查询生命周期”的核心逻辑之一涉及查询对象的创建、回收、状态管理以及与渲染命令列表的交互。3. 源码深度解析FOcclusionQueryFPool与帧管理让我们把目光聚焦到Occlusion.cpp的第206行附近。通常这里会是一个关键函数或逻辑块的一部分。为了透彻理解我们需要先了解其所在的上下文结构。UE5的遮挡查询系统主要围绕几个核心类展开FOcclusionQueryFPool: 查询对象池。这是资源管理的核心避免频繁创建和销毁GPU查询对象带来的开销。它管理着一系列FRHIRenderQuery对象。FOcclusionQueryBatcher: 查询批处理器。负责将多个查询请求批量提交到渲染命令列表。FViewInfo: 视图信息。其中包含了当前帧所有待处理的遮挡查询状态。假设我们关注的代码位于FOcclusionQueryFPool::AllocateQuery或FOcclusionQueryFPool::ReleaseQuery函数中或者是提交查询命令的附近。以下是基于此场景的深度解读。3.1 查询对象的生命周期管理// 伪代码示意查询分配的核心逻辑 FOcclusionQueryFPool::FOcclusionQueryFPool(FRHICommandListBase RHICmdList) { // 预分配一批查询对象放入空闲池 for (int32 i 0; i InitialPoolSize; i) { FRHIRenderQuery* Query RHICmdList.CreateRenderQuery(RQT_Occlusion); FreeQueries.Add(Query); } } FRHIRenderQuery* FOcclusionQueryFPool::AllocateQuery(FRHICommandListBase RHICmdList) { FRHIRenderQuery* Query nullptr; if (FreeQueries.Num() 0) { // 优先从空闲池获取 Query FreeQueries.Pop(false); } else { // 空闲池不足动态创建新的查询对象 Query RHICmdList.CreateRenderQuery(RQT_Occlusion); // 可能会记录统计信息如动态分配次数 } // 将查询标记为“已分配正在使用” ActiveQueries.Add(Query); return Query; } void FOcclusionQueryFPool::ReleaseQuery(FRHIRenderQuery* Query) { if (Query ActiveQueries.Remove(Query) 0) { // 不是立即销毁而是放回空闲池以供复用 FreeQueries.Add(Query); } }关键点解析对象池模式这是高性能C程序的经典模式。直接创建/销毁GPU资源查询对象是昂贵的。通过池化引擎在初始化时或首次需要时批量创建用完后归还池中后续分配直接从池中获取几乎零开销。双列表管理FreeQueries和ActiveQueries分别管理空闲和正在使用的查询。这确保了资源的有效追踪防止泄漏查询对象未被释放和重复释放。动态扩容当场景复杂度突然激增预分配的查询不够用时池子能够动态创建新的查询对象。但这是一种“降级”策略理想情况是通过合理的InitialPoolSize配置来避免。注意在实际的UE5源码中管理可能更复杂会考虑多帧延迟释放、查询结果的有效性判断等。ReleaseQuery的调用时机非常关键必须在确定GPU不再需要这个查询对象之后通常是获取到结果之后。3.2 查询的提交与帧号关联接下来我们看查询是如何被提交并关联到特定帧的。这通常发生在FOcclusionQueryBatcher或FViewInfo的相关函数中。// 伪代码示意如何为一批图元批量提交遮挡查询 void SubmitOcclusionQueries(FRHICommandList RHICmdList, const TArrayFBox BoundingBoxes, int32 FrameNumber) { TArrayFRHIRenderQuery* Queries; Queries.Reserve(BoundingBoxes.Num()); // 1. 为每个包围盒分配一个查询对象 for (const FBox Bounds : BoundingBoxes) { FRHIRenderQuery* Query OcclusionQueryPool-AllocateQuery(RHICmdList); Queries.Add(Query); } // 2. 开始一个查询批次 RHICmdList.BeginRenderQueryBatch(Queries.Num()); // 3. 为每个查询绘制简化几何体通常是包围盒的8个顶点 for (int32 i 0; i BoundingBoxes.Num(); i) { RHICmdList.BeginOcclusionQuery(Queries[i]); DrawBoundingBoxMesh(RHICmdList, BoundingBoxes[i]); // 简化绘制 RHICmdList.EndOcclusionQuery(Queries[i]); } // 4. 结束批次并记录元数据 RHICmdList.EndRenderQueryBatch(); // 5. 关键步骤将查询对象、其对应的物体ID、以及当前帧号关联起来存入一个“待解决”列表。 // 这个帧号用于后续获取结果时判断结果的“新鲜度”。 for (int32 i 0; i Queries.Num(); i) { PendingOcclusionQueries.Add({Queries[i], PrimitiveId[i], FrameNumber}); } }关键点解析批量提交BeginRenderQueryBatch和EndRenderQueryBatch是优化关键。它告诉驱动将这些查询打包处理减少了API调用的开销。单独提交成百上千个查询的代价是巨大的。绘制简化几何体DrawBoundingBoxMesh是一个高度优化的路径。它可能使用一个固定的顶点缓冲区和一个极其简单的着色器只输出深度可能连顶点变换都极度简化唯一目的就是进行深度测试。帧号关联这是处理异步性的核心。FrameNumber记录了查询发起时的帧。当在下一帧或下下帧去获取结果时系统会检查这个帧号。如果结果对应的帧号过于陈旧比如相差3帧以上这个结果可能因为相机移动而失效需要被谨慎使用或直接丢弃。4. 结果获取与剔除决策发起查询只是上半场下半场是获取结果并做出剔除决策。这个过程通常发生在下一帧的开始时或者在本帧的稍后阶段如果GPU足够快。4.1 获取查询结果// 伪代码处理上一帧提交的查询结果 void ProcessPendingOcclusionQueries(FRHICommandList RHICmdList, int32 CurrentFrameNumber) { for (auto It PendingOcclusionQueries.CreateIterator(); It; It) { const FOcclusionQueryInfo QueryInfo *It; // 检查这个查询是否“太老”避免使用过时数据 if (CurrentFrameNumber - QueryInfo.SubmitFrameNumber MaxQueryLatencyFrames) { // 结果失效释放查询对象并从列表中移除 OcclusionQueryPool-ReleaseQuery(QueryInfo.Query); It.RemoveCurrent(); continue; } // 尝试从GPU获取结果 uint64 VisiblePixels 0; bool bResultAvailable RHICmdList.GetRenderQueryResult(QueryInfo.Query, VisiblePixels, false); // false表示不等待 if (bResultAvailable) { // 结果已就绪 bool bIsVisible (VisiblePixels 0); // 根据可见性更新对应图元的状态 UpdatePrimitiveVisibility(QueryInfo.PrimitiveId, bIsVisible); // 查询使命完成释放资源 OcclusionQueryPool-ReleaseQuery(QueryInfo.Query); It.RemoveCurrent(); } else { // 结果尚未就绪保留在列表中等待下一帧再检查 // 这里可能实现一个“等待计数器”超过一定帧数后强制释放避免堆积 } } }关键点解析非阻塞获取GetRenderQueryResult的最后一个参数bWait设为false至关重要。这意味着如果结果没准备好函数立即返回false而不会阻塞CPU线程等待GPU。这保证了渲染线程的流畅性。延迟容忍与超时MaxQueryLatencyFrames定义了系统能容忍的最大查询延迟。超过这个延迟的结果被认为不可靠直接丢弃。这防止了因GPU负载过高或驱动问题导致查询队列堵塞进而使用严重过时的可见性信息。可见性判断VisiblePixels 0是黄金标准。只要有一个像素的深度测试通过就认为该物体“可能可见”。注意这里是“可能”因为包围盒的可见性并不完全等价于物体本身的可见性包围盒可见物体可能被穿透或部分遮挡但这已经是一个极好的保守估计。4.2 整合到渲染决策链获取到的可见性结果如何影响渲染每个图元FPrimitiveSceneInfo都有一个LastRenderTime或可见性状态标志。当构建动态渲染列表如FSceneRenderer::SetupMeshPass时会检查这些标志bool ShouldRenderPrimitive(const FPrimitiveSceneInfo* Primitive, const FViewInfo View) { // 一系列其他剔除测试视锥体剔除、距离剔除等... if (!View.PrimitiveVisibilityMap[Primitive-GetIndex()]) { // 遮挡查询结果显示不可见 return false; } // ... 其他测试 return true; }PrimitiveVisibilityMap就是一个位图每一位对应一个图元在当前视图中的遮挡查询可见性结果。如果为false该图元及其所有网格体将不会进入任何通道的绘制列表。5. 高级策略与性能调优实战理解了基本流程后我们来看看UE5中一些高级策略和实际项目中的调优点。5.1 多粒度查询与层次化剔除UE5不会对所有物体都用同样的包围盒进行查询。它采用了一种层次化策略预计算层次结构在场景构建或流式加载时为静态网格体Actor或HLOD层次细节级别集群计算包围盒层次结构。自上而下遍历从根节点开始查询。如果根节点不可见其下所有子节点全部跳过。如果根节点可见则继续查询其子节点。动态物体处理对于动态物体每帧计算其包围盒并插入到查询批次中。动态物体的查询通常更“昂贵”因为它们的包围盒变化频繁。5.2 查询的保守性与“误报”遮挡查询是“保守”的。它只敢肯定地说“什么东西一定看不见”查询结果像素为0但不敢肯定地说“什么东西一定能看见”。因为包围盒的可见性只是物体可见性的必要条件而非充分条件。这导致两种“误报”假阴性False Negative物体实际可见但查询认为不可见。这是灾难性的会导致物体消失。UE5通过多种机制极力避免例如对移动中的物体使用上一帧的结果会更谨慎或者对某些关键物体如玩家角色禁用遮挡剔除。假阳性False Positive物体实际被遮挡但查询认为可见。这只会导致性能损失多画了看不见的东西但不会影响正确性。系统可以容忍一定程度的假阳性。5.3 项目中的关键性能参数与调试在UE5编辑器中有几个控制台变量CVars对遮挡剔除性能至关重要控制台变量默认值说明调优建议r.AllowOcclusionQueries1全局开关遮挡查询。性能排查时设为0可关闭剔除检查是否是剔除导致的问题。r.HZBOcclusion1 (如果支持)启用基于硬件层次深度缓冲的遮挡。这是比传统查询更现代、更高效的技术。确保在支持硬件上开启。这是UE5的默认优选方案。r.occlusion.QueryBatchSize查询批处理的大小。通常无需修改驱动和引擎会自动优化。在极端情况下调整它可能影响提交效率。stat initviews-在stat命令输出中查看“Occluded Primitives”计数。最重要的调试指标。它显示每帧被遮挡剔除的图元数量。这个数字应该在你的场景中相当可观例如30%-70%否则说明剔除效率低或相机视角特殊。visualize occlusion-可视化遮挡查询结果。被剔除的物体会显示为特定颜色如红色。在编辑器中运行直观查看哪些物体被剔除了。检查是否有不该被剔除的物体消失了假阴性。实操心得HLOD是你的朋友对于广阔的开放世界务必使用HLOD。它将远处的大量小物体合并成几个大物体极大地提升了遮挡查询的效率。一个大物体的一个查询就能剔除背后成百上千个小物体。关注动态物体大量快速移动的小型动态物体如飞弹、粒子系统发射器是遮挡系统的噩梦。考虑对它们使用简化的碰撞体作为查询体或者对非常小的物体直接禁用遮挡查询因为绘制它们的开销可能比查询本身还小。调试“物体闪烁”如果物体在相机移动时偶尔闪烁消失很可能是遮挡剔除的假阴性。首先用visualize occlusion确认。如果是可以尝试1) 略微放大该物体的包围盒在模型或Actor属性中2) 对该Actor强制禁用遮挡剔除bDisableOcclusionQueries3) 检查物体是否在HLOD集群中集群的包围盒计算是否准确。6. 常见问题排查与解决方案实录在实际开发中遮挡系统引发的问题虽然不多但一旦出现往往难以定位。下面记录几个典型案例和排查思路。问题一特定视角下一大片建筑或地形突然消失。排查步骤按下“~”键打开控制台输入visualize occlusion。移动到物体消失的视角观察消失的物体是否被染成了代表“被遮挡”的颜色如红色。如果是说明遮挡系统误判。逐步拉远相机物体可能会重新出现这证实了是剔除问题。根因分析包围盒不准确可能是模型的包围盒计算有误或者多个静态网格体组件组合后的Actor包围盒过紧。遮挡查询用的是这个包围盒。HLOD问题如果消失的是远处LOD可能是HLOD集群的包围盒计算错误或者HLOD的绘制本身有问题例如材质错误导致深度写入失败使得后续查询误以为该区域为空。查询延迟与相机高速运动相机移动过快时上一帧的查询结果用于当前帧可能导致位置滞后的误判。解决方案检查问题模型的资产确认其包围盒是否合理。可以在建模软件或UE编辑器中查看。对于Actor可以尝试在细节面板中找到渲染部分勾选“禁用遮挡查询”作为临时测试。如果问题解决则需考虑放宽该Actor的包围盒。如果是HLOD需要重新构建HLOD并检查HLOD代理网格体的材质和深度渲染状态。对于高速相机可以考虑对关键物体使用“永远可见”标志或调整MaxQueryLatencyFrames需谨慎修改源码CVar。问题二stat initviews显示“Occluded Primitives”数量极低但GPU性能依然吃紧。排查步骤确认r.HZBOcclusion和r.AllowOcclusionQueries均为1开启。使用stat scene查看总的图元数量。计算剔除率Occluded Primitives / Total Primitives。使用profilegpu命令查看渲染线程中“Occlusion”阶段的耗时。如果耗时异常高说明查询本身成了瓶颈。根因分析视角问题相机位于开阔地带视野内物体本就很少被彼此遮挡。查询过载场景中需要查询的物体太多即使大部分被剔除提交和解析查询的CPU开销本身已经很大。HZB未生效硬件或驱动不支持HZB或HZB生成有误回退到了效率较低的传统查询。解决方案这是场景设计问题。考虑通过美术布局增加场景的遮挡物如山体、建筑创造更多的遮挡机会。优化场景合并静态网格体、使用更少的Actor、启用HLOD从根本上减少需要参与查询的图元数量。如果传统查询是瓶颈可以尝试微调r.occlusion.QueryBatchSize但效果通常有限。根本之道还是减少查询数量。问题三移动设备上开启遮挡剔除后帧率反而下降或不稳定。排查步骤在PC上模拟移动设备性能使用相应的性能预览模式观察问题是否复现。使用stat unit和profilegpu对比开启和关闭遮挡剔除时的CPUGame和Draw与GPU耗时。根因分析CPU开销过高移动端CPU相对较弱管理大量查询对象、遍历层次结构、处理查询结果的开销可能抵消了GPU节省的开销。GPU带宽与功耗频繁的查询提交和结果读取也会占用GPU带宽在移动端这可能比绘制几个简单三角形更耗电、更影响性能。驱动差异不同移动GPU厂商的遮挡查询实现效率差异巨大。解决方案简化查询减少每帧发起查询的物体数量。可以增大查询的最小物体屏幕尺寸阈值需要修改引擎代码或寻找相关CVar。降低频率不对每一帧都进行查询而是每2-3帧查询一次中间帧复用之前的结果。这需要更复杂的帧间状态管理。分帧处理将查询任务分摊到多帧完成避免单帧CPU峰值。针对性关闭对于已知性能敏感的场景或低端设备在项目设置中考虑部分或全部关闭遮挡剔除依赖视锥体剔除和距离剔除。遮挡剔除是渲染优化中效果最显著、但也是最复杂的技术之一。通过深入UE5源码我们看到了一个工业级引擎是如何通过精细的对象池管理、异步结果处理、层次化查询和保守性决策在“确保正确性”和“追求极致性能”之间走钢丝的。理解这些底层机制不仅能帮助我们在遇到问题时快速定位更能指导我们在项目初期就做出更利于性能的场景设计和资产规划。记住最好的优化永远是“不画”而遮挡剔除就是实现“不画”的艺术。
)
