1. 项目概述为什么“看不见”的渲染更烧性能做Unity开发尤其是做开放世界、大型室内场景或者移动端项目性能优化是绕不开的坎。你可能会发现明明摄像机视野里只有一小块区域但帧率却莫名其妙地掉得厉害。打开Profiler一看CPU的Camera.Render或者GPU的负载居高不下。这时候一个经常被忽视但至关重要的优化技术就该登场了——遮挡剔除。简单来说遮挡剔除的核心思想就是“眼不见为净”。它通过计算判断哪些物体虽然存在于场景中但被更近的物体完全挡住从而在渲染时直接跳过这些被遮挡的物体。这听起来像是GPU的深度测试会自动做的事对吧但这里有个关键区别深度测试发生在GPU的像素着色阶段物体仍然经历了顶点着色等前期管线流程消耗了宝贵的计算资源。而遮挡剔除发生在CPU端在向GPU提交渲染命令之前就提前“枪毙”掉那些根本不会被看到的物体从源头上减少了渲染批次和顶点处理量。对于关键词中提到的“移动端性能优化”、“Unity游戏优化”遮挡剔除更是救命稻草。移动设备的GPU带宽和填充率有限减少不必要的绘制调用是提升帧率和降低发热最有效的手段之一。无论你是做“Unity数字孪生”需要处理海量模型还是开发“Unity游戏”面临复杂的场景理解并正确使用遮挡剔除都能让你的项目性能表现脱胎换骨。2. 遮挡剔除的核心原理与方案选型在Unity中实现遮挡剔除主要有两种技术路径静态遮挡剔除和动态遮挡剔除。选择哪种取决于你的场景构成和项目需求。2.1 静态遮挡剔除为固定场景量身定制静态遮挡剔除是Unity内置的、最常用的方案。它针对的是那些在游戏运行时不会移动、旋转或缩放的环境物体比如建筑、山脉、地形。它的工作原理是预计算。核心流程如下体素化与采样Unity会将整个场景包围盒划分成一个三维网格体素。然后它会从成千上万个预设的观察点通常分布在导航网格或可行走区域向各个方向发射射线检测场景的可见性。构建潜在可见集对于场景中的每个静态物体标记为Occluder Static和Occludee Static系统会记录下从哪些观察点能看到它。最终生成一个数据结构存储了“在A区域能看到B、C、D物体集合”这样的信息。运行时查询游戏运行时摄像机移动到某个位置对应某个体素单元格系统便快速查询预计算的数据立即获知当前应该渲染哪些物体哪些物体被判定为不可见。为什么选择它运行时零开销所有复杂的计算都在烘焙阶段完成运行时只有高效的数据查询性能收益极高。精度可调通过调整烘焙参数如体素大小可以在烘焙时间、内存占用和剔除精度之间取得平衡。完美适配大型静态环境对于“Unity地图”制作、固定布局的室内场景这是不二之选。注意静态遮挡剔除只对标记为Occluder Static的物体有效。一个物体必须同时勾选Occluder Static能遮挡别人和Occludee Static能被别人遮挡才能参与这个系统。只勾选Occludee Static的物体不会被剔除。2.2 动态遮挡剔除应对移动物体的挑战当你的场景中有大量移动的单位、车辆或者可破坏的建筑时静态方案就失效了。这时需要动态方案。2.2.1 Unity的硬件遮挡查询Unity自身提供基于GPU的硬件遮挡查询。其原理是先使用一个简化版本的物体通常是一个包围盒发起一个查询询问GPU“这个物体在当前深度缓冲下可见吗”。GPU快速光栅化这个简单模型并对比深度将结果返回CPU。如果不可见则CPU在提交该物体复杂网格的渲染命令时就会跳过它。它的优缺点非常明显优点真正动态无需预计算适合移动物体。缺点存在“延迟”。查询和渲染是异步的可能导致物体在出现的第一帧闪烁因为查询结果晚了一帧。同时频繁的查询本身也有CPU-GPU通信开销。在移动端部分低端GPU对此支持不佳或开销较大需谨慎使用。2.2.2 软件方案层次深度缓冲一些高端自定义方案或第三方插件会采用软件渲染一个低分辨率的深度图Hierarchical Z-Buffer在CPU端进行快速的遮挡判断。这比硬件查询更可控但实现复杂对CPU有一定要求。2.2.3 简化的动态方案门户系统与区域管理对于很多游戏特别是RPG或室内FPS一种更实用、更可控的动态剔除思路是“区域管理”。将场景划分为多个房间或区域Cell并手动或半自动地设置门户Portals即门、窗等连通处。当摄像机在一个区域内时只渲染该区域及通过门户可见的相邻区域内的物体。这本质上是一种粗粒度的动态遮挡非常高效但需要人工设计。方案选型心得对于大多数项目我的建议是静态烘焙为主动态方案为辅。首先确保所有静态环境物体都正确设置并烘焙静态遮挡。对于动态物体优先考虑通过设计来规避大量动态物体同时出现在复杂遮挡关系中的情况。如果确实需要再考虑测试Unity硬件遮挡查询在目标平台尤其是“移动端”的效果。对于结构化的室内场景花时间实现一个简单的区域/门户系统长远来看收益可能更高。3. 静态遮挡剔除的详细配置与烘焙实战理论说再多不如动手配置一次。我们以一个典型的室内走廊场景为例走通整个流程。3.1 场景准备与物体标记这是最关键也最容易出错的一步。分离动静物体在Hierarchy中明确哪些是永远不会动的墙壁、地板、天花板、大型家具静态哪些是玩家、敌人、可移动道具动态。正确设置Static Flags选中所有静态物体在Inspector右上角点击Static下拉框。必须同时勾选Occluder Static和Occludee Static。很多新手只勾选Occludee Static导致烘焙完全无效。对于非常细小但数量众多的静态物体如一堆碎石、草丛可以考虑将它们合并成一个大的Mesh使用Unity的Mesh Combiner工具或建模软件以减少需要处理的物体数量提升烘焙效率和运行时查询效率。检查碰撞体与尺寸遮挡剔除系统依赖于物体的Renderer组件Mesh Renderer, Skinned Mesh Renderer等的包围盒Bounds进行计算。确保你的静态物体有正确的Renderer。同时过小或过薄的物体如一张纸可能无法被有效识别为遮挡体可以适当调整其缩放或考虑用代理体替代。3.2 烘焙参数详解与策略打开Window Rendering Occlusion Culling面板切换到Bake页签。这里的参数决定了烘焙的质量和效率。核心参数解析Smallest Occluder能被当作遮挡体的最小物体尺寸。比如设置为1米那么任何小于1米在最窄轴向上的物体即使在Static中标记为Occluder也会在烘焙时被忽略。设置技巧从场景中最小但重要的遮挡体尺寸开始估算。设置过小会大幅增加烘焙时间和数据量设置过大会让一些小柱子、栏杆失去遮挡作用。通常从0.5-1.0开始尝试。Smallest Hole遮挡体上能被“看穿”的最小孔洞尺寸。如果一个窗户的尺寸小于这个值系统会认为它不是一个洞从而错误地遮挡窗后的物体。设置技巧根据场景中需要透光的门、窗、栅栏的最小尺寸来设置。一般0.2-0.5米。Backface Threshold背面剔除阈值。这是一个高级参数。系统在采样时如果发现一个表面的背面被看到的比例超过这个阈值百分比就会认为这个面可能是内部面比如房间的内墙而不将其视为有效的遮挡边界。通常保持默认值100即可除非遇到室内场景烘焙异常。View Cell Size这就是前面提到的“体素”大小。摄像机运行时查询的基本单位。设置技巧这是平衡精度和性能的关键。值越小精度越高摄像机移动时物体显隐切换越平滑但烘焙的数据量越大。对于大多数第三人称或FPS游戏1.0米或0.5米是个不错的起点。对于大型开放世界可以适当增大到2.0米或更高。烘焙策略实操初次烘焙可以先将Smallest Occluder和Smallest Hole设得稍大View Cell Size也设大一些如2.0进行快速烘焙查看大致效果。在Visualization视图下移动场景中的摄像机观察物体的剔除状态蓝色为被剔除。检查是否有明显的错误剔除该看到的没了或该剔除的没剔除。逐步调小参数重新烘焙观察效果改善和烘焙时间增长。这是一个迭代过程。切记不要追求极限精度否则烘焙时间会指数级增长最终的数据文件也会巨大。3.3 烘焙过程与结果验证点击Bake按钮后Unity会开始预计算。你可以在Console窗口看到进度。烘焙完成后会在项目资源中生成一个OcclusionCullingData文件。如何验证效果在Occlusion Culling窗口的Visualization页签下勾选Visualize Occlusion Culling。在Scene视图中你会看到绿色线框表示当前摄像机视锥体。蓝色物体表示被遮挡剔除的物体。红色/绿色/黄色物体表示正在渲染的物体颜色代表不同的渲染队列等。在Game视图运行时你也可以通过Occlusion Culling窗口的Visualization来观察但更推荐使用Frame Debugger(Window Analysis Frame Debugger)。开启录制后你可以逐条查看每一个绘制调用Draw Call清晰地看到哪些物体因为遮挡剔除而被跳过这是最直接的证据。一个重要的检查点确保你的场景有足够的“遮挡体”。一个常见的错误是在一个广阔平坦的地面上放一些房子然后发现遮挡剔除几乎不起作用。因为从摄像机的多数角度房子之间并没有形成连续的遮挡墙。你需要确保场景的布局能产生有效的遮挡关系例如利用地形起伏、密集的建筑群、室内复杂的隔断等。4. 动态物体与遮挡剔除的协同策略静态烘焙好了但游戏中的主角、怪物、飞行的子弹都是动态的它们怎么办4.1 将动态物体设为“Occludee Static”这是一个常用技巧。对于**自身不会移动但可能会被销毁或改变渲染状态如隐藏**的物体比如一堵可以被炸毁的墙你可以将它标记为Occludee Static但不勾选Occluder Static并确保它包含在遮挡烘焙中。这样只要这堵墙存在它就能被正确地遮挡或显示。当你炸毁它通过SetActive(false)或销毁Renderer组件时它不再渲染其后原本被它遮挡的物体也会自然显示出来。这利用了静态剔除数据的查询而非动态计算。4.2 使用LOD Group作为动态物体的代理对于重要的动态物体如BOSS角色你可以为其设置LODLevel of Detail组。LOD Group不仅管理不同距离下的模型精度其生成的包围盒也可以作为硬件遮挡查询的简化代理。在LOD Group组件中勾选Fade Mode为Cross Fade或SpeedTree模式并确保其Bounds设置得合理不要过大可以提升动态遮挡查询的准确性。4.3 通过脚本进行基于区域的粗略剔除对于大量同屏的动态物体如一群NPC更实用的方法是结合管理脚本。例如将场景划分为逻辑区域Trigger体积或网格。动态物体注册到自己所在的区域管理器。区域管理器根据摄像机所在的位置决定哪些区域的物体需要更新和渲染。可以设置一个“激活距离”只更新和渲染摄像机一定范围内的动态物体。这种方法虽然不如真正的遮挡剔除精细但CPU开销极低能有效控制动态物体的数量上限是解决“人海战术”性能问题的常用手段。你可以将其视为一种更粗粒度的、基于距离的“遮挡”。4.4 谨慎启用硬件遮挡查询如果决定尝试Unity的硬件遮挡查询可以在摄像机组件的Occlusion Culling部分勾选Per-Object Occlusion。你需要为希望参与查询的动态物体的Renderer组件勾选Allow Occlusion When Dynamic。实测注意事项平台测试务必在真机尤其是目标低端移动设备上测试性能。有时开启后反而因为查询开销导致帧率下降。代理体大小查询使用的是物体的渲染包围盒。对于形状特异的物体如一个很长的闪电特效其包围盒可能很大导致剔除失败。可以考虑为其附加一个简化的Box Collider并通过脚本将该Collider的bounds赋值给Renderer.bounds需每帧更新作为更精确的查询代理。避免高频更新物体对于位置、旋转、缩放每帧都剧烈变化的物体如粒子系统不适合用此法因为包围盒更新和查询的成本可能超过渲染成本。5. 高级技巧、常见问题与性能分析掌握了基础我们再看一些深入的问题和技巧。5.1 遮挡剔除与合批、LOD的协同优化是一个系统工程遮挡剔除需要和其他技术配合。与静态合批Static Batching静态合批将多个静态物体合并成一个大的绘制调用但合批后的物体会拥有一个巨大的合并包围盒。这个超大包围盒可能很难被完全遮挡反而削弱了遮挡剔除的效果。经验法则对于可能被遮挡的、中小型的静态物体组优先使用遮挡剔除对于总是同时出现、距离很近的大量小物体如地面落叶优先使用静态合批。需要实测权衡。与动态合批Dynamic Batching两者无冲突但动态合批主要针对小网格与遮挡剔除关注点不同。与LOD这是黄金搭档。LOD根据距离切换模型精度遮挡剔除根据可见性决定是否渲染。一个物体如果被遮挡无论其LOD级别如何都不应该渲染。确保你的LOD Group的各级模型都被正确标记为Occludee Static如果是静态的或启用了动态遮挡。5.2 常见问题排查清单问题现象可能原因排查与解决方案烘焙后遮挡完全无效所有物体始终渲染。1. 静态物体未正确标记漏勾Occluder Static。2. 场景缺乏有效的遮挡关系如一片平原。3. 摄像机视锥体过大包含了整个场景。1. 检查关键静态物体的Static Flags。2. 使用Occlusion Visualization视图看是否有蓝色物体出现。如果没有检查场景布局。3. 调整摄像机远裁剪平面距离。物体在应该可见时被错误剔除闪烁。1.Smallest Occluder设置过大小遮挡体失效。2.View Cell Size过大摄像机移动时查询精度不够。3. 物体自身Renderer的包围盒Bounds计算不准。1. 适当调小Smallest Occluder。2. 适当调小View Cell Size。3. 选中物体在Scene视图查看其包围盒Gizmos检查是否异常。可尝试通过代码Renderer.RecalculateBounds()重置。烘焙时间过长数小时。1.Smallest Occluder/Smallest Hole设置过小。2.View Cell Size设置过小。3. 场景中静态物体数量过多、过细。1. 增大上述参数牺牲少量精度换取烘焙速度。2. 合并细小静态物体Mesh Combining。3. 分区域烘焙将大场景分成多个部分分别烘焙Occlusion Data运行时通过脚本切换。动态物体无法被遮挡。1. 未启用硬件遮挡查询或平台不支持。2. 动态物体Renderer未勾选Allow Occlusion When Dynamic。3. 动态物体移动过快查询结果滞后。1. 确认目标平台支持并在摄像机启用Per-Object Occlusion。2. 检查Renderer设置。3. 考虑使用基于区域的管理脚本进行粗粒度剔除。移动端上开启遮挡剔除后性能提升不明显。1. 渲染瓶颈可能在GPU的填充率或Shader复杂度而非Draw Call。2. 场景中动态物体过多静态剔除收益被掩盖。3. 遮挡数据文件过大加载和查询占用内存和CPU。1. 使用Unity Profiler (Deep Profile) 和 RenderDoc等工具定位真正的性能瓶颈。2. 优化动态物体数量采用对象池和距离管理。3. 检查生成的Occlusion Data文件大小尝试用更粗糙的参数重新烘焙。5.3 性能分析与调试工具链不要盲目优化用数据说话。Unity Profiler这是第一道关卡。重点看Rendering区域下的Batches和SetPass Calls数量。在开启/关闭遮挡剔除摄像机组件上取消勾选的情况下对比看批次数的下降是否明显。同时观察CPU的Camera.Render时间。Frame Debugger这是理解遮挡剔除行为的显微镜。逐条查看绘制调用你能精确看到是哪一堵墙的遮挡导致后面一片物体被跳过。这对于验证剔除正确性和优化场景布局无可替代。Occlusion Culling Visualization在Scene视图和运行时进行可视化调试直观理解剔除范围。平台专属工具对于Android可以使用Android GPU Inspector对于iOS使用Xcode Frame Debugger。这些工具能提供更底层的GPU渲染管线信息帮助你判断减少的Draw Call是否真的转化为了GPU负载的降低。我个人在实际项目中的体会是遮挡剔除并非一劳永逸的银弹。它最擅长解决的是“复杂静态环境”下的过度渲染问题。它的效果严重依赖于场景美术的布局。作为程序员你需要和美术同学紧密沟通让他们理解“连续的遮挡体”对性能的重要性。有时稍微调整一堵墙的位置或增加一些装饰物就能带来比调优参数更显著的性能提升。把它当作性能优化工具箱中一件强大但需要精心打磨的工具结合合批、LOD、光照优化等手段才能构建出真正流畅的体验。