文章摘要
本文详解Unity遮挡剔除技术，通过"可见才渲染"机制大幅优化性能。核心流程分为烘焙和运行时两步：1）编辑器预计算场景可见性数据（需标记静态物体、设置遮挡参数、划分区域）；2）游戏运行时自动查询数据表决定渲染内容。重点解析参数设置技巧（最小遮挡体积、孔洞阈值等）、动态物体处理方案，并提供室内外场景优化建议。通过合理配置，可减少40%-90%的Draw Call，显著提升复杂场景性能。文章包含常见问题解答和实战案例，适合开发者快速掌握这一关键渲染优化技术。
一、前言：为什么要用Occlusion Culling？场景太大，渲染要省事！
大家都玩过3D游戏，尤其是开放世界、室内场景丰富的那种。场景里能有上千个物体、几百个建筑，还有一堆装饰。真的每一帧都把这些东西全画一遍吗？
其实不是。
想想现实生活，你在屋里看手机，根本不会去管后面书架上那些书到底有多少本；你往窗外看，家里沙发也在你视线之外，这就是“看不见就不关心”。电脑也是一样——能看到才画，其他都不开工。这个“只画能看到的”就是遮挡剔除（Occlusion Culling）。
Unity引擎把这事做得很方便，只要提前“扫一遍家里”（就是烘焙），后面游戏跑起来就知道各个角落啥能看见啥看不见，全自动“偷懒”。这样你场景多再大，优化起来就很轻松。
二、遮挡剔除的原理大揭秘：能看见的才画，别浪费性能
遮挡剔除其实很朴素——被墙挡住的东西不画；被地形挡的也不画。
画面上只有你视线能穿过去的物体才会被渲染。
遮挡剔除比常见的“视锥体剔除”更高级：
- **视锥体剔除（Frustum Culling）**只判断在你前方视线范围之内的物体，不管是不是被挡住。
- **遮挡剔除（Occlusion Culling）**进一步判断：物体虽然在你的视线范围，但被某个障碍（比如墙或者大山）“遮住了”，那也能直接不画。
实际效果：
场景里有成百上千的物体，有一大半都只在你看得到的时候渲染，其他时候全隐藏，能把Draw Call压低，加速帧率，减少显卡压力，手机都变得不卡了。
三、Unity里遮挡剔除流程总览——“烘焙+自动判定”
在Unity引擎里，遮挡剔除主要分两步：
- 场景烘焙（Bake）遮挡数据：编辑器提前分析，搞清楚从每个角落各个方向到底能看到什么。
- 运行时自动判断（自动剔除）：每帧根据当前摄像机的位置和朝向，自动查询“能看”的内容，只渲染需要的物体。
下面我们把这两步拆得一清二楚，带你流程走一遍。
四、烘焙流程细节——编辑器里如何一步步“扫视全场”
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<OcclusionCullingData>("场景名");
data.cellSize = 10.0f;
//自定义烘焙流程
十二、实际案例讲解——室内大楼优化全过程
假设你有一个三层大楼场景：
- 每层屋子密密麻麻，家具几十件，门窗多。
- 给所有楼板、主墙体、门框贴静态Occluder Static。
- 家具都贴Occludee Static，只有大件（床、柜子、沙发）。
- 打开Occlusion窗口，Cell Size设成2米，Smallest Occluder设3立方米，Smallest Hole设0.5平方。
- 烘焙一遍，观察可见性变化，走房间发现转弯后家具自动隐藏，视线内只有房间当前摆件。
- 用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-专业IT技术社区
原文链接：https://blog.csdn.net/qq_33060405/article/details/154833089
