1. 项目概述：视觉遮挡，性能与体验的隐形杀手
在Unity游戏开发中，视觉遮挡（Occlusion Culling）是一个常被提及，但实际操作中又容易踩坑的优化技术。简单来说，它解决的是“看不见就不画”的问题。想象一下你的游戏场景是一个复杂的城市，玩家站在一条街道上，他身后的建筑和远处的楼房，其实都不需要被渲染。但默认情况下，GPU可不管这些，它会忠实地把摄像机视锥体内所有物体的像素都计算一遍，哪怕它们被前面的墙挡得严严实实。这种“过度绘制”（Overdraw）是性能的巨大浪费，直接导致帧率下降、设备发热。
视觉遮挡剔除，就是一套聪明的系统，它能在运行时动态判断哪些物体被其他物体完全挡住，从而阻止这些被遮挡的物体进入渲染管线。这和我们熟知的“视锥体剔除”（Frustum Culling）是两回事。视锥体剔除只负责踢出摄像机视野范围外的物体，是Unity自动完成的；而遮挡剔除则专门处理视野内物体之间的前后遮挡关系，需要开发者手动设置和烘焙数据。对于室内场景、复杂地形或者拥有大量静态建筑的游戏，正确启用遮挡剔除带来的性能提升是立竿见影的，有时甚至能减少50%以上的无效绘制调用。无论你是独立开发者还是团队中的技术美术、客户端程序，掌握这套流程都是优化游戏性能、提升玩家体验的必修课。
2. 核心原理与方案选型：为什么是它，以及如何工作
在深入步骤之前，我们必须理解遮挡剔除的工作原理，这样才能在后续配置中做出正确决策。Unity的遮挡剔除系统并非实时计算（那开销太大），而是采用预计算（Bake）的方式。
它的核心思想是：将整个场景空间用一个个细小的立方体网格（我们称之为“单元格”或“体素”）进行划分，形成一个空间层次结构（通常是二叉树）。在烘焙阶段，Unity会模拟一个虚拟摄像机在场景中移动，计算从每个单元格看向其他单元格时，哪些物体是可见的，哪些是被完全遮挡的。这些可见性信息会被记录下来，形成一个“潜在可见集”（Potentially Visible Set, PVS）的数据结构。
运行时，摄像机每帧都会根据自身所在的单元格，快速查询这个预计算好的PVS数据，只渲染当前单元格“可能看到”的物体集合。这就像给游戏世界提前绘制了一张极其详细的“可见性地图”。
这里有几个关键概念需要厘清：
- 遮挡物（Occluder） ：能够挡住其他物体的东西，通常是大型、不透明的静态物体，如墙壁、山体、建筑。
- 被遮挡物（Occludee） ：可能被其他物体挡住的东西，可以是静态的，也可以是动态的。小型物件如桌上的杯子，通常只作为被遮挡物。
- 静态（Static）标记 ：这是Unity烘焙光照贴图、导航网格和遮挡数据的基础。一个物体必须被标记为
Occluder Static或Occludee Static，才会被纳入遮挡剔除的计算范围。
方案选型上，Unity提供了两种主要工具：
- 全局烘焙（Global Baking） ：针对整个场景或大型静态区域。这是最常用、效果最显著的方式，适用于建筑内部、复杂地形等。
- 遮挡区域（Occlusion Area） ：针对动态物体或场景中特定的移动区域（如一个可移动的平台或载具内部）。你可以为这个动态物体绑定一个
Occlusion Area组件，系统会为这个区域单独计算遮挡数据。
对于绝大多数以静态环境为主的游戏，我们主要使用全局烘焙。而动态物体（如玩家、敌人、可移动机关）本身通常不作为遮挡物，但它们能否被正确剔除，依赖于静态环境烘焙数据的质量。
3. 五步高效配置与烘焙实战
理解了原理，我们进入实战环节。以下五个步骤，是我在多个项目中总结出的高效工作流，能帮你系统性地解决遮挡问题。
3.1 第一步：场景分析与物体标记
这一步是基础，也是最容易出错的地方。不要一上来就点“Bake”。
核心操作：
- 分析场景结构 ：在Scene视图中，使用线框模式或切换不同的渲染模式，观察你的场景。找出那些大型的、连续的、不透明的结构，比如外墙、室内隔断、大型岩石。这些是你的主要遮挡物。
- 标记静态物体 ：在Hierarchy中选中所有充当遮挡物的静态物体（建筑、地形块等）。在Inspector窗口的右上角，找到“Static”复选框。点击旁边的小箭头，会展开详细选项。 务必勾选“Occluder Static” 。对于场景中的小物件（箱子、灌木丛、家具），如果它们不太可能挡住其他大物体，但自己经常被
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/weixin_29002209/article/details/162747212
