利用遮挡剔除优化 3D Tiles 传输（译：Optimizing 3D Tiles Streaming in Cesium for Unreal with Occlusion Culling）

物体空间方法是另一类遮挡剔除技术，在这种方法中，遮挡物和被遮挡物的几何形状以保守的、轴对齐的表示方式存储在包围体积层次结构（BVH）中——通常使用八叉树。每个遮挡物体积沿摄像机的反方向向物体BVH投射一个“可见性阴影”。对于每个遮挡物，必须遍历一次BVH以找到被遮挡的物体（那些位于遮挡物“阴影”中的物体）。遮挡物的轴对齐表示可以选择进行融合，以提高遮挡率并减少独立的BVH遍历次数。

遮挡物融合、轴对齐遮挡物简化和BVH遍历都是CPU密集型任务。为了支持3D Tiles，如果使用这种方法，这些任务必须在运行时持续执行，因为随着摄像机飞行穿越世界，遮挡物的集合会不断变化。总体而言，物体空间方法随着遮挡物数量的增加而扩展性差，且可能过于保守。

场景中的物体存储在八叉树中。红点代表摄像机。遮挡物（黄色）投射出一个“阴影”（蓝色），遮挡所有被遮挡物体后面的物体。

图像空间

图像空间方法目前是最受欢迎、可扩展且有效的遮挡剔除形式。这些方法利用GPU，并且对于动态和流式传输的物体具有更强的鲁棒性，开销极小。本文的其余部分重点介绍了虚幻引擎和Cesium for Unreal中使用的图像空间技术的特定组合。

图像空间遮挡剔除

外包体积

精确判断一个物体是否被遮挡是昂贵且不利于遮挡剔除目标的。考虑与视锥剔除的类比——检查物体的每个顶点以判断它们是否都在屏幕外是非常耗时的。相反，更快速且同样有效的方法是检查物体的包围体积是否在屏幕外。类似地，我们可以测试物体的包围体积是否被遮挡，而不是直接测试物体的几何形状，这样计算效率更高。至关重要的是，我们的近似遮挡结果仍然是保守的——我们永远不会错误地认为一个物体被遮挡。

在实际实现遮挡剔除时，每个物体应该具有一个预计算的、合适的包围体积，该体积包含了物体的所有几何形状。一般来说，面向的包围盒（OBBs）最为适合（例如，建筑物通常可以紧密地用OBBs包围）。轴对齐包围盒（AABBs）可能适配稍微差一些，但有时由于更容易集成到场景八叉树中，它们会更受偏好。包围球通常适配最差，导致极为保守的遮挡结果。

带有包围球（黄色）和包围盒（红色）的树木显示。请注意，包围球通常比包围盒的拟合度差。虚幻引擎使用轴对齐包围盒进行遮挡剔除。

深度缓冲区

深度缓冲区是单通道图像，每个像素代表与摄像机的距离。对于当前视图，包含场景中所有可能遮挡物的深度缓冲区应在预处理阶段绘制。作为一种优化，可以考虑使用上一帧的深度缓冲区，但这会根据帧与帧之间的运动量引起遮挡结果的轻微不准确。

绘制包围体积

为了检查一个物体是否被遮挡，需要将物体的包围体积绘制到深度缓冲区，并检查修改了多少像素。现代图形API通常提供高效的硬件优化功能，用于计算在一次绘制调用中光栅化的像素数量。

包围体积被绘制到深度缓冲区中以测试遮挡情况。如果非零的绿色像素表示相应的物体是可见的。

在虚幻引擎中，之前被遮挡的物体在随后的帧中被批处理为分组的遮挡查询。这是一种优化，用于减少对持续遮挡物体的遮挡查询次数。在这种情况下，批次中的所有物体都保持遮挡状态。

使用遮挡结果进行剔除

如果没有像素被光栅化，意味着整个包围体积被场景中现有的几何形状遮挡。因此，物体被遮挡，不需要渲染。

遮挡结果需要回传到CPU才能用于剔除。实际上，这需要精心的流水线设计，以避免在GPU与CPU之间的同步引入瓶颈。大多数实现必须接受接收遮挡结果时的2-3帧延迟。它们使用几帧前的遮挡结果来决定当前帧中要剔除哪些物体，尽管场景在这期间可能已经发生变化。值得注意的是，这打破了遮挡剔除的保守性假设——新的非遮挡物体可能在最多2-3帧内看不见。

3D Tiles的遮挡剔除

3D Tiles、分层LOD 和包围体积

3D Tiles是一种用于流式传输大规模真实世界3D内容的分层空间索引标准。在3D Tiles中，3D内容被组织成一个分层的细节级别（HLOD）结构，其中每个瓦片都有一个关联的包围体积。原始的全分辨率几何体被空间上细分为叶子瓦片。层次结构中的内层瓦片使用逐渐较低细节级别（LOD）的原始内容表示。这种HLOD组织结构使得瓦片选择算法可以基于与视图者的距离来选择理想的LOD。与传统的缩放级别不同，3D Tiles基于几何误差LOD选择，允许在同一视图中显示多个级别。

3D Tiles的层次结构是通过瓦片集（tileset）定义的，瓦片集包含了关于每个瓦片包围体积的预计算信息。

在Cesium for Unreal中可视化包围体积的3D瓦片集。3D Tiles允许将高细节模型以分层方式表达，以实现高效的流式传输。

渲染器级别的遮挡剔除

在Cesium for Unreal中渲染的3D Tiles自动利用了Unreal Engine内置的遮挡系统。在Cesium for Unreal中，流式传输的3D Tiles在运行时转换为静态网格。这些网格通常代表地形、建筑物和其他固定几何体，因此这些网格的可移动性设置可以设置为“静态”。Unreal Engine会对这些静态网格进行遮挡测试，以确定哪些网格需要在渲染管线中绘制。通过将对象设置为静态，允许引擎进行进一步优化，如批处理遮挡查询，以处理先前被遮挡的网格。

每个绿色的包围框代表一个在背景中被遮挡的网格，它被前景中可见的建筑物遮挡。

红色线条大致表示冻结相机的位置和视野。这是仅使用视锥剔除而没有使用遮挡剔除时的场景——共渲染了192个图元。请注意，一个瓦片可能包含多个图元。

在启用视锥剔除和遮挡剔除后的冻结视图中——仅渲染了96个图元，而不是最初的192个。

可以看到，与之前的图片相比，缺少了很多图元。Unreal通过剔除被认为被遮挡的场景部分，节省了近50%的原始渲染成本。

Unreal Engine 的遮挡系统实际上并不会开始剔除这些瓦片，直到 Cesium for Unreal 已经获取、处理并加载了它们。例如，比较上面两张图 —— 即使 Unreal Engine 由于遮挡没有渲染这些瓦片，额外的瓦片仍然被加载。

瓦片选择算法中的遮挡剔除

Unreal Engine已经节省了被遮挡物体的不必要绘制调用，但瓦片选择算法可以更进一步，节省被遮挡瓦片的不必要网络请求。作为额外的好处，这也能加速可见瓦片的加载。

Cesium for Unreal在遮挡感知瓦片选择中的方法包括以下步骤。

等待遮挡结果

遮挡结果可能需要几个帧才能到达。默认情况下，如果瓦片仍在等待遮挡结果，我们不会继续遍历它。这可以避免对可能很快被发现是遮挡的瓦片发起不必要的网络加载请求。

在遮挡的瓦片处停止遍历

一旦发现一个瓦片被遮挡，选择算法就不再需要遍历该瓦片的子树，因为所有的子代都可以保证被遮挡。

假设内部瓦片的可见性是一致的

选择算法假设如果一个瓦片有至少一个之前确认可见的子瓦片，它在这一帧仍然可见。这个假设让选择算法能够避免为那些可能“显而易见”的未被遮挡的内部瓦片发起重复的遮挡查询。注意，一旦瓦片的所有子瓦片都确认被遮挡，该瓦片将自动开始再次发起遮挡查询。

选择算法不会遍历被遮挡的节点。对于有已经遍历的子孙节点的内部节点，不会请求遮挡。

简单的剔除可能会导致空洞

当一个瓦片被确定为遮挡时，一种选择是简单地不加载它。这不会影响当前视图，但可能会在相机移动时创建明显的空洞，导致之前被遮挡的瓦片重新显现。这些空洞有时可以通过切换到已经加载的、较低LOD的瓦片来填补。但如果低LOD瓦片有任何先前渲染的后代（之前可见的细节会消失，并被可能是非常低细节的瓦片替换），就无法实现这一点。