企业官网建设流程全解析

一句话：遮挡剔除就是在渲染前判断"哪些物体被墙挡住了"，被挡住的直接跳过不画，从而减少 Draw Call，降低 CPU 和 GPU 的压力。

一、生活里的例子：站在客厅里

你站在自家客厅：

• 身后的东西看不到 → 不用画（这是视锥剔除）
• 卧室里的床在你前方，但被墙挡住了 → 也不用画（这是遮挡剔除）
• 卧室门开着，从门缝能看到一角 → 这时才需要画

如果不做遮挡剔除，GPU 会把整栋楼的家具都画一遍，再被墙盖住。画了，但白画了。

二、Unity 里的三道"过滤网"

每一帧，物体要经过几层筛选才会真正被绘制：

场景里所有物体（比如 5000 个） │ ▼ ① 视锥剔除（自动，总是开启） 不在摄像机视野范围内的 → 去掉 剩 2000 个 │ ▼ ② 遮挡剔除（需要手动设置和烘焙） 在视野内，但被墙挡住的 → 去掉 剩 300 个 │ ▼ ③ 提交渲染（合批、LOD、Draw Call） 真正画出来的 300 个

三、Unity 内置遮挡剔除的核心思路：提前算好

Unity 内置方案使用第三方库Umbra，思路是：

在编辑器里提前把"从哪里能看到哪里"算好存起来（烘焙），游戏运行时直接查表。

为什么要提前算？因为每帧实时精确计算"谁挡住了谁"太贵；提前算好后，运行时只需要很少的 CPU 开销。

代价：只有不会移动的物体才能当"挡板"。

四、全流程：七个步骤

1. 标记物体 谁是挡板？谁能被挡？ 2. 划定区域 摄像机会去哪些地方？ 3. 设置门 哪些通道会开关？ 4. 调整参数 格子多细？ 5. 烘焙 生成可见性数据 6. 可视化检查 剔除得对不对？ 7. 性能验证 真的变快了吗？

第 1 步：标记物体（Static 标记）

选中物体，在 Inspector 右上角Static下拉菜单里勾选：

一个物体可以两个都勾（比如一栋房子：既挡住后面的东西，自己也会被前面的山挡住）。

怎么选：

动态物体（会移动的）怎么办？
在它的 Mesh Renderer 上勾选Dynamic Occlusion（默认已勾选）。这样它可以被静态墙挡住而剔除，但不能挡住别人。

所以敌人、玩家、子弹走到墙后面时，依然会被剔除。

第 2 步：划定摄像机活动区域（Occlusion Area）

GameObject → 创建空物体 → Add Component → Occlusion Area

射击游戏例子：玩家只在走廊和房间里走动，就只在这些地方放 Occlusion Area，天空、山后面这些摄像机去不了的地方不用算。

第 3 步：设置可开关的门（Occlusion Portal）

门关上时，门后的东西应该被剔除；门打开时，又要能看到。

做法：在门的位置放一个物体，加Occlusion Portal组件，调整大小正好盖住门洞。

usingUnityEngine;[RequireComponent(typeof(OcclusionPortal))]publicclassDoor:MonoBehaviour{OcclusionPortalportal;voidAwake(){portal=GetComponent<OcclusionPortal>();portal.open=false;// 一开始门是关的，门后的东西被剔除}publicvoidOpen(){portal.open=true;// 开门：门后可以被看到了// 播放开门动画……}publicvoidClose(){portal.open=false;// 关门：门后又可以被剔除}}

注意：

• 门本身不要标记 Occluder Static。会动的门如果当挡板烘焙进数据，门打开以后，门后的东西还是被当成"被挡住"，就看不见了。
• Portal 的大小要略大于门洞，不然边缘可能漏剔或误剔。
• 门开着时，Portal 不挡任何东西；关上时，它就像一面临时的墙。

第 4 步：调整烘焙参数

打开Window → Rendering → Occlusion Culling，切到Bake页签：

射击游戏推荐的起点：

调参的原则：先用默认值烘焙一次，看到问题再调。物体"闪烁消失"就调小 Smallest Hole；数据太大就调大 Smallest Occluder。

第 5 步：烘焙

点击窗口右下角的Bake。

Unity 会做这些事：

1. 收集所有 Occluder Static 和 Occludee Static 物体 2. 把场景空间切成很多小格子（Cell） 3. 计算：站在每个格子里，能看到哪些格子 4. 识别门（Portal）的位置，记录"门开 / 门关"时的连通关系 5. 把结果压缩，存成一份数据文件

烘焙结果保存在和场景同名的文件夹里（OcclusionCullingData.asset），随场景一起打包。

多场景叠加加载（Additive）的注意事项：
如果游戏是"主场景 + 多个子场景叠加"，要把这些场景同时打开再烘焙，Unity 会生成一份共享数据。分开烘焙的话，场景之间的遮挡关系不会被计算。

第 6 步：可视化检查

还是在 Occlusion Culling 窗口，切到Visualization页签，然后在 Scene 视图里选中摄像机：

拖动摄像机走一圈，被剔除的物体会直接从 Scene 视图里消失。

重点检查：

• 墙后面的东西有没有消失？（没消失 → 墙没标 Occluder，或者太小）
• 视野里的东西有没有不该消失却消失了？（→ Smallest Hole 太大，或者透明物体被当成了挡板）
• 走到门口、拐角时，有没有物体**“突然出现”**？

还有一个常被忘记的开关：摄像机组件上的Occlusion Culling复选框必须勾上（默认是勾上的），否则烘焙了也不生效。

第 7 步：性能验证

做了遮挡剔除，不代表一定变快。要用数据说话：

判断标准：

省下的渲染时间 > 剔除本身的耗时 → 值得 省下的渲染时间 ≤ 剔除本身的耗时 → 不值得，可能反而变慢

典型情况：开阔的户外场景，大部分东西本来就互相看得见，剔除几乎剔不掉什么，反而白白多了查询开销。

五、运行时每一帧发生了什么

每一帧，摄像机开始渲染前： 1. 拿到摄像机的位置和朝向 2. 查烘焙数据：摄像机现在在哪个格子里？ 3. 从这个格子出发，沿着"能看到的格子"往外找 ├─ 遇到开着的门（Portal.open = true）→ 继续往门后找 └─ 遇到关着的门 → 停下，门后不再找 4. 同时结合视锥：不在视野范围内的格子直接跳过 5. 得到"可见格子"列表 ├─ 静态物体：在可见格子里的 → 保留，否则剔除 └─ 动态物体：用包围盒检查是否被静态挡板挡住 → 挡住就剔除 6. 剩下的物体交给渲染管线：合批、LOD、提交 Draw Call

关键点：运行时没有实时计算"谁挡住了谁"，只是查表 + 沿格子走一走，所以 CPU 开销很小。这就是"烘焙"的价值：把贵的计算挪到了开发阶段。

六、射击游戏的实际案例

假设做一个室内 CQB（近距离战斗）射击游戏：一栋三层建筑，每层 10 个房间。

效果（示意数量级）：

不开遮挡剔除：玩家站在一楼房间里，Batches ≈ 1200（全楼的家具都在画） 开启遮挡剔除：同一个位置，Batches ≈ 150（只画当前房间和门口能看到的部分）

七、Unity 内置方案的局限与其他方案

内置的 Umbra 方案很好用，但不是万能的：

其他可选方案：

实际项目常常组合使用：内置遮挡剔除处理室内，距离剔除处理小物件，LOD 处理远景，CullingGroup 处理看不见的特效和动画。

CullingGroup 小例子：看不见的敌人不播动画，省 CPU。

usingUnityEngine;publicclassEnemyVisibility:MonoBehaviour{publicAnimator[]enemies;CullingGroupgroup;BoundingSphere[]spheres;voidStart(){group=newCullingGroup();group.targetCamera=Camera.main;spheres=newBoundingSphere[enemies.Length];for(inti=0;i<enemies.Length;i++)spheres[i]=newBoundingSphere(enemies[i].transform.position,1.5f);group.SetBoundingSpheres(spheres);group.SetBoundingSphereCount(enemies.Length);group.onStateChanged=OnStateChanged;}voidUpdate(){// 敌人会移动，每帧更新包围球位置for(inti=0;i<enemies.Length;i++)spheres[i].position=enemies[i].transform.position;}voidOnStateChanged(CullingGroupEvente){// 变得可见 → 打开动画；变得不可见 → 关闭动画if(e.hasBecomeVisible)enemies[e.index].enabled=true;if(e.hasBecomeInvisible)enemies[e.index].enabled=false;}voidOnDestroy(){group.Dispose();// 必须释放，否则内存泄漏group=null;}}

这里的"可见"同样会考虑烘焙好的遮挡数据：敌人在墙后面时，hasBecomeInvisible也会触发。

八、常见的坑

九、什么时候值得用？

一句话总结

Unity 遮挡剔除 = 标记挡板和被挡物 → 划定摄像机区域 → 用 Portal 处理门 → 调参烘焙 → 可视化检查 → 用 Profiler 验证。
它的本质是把"谁挡住谁"的计算提前到编辑器里做完，运行时只查表，所以开销很小；但只有静态物体能当挡板，最适合室内、结构封闭的场景。是否真的变快，以 Profiler 的数据为准。