虚幻引擎(UE):HZB是什么？如何在UE4移动端中实现HZB？

Hierarchical Z-Buffering分层Z缓冲（HZB）对遮挡剔除研究具有重要影响，是GPU Driven Rendering Pipeline的重要剔除手段。目前部分主流商业引擎可能因为某些原因导致该技术无法完全在GPU端工作，但依然是值得探讨的。本文先介绍HZB的基本原理以及UE4在PC端的实现方式，然后介绍如何移植到移动端并分析其性能和带来的价值，以及未来还可以做的工作。

一、HZB的原理

一般来说，大多数基于HZB的遮挡剔除是这样的工作的：

1. 使用一些遮挡器生成一个完整的分层Z-金字塔。

z-pyramid的最低级别是一个标准的z-buffer。在所有其他层，每个z值都是上一层对应的2×2像素中最远的z。

2. 要测试的对象是否被遮挡，可以将其包围体投射到屏幕空间，并在z-pyramid中估计mip级别。将对象的包围体投影到屏幕空间。最长的边l(像素)用来计算mip等级λ。

边长越长，选取的mip等级越高。

3. 根据选定的mip测试遮挡。如果结果不明确，可以继续使用更细的mip级别进行测试。

这个选择的原因是它使成本可预测——最多需要读取和测试四个深度值。此外，这种测试可以被看作是“概率性的”，因为大对象比小对象更容易被看到，所以在这些情况下没有理由读取更多的深度值，即节省了带宽，也增加了Cache命中。

二、UE4的实现

UE4只在PC端进行了实现，过程大致一样，不同的是在构建层级Z缓冲上分为ComputeShader和PixelShader两种方式，然后最终剔除工作主要在CPU端进行，意味着需要回读GPU的测试结果。以下是UE4的工作流程：

1. 使用SceneDepth作为数据源构建层级Z缓冲。Mip0为第一级，大小为1024*512，总共构建10级。分为两种方式，PixelShader方式比较简单，一次构建一级，总共执行十次。ComputeShader则稍微复杂一点，利用GroupMemoryBarrierWithGroupSync，每次同时构建4级，总共只要执行3次，便完成构建。

2. 场景中的物体经过视锥剔除以后，剩下的会被收集起来，存放在一个数组中，并且每个物体会保存自己在数组中的索引值。然后，创建2张RGBA32格式的贴图，一张存放物体包围盒的质心坐标，一张存放物体包围盒的大小。每次从数组中取64个物体作为一组，保存到贴图的64个像素区域中。

3. 采样第二步中的贴图，获取物体的质心坐标和包围盒大小，可以计算出物体包围盒的八个顶点的世界位置，对这八个顶点进行投影，选取其中最近的Z值。根据投影后的矩形区域，选取最长边长计算mipmap等级，然后在矩形区域内采样该mipmap的16个像素，选取其中最远的Z值。如果包围盒最近的Z值比它还小，则物体不可见。将结果保存到一张格式为RGBA8的RenderTarget中，作为下一帧读取。

4. 当前帧读取上一帧的贴图数据到一个数组中。每个物体将上一帧保存的数组索引到该数据进行查询，查询结果决定了该物体在当前帧的可见性。

以上步骤看出，UE4的HZB实现流程没有完全放在GPU端执行，在下一帧的时候需要回读上一帧的结果，然后进行查询以决定物体当前帧的可见性。另外，在第三步中，计算最远Z值时，采样了矩形区域内16个像素，而不是4个像素。

三、移动端的实现

移动端的HZB方案大部分可以与PC端共用一套逻辑实现，然后针对移动端性能点进行优化。移动端需要解决的第一个首要问题就是SceneDepth的获取，因为它是构建层级Z缓冲的重要数据来源。

在移动端上，一般来说，如果存在后处理材质需要访问场景深度信息，UE4会将场景线性深度值保存在SceneColor的Alpha通道。而对于透明材质，如果使用了DepthFade材质节点，则会通过移动设备扩展API来直接提取FrameBuffer中的深度信息。

那我们如果想在移动端上直接访问深度纹理的话，需要怎么做了？可以通过设置r.Mobile.ForceDepthResolve为1来始终保留移动端的深度信息。强制深度解析，为设备保留深度纹理。

移动端获取深度纹理

获取了深度纹理，就可以开始构建层级Z缓冲。考虑到移动设备的兼容性，这里只使用了PixelShader方式，依然构建了10级mipmap。为了保证深度值的精度，这里将每个深度值编码到rgba8888格式的贴图中。

移动端构建层级Z缓冲

构建完层级Z缓冲以后，接下来就是进行遮挡测试。算法沿用了PC端的方式，将结果保存在贴图中，下一帧回读。移动端上回读GPU贴图数据，需要注意的是，UE4会默认处理上下翻转。因为这里只是存放遮挡结果的数据贴图，所以不需要做上下翻转。

最后一步遮挡查询，过程和PC端一样，每个物体用上一帧的数组索引去查询自己当前帧的可见性。

优化读取性能

移动端回读GPU数据相当耗费性能，我们可以来看下glReadPixels分别在oppo手机型号为r15和r17上的测试结果：

r15耗时6~8ms

r17 耗时 16~20ms

直接调用glReadPixels相当慢，不过，好在目前大多数移动设备的opengles已经达到3.0以上，所以，可以考虑使用PBO的方式进行优化，使用 glMapBufferRang进行读取。过程大致如下：

1.初始化2个buffer。

2.buffer1用于异步glReadPixels读取，buffer2用于glMapBufferRange读取。

3.下一帧交换buffer，buffer1用于glMapBufferRange，buffer2用于glReadPixels。

再来看下，优化后的测试结果：

优化后，r15耗时0.9ms

优化后，r17耗时4~6ms

硬件遮挡查询和 HZB在oppo r15上的性能对比

经过初步优化，我们来看下，硬件遮挡查询和HZB各自在手机上的性能对比。测试分为静态物体和动态物体。新建一个场景，场景内随机生成10000个物体。在分别只开启硬件查询和只开启HZB的情况下，对帧率和被遮挡物数量的影响。UE4针对硬件查询做了Batch优化，这样可以大大降低硬件查询带来的DC开销，不过Batch只对静态物体有效。所以，需要分开测试。

动态物体：

如图，只开启了硬件查询，因为动态物体无法Batch，Occlusion queries相当高，达到987，而draw call数量达到了1450。被遮挡物体为579，可见物体为411。帧率只有18。由此可见，对于大量动态物体，硬件查询本身带来了巨大的DC开销。