本文详解Unity遮挡剔除技术，通过"可见才渲染"机制大幅优化性能。
核心流程分为烘焙和运行时两步：
1）编辑器预计算场景可见性数据（需标记静态物体、设置遮挡参数、划分区域）；
2）游戏运行时自动查询数据表决定渲染内容。
重点解析参数设置技巧（最小遮挡体积、孔洞阈值等）、动态物体处理方案，并提供室内外场景优化建议。通过合理配置，可减少40%-90%的Draw Call，显著提升复杂场景性能。文章包含常见问题解答和实战案例，适合开发者快速掌握这一关键渲染优化技术。
一、前言：为什么要用Occlusion Culling？场景太大，渲染要省事！
大家都玩过3D游戏，尤其是开放世界、室内场景丰富的那种。场景里能有上千个物体、几百个建筑，还有一堆装饰。真的每一帧都把这些东西全画一遍吗？
其实不是。
想想现实生活，你在屋里看手机，根本不会去管后面书架上那些书到底有多少本；你往窗外看，家里沙发也在你视线之外，这就是“看不见就不关心”。电脑也是一样——能看到才画，其他都不开工。这个“只画能看到的”就是遮挡剔除（Occlusion Culling）。
Unity引擎把这事做得很方便，只要提前“扫一遍家里”（就是烘焙），后面游戏跑起来就知道各个角落啥能看见啥看不见，全自动“偷懒”。这样你场景多再大，优化起来就很轻松。
二、遮挡剔除的原理大揭秘：能看见的才画，别浪费性能
遮挡剔除其实很朴素——被墙挡住的东西不画；被地形挡的也不画。
画面上只有你视线能穿过去的物体才会被渲染。
遮挡剔除比常见的“视锥体剔除”更高级：
- 视锥体剔除（Frustum Culling）只判断在你前方视线范围之内的物体，不管是不是被挡住。
- 遮挡剔除（Occlusion Culling）进一步判断：物体虽然在你的视线范围，但被某个障碍（比如墙或者大山）“遮住了”，那也能直接不画。
实际效果：
场景里有成百上千的物体，有一大半都只在你看得到的时候渲染，其他时候全隐藏，能把Draw Call压低，加速帧率，减少显卡压力，手机都变得不卡了。
三、Unity里遮挡剔除流程总览——“烘焙+自动判定”
在Unity引擎里，遮挡剔除主要分两步：
1. 场景烘焙（Bake）遮挡数据：编辑器提前分析，搞清楚从每个角落各个方向到底能看到什么。
2. 运行时自动判断（自动剔除）：每帧根据当前摄像机的位置和朝向，自动查询“能看”的内容，只渲染需要的物体。
下面我们把这两步拆得一清二楚，带你流程走一遍。
四、烘焙流程细节——编辑器里如何一步步“扫视全场”
1. 什么是烘焙？提前做大扫除
烘焙在Unity里，就是“离线”分析场景，把所有能成为“障碍物”的东西列出来，把所有“会被遮住的”物体也记下，模拟摄像机在场景里各个角落、各个方向的视线，形成一个特殊的数据表。
这数据表存着“哪时候能看见哪些东西”，游戏运行时就靠它来快速判定。
2. 步骤详细解释
（1）静态物体标记
在Unity里，只有“静态”物体才能被烘焙参与遮挡剔除。
比如房子、楼、墙、地板这些通常不怎么移动，就标记为“静态”：
选中物体，在Inspector面板打勾“Static” （右上角）
如果你只想让某些物体参与遮挡剔除，还可以在Static下拉菜单里单独勾选“Occluder Static” 或 “Occludee Static”：
Occluder Static（遮挡体）：能挡视线的大块儿物体，比如建筑、地形。
Occludee Static（被遮挡体）：能被挡住的小物体，比如家具、NPC模型、装饰。
（2）打开遮挡烘焙面板
点击菜单栏的Window > Rendering > Occlusion Culling，打开遮挡烘焙窗口。
在这里，你能看到如下几个核心参数：
Smallest Occluder（最小遮挡体体积）：设置多大物体才参与遮挡（防止每个小草都当做墙，太浪费）
Smallest Hole（最小孔洞体积）：比这还小的洞就不当做能“看穿”（比如门和窗）
Backface Threshold（背面阈值）：判断物体朝向和摄像机的角度，比这角度偏得太远就直接不算。
（3）区域划分Cell Size
Unity会自动把场景分成一格一格小方块（Cell），每块都计算一次可见性。
Cell太大遮挡不精确，太小性能浪费。
一般建议Cell Size设置为5-10米，比如房间大小、走廊长度，实际场景大小越复杂，Cell可以设大一点，细致区域再人工缩小。
（4）一键“Bake”烘焙所有数据
在遮挡窗口点击Bake按钮，Unity开始自动分析场景。从每个cell的每个方向模拟摄像机视线，查哪些物体能看到，哪些物体被什么挡住了。
这个过程和灯光 烘焙类似，会花一点时间（场景越复杂越慢）。
烘焙完会生成遮挡数据文件，存到Library里。
（5）烘焙视图调试
烘焙完成后，你可以在Scene视图调整摄像机观察，切换到Occlusion视角模式，实时查看“看得见和看不见的物体”颜色变化。
通常绿色或蓝色是可见，灰色被遮挡不画。
五、遮挡体与被遮挡体设置心得——别让一根小棍子挡住全场
1. 遮挡体（Occluder Static）选择技巧
一般只选择“真能挡住大块视野”的物体：
墙面、楼板、山体、粗柱
大型建筑
千万别把小物体都勾上，像花盆、相框没必要，既不影响遮挡效果还拖慢烘焙速度。
2. 被遮挡体（Occludee Static）选哪些？
只要是“可以被遮住”的东西就可以勾选，比如：
家具、装饰物、NPC（静态位置）
室内的灯具、电视、床
门、窗（视情况）
移动的物体（比如玩家角色、怪物），一般不用静态遮挡剔除。
3. 大场景分区管理
对于超大地图，比如开放世界，建议把地图分几个区域单独烘焙，避免一次性分析全场数据太慢，内存太大。
六、参数设置深入讲解——烘焙结果怎么调得合适？
1. Smallest Occluder（最小遮挡体体积）
如果设置太小，每个细棍小盆栽都参与遮挡烘焙，性能被拖死。
一般推荐设置为 2-5 立方米，具体看场景密度。
2. Smallest Hole（最小洞体积）
这个参数决定“能否看穿小窗”——像透过门把手洞的这种，不太用剔除。
一般设置1-2平方厘米为下限。
3. Backface Threshold（背面阈值）
这个是额外精准控制，从某个角度看到遮挡体背面时还算不算被挡住。角度越大可见性越宽松，越精确需要小一点。
七、运行时自动判断机制——每帧都“查表”，性能快又准！
1. 怎么判定“本帧需要渲染那些东西”？
每一帧，Unity会根据主摄像机当前的位置（在哪个cell）和朝向，去查烘焙好的遮挡数据表。
查完以后，哪些物体“能看到”，就会自动渲染；哪些“被遮挡扔后面去了”，直接不画，甚至不用加载。
2. 动态物体怎么处理？
遮挡剔除是针对静态物体的。动态物体（比如玩家、怪物）一般用更简单的视锥体剔除+距离剔除，或者实时射线检测。
不过如果你的动态物体移动很少（比如门只开关，不走远），可以采用“分区再烘焙”的策略，开关状态改变时重新烘焙局部遮挡数据。
3. 多摄像机场景支持
如果你游戏里有多主摄像机，比如第一人称加迷你地图/安全摄像头，多烘焙一份数据表，每个摄像机单独查自己的遮挡数据。
八、场景维度实际效果分析——遮挡剔除到底省了多少？
举例：房间里有100个物体，墙挡住了一半，从大厅里看，只有30个能看见。遮挡剔除一开，渲染负担减到三分之一。
在复杂室内/城市场景，遮挡剔除能让Draw Call下降40%～90%（视场景复杂程度和遮挡策略），这对于低端机/手机来说直接决定“能不能跑得动”。
实际测试：
用Unity Profiler打开Stats面板，对比开启和关闭遮挡剔除前后，每帧渲染物体数量和Draw Calls数量，性能提升会非常明显。
九、实战优化建议——让烘焙和自动判断“又快又不误伤”
1. Cell区域设置不能太小也不能太大
太大：判定粗糙，本来能看见的东西被误剔除。
太小：性能浪费，数据表超级大，运行变慢。
建议场景内走廊用 5 米，房间用 2-3 米。开放区域大场景适当设大。
2. 遮挡体只选核心障碍
比如大墙、层板，别让小盆栽都成遮挡主力。
3. 动态和静态物体分开管理
动态区域用别的剔除方法，或者烘焙时只分析关键静止障碍。
4. 多摄像机和多分区合并 数据表
多分区烘焙后，可以合并分区遮挡数据表，节约空间、加快查表速度。
5. Profiler实时检测及时调整
每次烘焙后用Profiler比对，不要光看理论效果，要关注实际帧率和Draw Call数量。
十、常见问题与开发者疑难解答
1. 为什么有些物体误判“本来应该显示结果被隐藏？”
Static标记没设置对，或Cell太大导致遮挡范围“误伤”。
遮挡体积设置过小，场景“重叠遮挡主力”太多。
多摄像机未分区或重复标记。
2. 为什么烘焙很慢，内存爆炸？
Cell设置太小，场景物体太多，每个角落都算一次，数据量急速膨胀。
遮挡体太多，小物体参与遮挡导致数据冗余。
3. 为什么动态物体不能被剔除？
遮挡剔除只支持静态障碍，动态物体需实时剔除，可以用射线检测或自定义算法。
子物体如果父物体没标记static，也不会被烘焙。
4. 室外场景怎么用遮挡剔除？
室外一般用大楼、山体、大型障碍物为遮挡体，小树没必要。
超大地图建议分区管理，开阔区域cell可设大一点。
十一、代码层面原理介绍与开发扩展
虽然Unity遮挡剔除绝大部分是“零代码”工程师配置，实际底层是这样：
- 编辑器阶段烘焙，C++层用一套空间分块加光线投射做预计算，可见性数据存文件。
- 运行时C#逻辑，摄像机每一帧查当前cell和朝向，load的数据表，自动控制Renderer.enabled标记。
- 如果配合Animator或AI，可以根据Renderer.enabled自动让NPC死亡或触发事件。
开发者实际不需要手写遮挡剔除算法 ，只用合理设置参数和静态标记。
但高级用法：
比如某些特殊摄像机（安全区监控），可以用代码控制强制显示/隐藏某些物体：
OcclusionArea area = GetComponent<OcclusionArea> (); area.enabled = false; //某区域临时关闭遮挡剔除
或者动态调整Cell Size/烘焙参数：
OcclusionCullingData data = Resources.Load("场景名"); data.cellSize = 10.0f; //自定义烘焙流程
十二、实际案例讲解——室内大楼优化全过程
假设你有一个三层大楼场景：
1. 每层屋子密密麻麻，家具几十件，门窗多。
2. 给所有楼板、主墙体、门框贴静态Occluder Static。
3. 家具都贴Occludee Static，只有大件（床、柜子、沙发）。
4. 打开Occlusion窗口，Cell Size设成2米，Smallest Occluder设3立方米，Smallest Hole设0.5平方。
5. 烘焙一遍，观察可见性变化，走房间发现转弯后家具自动隐藏，视线内只有房间当前摆件。
6. 用Profiler观察帧率和Draw Call，关闭遮挡剔除瞬间多出200+ Draw Calls，开启后只剩50左右，帧率提升30%。
十三、遮挡剔除与其它优化方案配合技巧
1. 搭配LOD（细节层级开关）
开远距离自动降级模型，再加遮挡剔除，低模也不用加载，极度省资源。
2. 与对象池动态管理
物体被剔除时直接隐藏，不要销毁，可以对象池暂存，等用到再显示。
3. 分区Cull Group自管理
如Unity的Cull Group组件，可以区域性分组做自定义遮挡剔除，比如一栋楼一组。
十四、未来增强趋势与高阶玩法
1. 动态遮挡剔除GPU加速
配合GPU插件，能做大规模动态障碍实时遮挡，适合开放世界、大型多人网络场景。
2. AI可见性预测
智能算法根据玩家移动轨迹，提前预判可能可见物体，实现提前加载/隐藏。
3. 云端烘焙同步
场景复杂时，预计算烘焙云端完成，运行时自动流式下载遮挡数据，节省硬件负担。
十五、结语：遮挡剔除是Unity大场景提速“神技”，做好一点不难
总的来说，Unity里遮挡剔除能让3D场景一下子省下海量性能，既方便开发又轻松提效。别小看“前期烘焙”这一步，后期自动判断才能真的让你的游戏不卡、帧率稳、Draw Call低。
记住几个大方向：
- 合理标记静态物体，不该遮挡的物体就别乱勾选。
- Cell区域、参数设置要结合场景实际，宁可精简也别贪心。
- 多用Profiler实测效果，每次调整都看实际数据。
- 和其它优化方法灵活搭配，远距离降模、对象池配合，能把资源利用率拉满。
如果还不理解遮挡剔除怎么回事——自己动手把家里搭个场景试试，随便拉几十个物体，看静态标记和烘焙后能看到的变化，非常直观。
做大地图、复杂室内场景、低端设备兼容，Unity遮挡剔除都是不可替代的法宝。用好它，你的游戏场景就能像魔术一样“只画你看的到”！
版权声明：本文为CSDN博主「你一身傲骨怎能输」的原创文章，
遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_33060405/article/details/154833089
