1. 项目概述深入Unity引擎核心的遮挡剔除在Unity中开发大型场景尤其是开放世界或复杂的室内环境时性能优化是永恒的话题。我们常常会遇到这样的困境明明摄像机视野里只有几面墙但帧率却莫名地低。打开Profiler一看CPU和GPU都在疯狂地处理着成千上万个根本看不见的物体。这就是典型的“过度绘制”问题而解决它的核心武器之一就是静态遮挡剔除。今天我们不聊编辑器里那个简单的“Bake”按钮而是要钻进Unity的源代码仓库——UnityCsReference去扒一扒StaticOcclusionCulling这个核心模块的实现原理。为什么场景中的一堵墙能让它背后的整个街区瞬间“消失”引擎是如何在编辑阶段就预判出哪些物体在哪些视角下是看不见的理解这些底层逻辑不仅能让你在遇到遮挡剔除失效、烘焙数据异常时快速定位问题更能让你在设计场景时做出更明智的决策从根源上提升项目性能。这篇文章就是一次对Unity遮挡剔除系统“庖丁解牛”式的深度探索。2. 静态遮挡剔除的核心思想与工作流程2.1 从“视锥体剔除”到“遮挡剔除”的演进在深入代码之前我们必须先厘清一个基本概念遮挡剔除Occlusion Culling和视锥体剔除Frustum Culling是两回事但它们协同工作。视锥体剔除是图形学的第一道防线。它基于一个简单的空间几何判断一个物体是否在摄像机的视锥体一个平头锥体内如果不在直接丢弃。这个计算非常快通常在CPU上每帧对每个物体的包围盒进行一次检测。然而它有一个致命的弱点它不关心物体之间的前后关系。想象一下你站在一栋高楼前视锥体内包含了这栋楼以及它后面十条街的所有建筑。视锥体剔除会放过所有建筑因为它们都在视野范围内。这时遮挡剔除就该上场了。它的核心任务是回答“在视锥体内的物体有哪些被更近的物体完全挡住了”静态遮挡剔除特指针对那些在运行时不会移动的物体标记为Occluder Static和Occludee Static在编辑阶段或离线阶段预先计算好遮挡关系。它的输出是一张“地图”告诉引擎“当摄像机在A位置时B、C、D物体是可见的当摄像机移动到E位置时B物体被F墙挡住不可见。”StaticOcclusionCulling模块的工作就是生成这张“遮挡地图”。2.2 静态遮挡剔除的完整工作流拆解整个静态遮挡剔除流程可以清晰地分为三个阶段理解这个流程是读懂源码的基础数据准备与体素化引擎首先需要理解场景的三维空间。它会将整个场景的包围盒划分成一个均匀的三维网格每个网格单元称为一个“体素”。同时所有标记为Occluder Static的物体会被转换为简化的几何表示通常是其凸包或简化网格作为潜在的遮挡物。潜在可见集计算这是最核心、最耗时的步骤。引擎会在场景中选取大量的采样点通常是体素网格的中心或顶点从每个采样点向各个方向发射“探测射线”或使用“保守光栅化”技术模拟摄像机看到的内容。通过判断从该点出发哪些Occludee Static物体能被“看到”哪些被Occluder Static挡住来逐步构建一个庞大的关系数据库。这个数据库记录了从每个离散的采样点或区域出发哪些物体是潜在可见的。数据压缩与序列化计算出的PVS数据非常庞大。StaticOcclusionCulling会采用一系列压缩算法如差分编码、位图压缩来减少数据体积。最后将压缩后的数据、体素网格信息、场景参数等序列化为一个二进制文件通常是OcclusionCullingData.asset存储在项目资源中。运行时引擎只需根据摄像机当前所在的体素单元格快速查找并加载对应的可见物体列表。注意很多人误以为烘焙是“预计算渲染”其实不然。它预计算的是“可见性”而非渲染结果。烘焙过程完全不涉及材质、贴图或光照纯粹是几何可见性的分析。3. UnityCsReference中StaticOcclusionCulling源码核心解析打开Unity的C#参考源码仓库定位到StaticOcclusionCulling相关的类主要集中在UnityEditor.Rendering和UnityEngine.Rendering命名空间下我们可以深入其核心实现。这里我们聚焦几个关键类和方法。3.1 OcclusionCullingSettings与场景参数设定在编辑器层面OcclusionCullingSettings类或其相关序列化结构负责存储用户在Occlusion Culling窗口Bake标签页下设置的所有参数。这些参数直接决定了烘焙的精度和性能。// 这是一个概念性的代码结构用于说明参数如何影响算法 public class OcclusionBakeSettings { public float SmallestOccluder; // 最小遮挡物小于此尺寸的物体不被视为有效遮挡物 public float SmallestHole; // 最小孔洞小于此尺寸的缝隙将被忽略物体被视为连续遮挡 public float BackfaceThreshold; // 背面阈值用于判断一个面是否是“背面”背面通常不参与遮挡测试 }Smallest Occluder这个参数至关重要。它设定了一个体积阈值。如果一个Occluder Static物体的包围盒对角线长度小于此值它将在烘焙时被忽略。为什么因为从远处看一个很小的物体如一盏吊灯几乎不可能完全遮挡住它后面的大型物体。将其纳入计算会极大地增加计算复杂度但收益甚微。在室内场景中这个值可以设小一些如0.5-1米在广阔的户外地形这个值应该设得较大如5-10米以避免地形上的小石块产生海量的无效遮挡计算。Smallest Hole现实中的遮挡物很少是严丝合缝的。墙上有门、窗、栅栏。这个参数决定了多大的“洞”会被认为是可通过的。如果设置为0.5米那么任何小于0.5米宽的缝隙在计算时都会被当作“实心墙”处理。这对于优化性能很有帮助但如果你有一个带有很多狭窄窗户的城堡外墙就需要调小这个值否则光线视线将无法透过窗户看到内部。Backface Threshold引擎在计算时需要区分一个三角形的正面和背面。通常面向摄像机的面是正面。这个阈值用于处理那些法线方向模糊或几乎与视线平行的面。合理设置可以避免将本应可见的物体错误剔除。3.2 体素化与场景剖分在StaticOcclusionCulling内部会调用底层的C引擎代码如UnityOcclusionCulling模块进行重型计算。其中一个关键步骤是体素化。引擎会计算所有静态物体的联合包围盒然后根据一个默认或用户定义的Voxel Size体素尺寸将其划分为网格。这个尺寸是精度和内存/计算量的权衡。更小的体素如0.5米能更精确地描述场景细节和摄像机位置但会导致体素数量立方级增长PVS数据量暴增。更大的体素如2米则相反。// 概念性描述计算场景的体素网格 Bounds sceneBounds CalculateSceneBounds(allStaticObjects); Vector3 voxelSize new Vector3(1.0f, 1.0f, 1.0f); // 假设1米精度 int gridSizeX Mathf.CeilToInt(sceneBounds.size.x / voxelSize.x); int gridSizeY Mathf.CeilToInt(sceneBounds.size.y / voxelSize.y); int gridSizeZ Mathf.CeilToInt(sceneBounds.size.z / voxelSize.z); // 生成一个 gridSizeX * gridSizeY * gridSizeZ 的三维体素网格每个体素单元格会记录其内部包含哪些Occluder Static物体的部分通常记录为物体ID的引用。摄像机在运行时的位置会被量化到某个具体的体素单元格中PVS查询正是基于这个单元格索引进行的。3.3 PVS计算的核心算法保守光栅化与软件渲染Unity的静态遮挡剔除主要采用了一种称为保守光栅化的软件渲染技术来生成PVS。你可以把它想象成一个极其简化的、运行在CPU上的“渲染管线”但它渲染的不是颜色而是“物体ID”。设置虚拟摄像机对于每个需要计算的采样点通常是每个非空体素单元格的中心算法会设置一个虚拟摄像机。深度缓冲与ID缓冲它创建两个缓冲区一个深度缓冲区Z-Buffer记录最近的距离一个ID缓冲区ID-Buffer记录对应像素位置是由哪个Occluder Static物体占据的。渲染遮挡物将所有Occluder Static物体的简化网格通常是凸包或经过 drastic simplification 的网格用这个虚拟摄像机进行“渲染”。但这里渲染的不是像素颜色而是将物体的唯一ID写入ID缓冲区并同时更新深度缓冲区。这个过程是“保守”的意味着即使一个三角形只覆盖了像素的一小部分该像素也会被标记为该物体占用确保不会漏掉可能的遮挡。测试被遮挡物接着对于每个Occludee Static物体算法会检查它的屏幕空间包围盒或一组代表点。如果这个包围盒内的所有像素在ID缓冲区中都被同一个或几个更近的遮挡物ID所覆盖即深度值更小那么这个物体就被判定为在该采样点完全不可见。反之只要有一个像素没有被遮挡该物体就被加入该采样点的PVS。这个“对所有像素”的测试就是为什么Occluder Static物体需要是实心的、封闭的。如果一个遮挡物有洞那么被遮挡物就有可能透过洞被“看到”从而无法被剔除。实操心得这也是为什么复杂的、镂空的网格如铁艺栏杆、茂密的树叶不适合作为Occluder Static。它们会导致ID缓冲区出现大量空洞使得背后的物体无法被有效剔除。对于这类物体更好的做法是将其设为Occludee Static而使用一个简单的、实心的代理碰撞体Box Collider作为Occluder Static来近似其遮挡体积。3.4 数据存储与运行时查询计算出的PVS数据需要被高效存储。对于一个有N个Occludee Static物体的场景和M个体素采样点最原始的PVS是一个M x N的布尔矩阵VisibilityMatrix[M][N]表示每个点是否能看到每个物体。这显然太庞大了。Unity的源码中会展示其采用的压缩策略差分编码相邻的采样点体素其可见物体集合通常高度相似。因此可以只存储每个单元格的PVS与其某个相邻单元格PVS的差异增量。位图压缩每个物体的可见性用一个比特位表示。整个场景的可见性集合就是一个很长的比特位数组。然后对这个比特流使用通用的压缩算法如LZ4。分层结构不是所有体素都存储完整PVS。可能采用四叉树/八叉树结构上层节点存储子节点的公共可见集叶子节点存储差异部分。运行时UnityEngine.Rendering.OcclusionCulling类或底层C组件负责查询。// 运行时简化逻辑 int currentCellIndex CalculateVoxelCellIndex(Camera.position); BitArray visibleSet occlusionData.LoadPVSForCell(currentCellIndex); for (int i 0; i allStaticRenderers.Count; i) { if (visibleSet[i]) { // 提交渲染器Renderer.enabled true 或加入渲染队列 } else { // 禁用渲染器Renderer.enabled false } }这个过程每帧都在发生但它只是一次内存查找和比特位操作其开销远小于渲染一个物体所需的顶点变换、光照计算和像素填充。4. 高级主题参数调优与常见陷阱分析理解了原理我们就能有的放矢地进行调优和问题排查。4.1 关键参数深度调优指南Smallest Occluder问题场景烘焙后一些小物件如椅子、箱子背后的物体没有被剔除。分析这些物件可能小于Smallest Occluder阈值被烘焙过程忽略了。对策如果这些小物件在游戏视角中确实能形成有效遮挡例如在走廊里一个箱子能挡住后面的门就需要适当调小此参数或者将这些物件的Scale放大仅用于遮挡计算不影响视觉或者将其拆分为多个部分组合成一个大的遮挡体。Smallest Hole问题一堵带有窗户的墙窗户后的物体在某些角度应该可见但却被剔除了。分析Smallest Hole值可能大于窗户的尺寸导致算法将窗户也视为实心墙体。对策减小Smallest Hole值使其小于窗户等关键孔洞的尺寸。注意这会增加计算复杂度因为算法需要更精细地处理几何边界。Backface Threshold问题一些薄片状的物体如公告板、单面树叶两面都能看到但有一面被错误剔除。分析这些物体的面法线可能不统一或者摄像机视角恰好与平面平行导致算法误判为背面。对策对于这类双面显示的物体最好不要将其设为Occluder Static。如果必须尝试微调Backface Threshold或者检查模型的法线方向。4.2 静态遮挡剔除的典型失效场景与解决方案动态物体无法被剔除原理限制静态遮挡剔除只处理标记为Static的物体。任何会移动的物体玩家、敌人、可移动道具都不会被预计算的PVS所管理。解决方案对于动态物体需要使用动态遮挡剔除技术如硬件遮挡查询通过GPU查询一个物体的简化包围盒是否被当前帧的深度缓冲区遮挡。这是Unity的Occlusion Culling组件为动态物体提供的运行时解决方案。门户系统常用于室内场景手动定义房间和门户动态计算通过门户可见的物体集合。层次Z缓冲一种更高级的软件方法。大范围开放地形剔除效果差分析在广袤的地形上可能缺乏足够大的、连贯的Occluder Static物体如山体。地形本身如果被分割成很多小块每一块都可能无法完全遮挡其后的地块。解决方案在地形上放置大型的、作为遮挡体的代理网格如远景山脉模型。使用层次细节与距离剔除作为主要优化手段遮挡剔除作为辅助。考虑将地形分割成更大的区块并确保地形网格足够“厚实”以被视为有效遮挡物。烘焙数据异常巨大分析场景中Occludee Static物体数量过多或体素精度设置得太高。解决方案合并静态物体将不会单独移动的小型静态物体如场景杂物合并成一个大的网格减少Occludee数量。调整体素大小在保证必要精度的前提下增大Voxel Size。分层烘焙将大型场景分块烘焙运行时按需加载不同的遮挡数据。4.3 结合Occlusion Culling窗口进行可视化调试Unity编辑器的Occlusion Culling窗口的Visualization标签页是一个强大的调试工具。在Scene视图下蓝色线框表示被剔除的物体当前摄像机位置不可见。绿色线框表示可见的物体。白色/红色体素表示场景的体素化网格可以直观地看到烘焙的精度和摄像机所在的当前体素单元。当发现遮挡行为不符合预期时首先在这里进行可视化检查。移动场景中的摄像机观察物体的颜色变化。如果一个应该被挡住的物体始终是绿色的说明它的遮挡关系没有被正确计算需要回头检查物体的Static标记、尺寸以及烘焙参数。5. 源码启示最佳实践与性能考量通过阅读UnityCsReference中相关的代码我们可以总结出一些在项目实践中至关重要的最佳实践。5.1 场景设计阶段的规划明确遮挡物与被遮挡物在搭建场景白模阶段就要有意识地区分哪些是大型的、实心的、连贯的“遮挡物”墙壁、山体、大型建筑哪些是“被遮挡物”室内家具、装饰品、小物件。为它们正确设置Occluder Static和Occludee Static标签。优化遮挡物几何作为Occluder Static的模型应尽量使用简化的碰撞体或低模代理。一个复杂的雕塑可以用一个Box或几个Box组合来近似其遮挡体积。这能极大加速烘焙过程和减少运行时查询的复杂度。避免使用镂空物体作为遮挡物如前所述栅栏、链条、植被等应设为Occludee并用实心代理代替。5.2 烘焙流程的优化策略迭代烘焙增量调整不要一次性对所有参数进行大幅修改。先使用默认参数烘焙一次在Visualization模式下检查主要区域的遮挡是否正确。然后针对出现问题的区域局部调整物体设置或参数进行增量烘焙Unity支持仅烘焙选中的物体或区域。控制烘焙范围如果场景非常大可以使用Occlusion Area组件来划定需要计算遮挡的区域忽略那些永远不会有摄像机进入或遮挡关系简单的区域。关注烘焙日志烘焙完成后查看Console窗口的日志。Unity会输出诸如“Baked successfully in X seconds”、“X objects considered as occluders”等信息。如果烘焙时间异常长或被视为遮挡物的物体数量异常多就是需要优化的信号。5.3 运行时性能监控静态遮挡剔除本身运行时开销很低但需注意内存占用烘焙出的OcclusionCullingData文件大小是重要的监控指标。一个几百MB的遮挡数据文件是不正常的。摄像机瞬移如果摄像机在相邻两帧跨越了多个体素单元格引擎可能需要同时加载多个PVS数据集可能引起卡顿。在设计游戏玩法如传送时需考虑这一点。与动态剔除的协作确保动态物体的Occlusion Culling组件设置合理如View Volume Size避免过多不必要的硬件查询。深入UnityCsReference探究StaticOcclusionCulling的实现不仅仅是为了解决一个技术黑盒。它赋予我们一种“空间思维”能力让我们在构建虚拟世界时能预先洞察性能的瓶颈并做出最优雅的布局。当你下次再点击那个Bake按钮时希望你能清晰地知道引擎正在背后为你编织一张怎样精密的空间可见性之网。这张网是构建流畅、宏大游戏体验不可或缺的基石。