TerrainRenderingInFarCry5

Terrain Quad Tree 使用两个链接在一起的 GPU 对象来实现。
第一个 GPU 对象是 mip-mapped 贴图：Mip0 有 160*160 个贴图图元。6层四叉树，每一层对应一个等级的 mipmap 贴图。贴图中的一个贴图图元代表四叉树中的一个节点。

贴图中存储一个 16 位的索引(mip-mapped 贴图的格式为 R16_UINT)，其可以索引到第二个 GPU 对象。

第二个 GPU 对象是 Node Description Buffer: Node Description Buffer 是一个简单的数组。其记录了我们加载完成的节点的一些信息，如：最小和最大 terrain 高度，节点的贴图在贴图 atlases 中的位置。节点数据被打包为两个 uints. 我们在 CPU 端保存了一份节点数据的 shadow copy，用于跟踪节点的分配。

每当我们加载一个节点后，我们都会将该节点对应的描述信息加载到 NodeDescriptionBuffer 中一个可用的 slot。我们会在每帧都执行一个 compute shader，用于在 NodeDescriptionBuffer 中添加或删除节点(对应于节点流式载入和卸载)描述信息。

注意，mip-mapped 贴图中有两个特殊值，其意义如下：

• 0xffff 表示空值，意味着该四叉树节点未被加载
  
• 0xfffe 表示不可用值，意味着其不对应任何四叉树节点
  

这些特殊值，保证我们可以正确地遍历四叉树（遍历时可正确忽略不可用的节点）。

Terrain Node List 是一个简单的节点列表，其表示我们潜在的可以进行渲染的节点列表（执行任何可见性测试之前的节点列表）。每一帧通过遍历四叉树结构（前一节提到的 Terrain Quad Tree）来计算出该列表。

我们使用一个 compute shader 来对 LOD 层级进行遍历，在每个阶段，一个 thread 处理当前 LOD 的每个节点，并且可能会将节点细分为多个子节点。下面会给出这个处理过程的细节。
首先，我们从最低级的 LOD(LOD2) 开始，用该 LOD 的所有节点的索引填充一个 temporary buffer A。
其次，我们希望这些节点细分为他们的子节点。我们读取 temporary buffer A，并且将会输出两个 buffer：一个 temporary buffer B 和一个最终结果 buffer Final。
对于 buffer A 中的每个节点，判断其能否被细分为多个子节点，如果可以，则将它的子节点添加到 buffer B，否则，将其添加到 buffer Final.

关于 LOD 标准：
在 Far Cry 中，我们会基于节点到一个或多个摄像机的距离来确定 LOD 标准。另外，我们还会考虑每个节点的 LOD bias，从而可以强制部分节点使用更高的细节。

在下一次 dispatch 时，compute shader 将会读取 temporary buffer B，执行相同的逻辑，将结果输出到 temporary buffer A，和 buffer Final。我们有 6 级 Lod，一共执行 6 次就可以得到最终的 Terrain Node List。

同时，我们还在 buffer 中存储了每个 LOD 中节点的个数。为每个 pass 使用 一个 compute shader dispatch，可以很优雅地完成该过程。然而，我们还是需要对每一个 pass 进行两次 dispatch，因为我们需要一个额外的 dispatch 来填充 indirect args buffer，以便传递数据给下一个 pass. 而且每次 dispatch 都涉及到一个小的同步开销。所以，在 Far Cry 中，为了将性能成本降到最低，我们在单个 dispatch 中处理所有的 passes，将中间数据存储在 LDS 中。我们之所以可以这样做，是因为我们有一个固定的节点数量上限，而且这个上限小于最大可用的 compute shader group 大小。

每帧我们都需要完全填充一个 8 位的贴图，每个贴图图元记录 Terrain 上每个 sector 对应的 LOD 级别。我们只需要这个信息来做一件事，那就是检测我们需要在哪儿缝合不同 LOD 的 patches。注意，当当前 patch 所相邻的 patch 的 LOD 更低时，我们才修改当前 patch 的顶点。所以，通过将空白区域填充为 0，我们有效地忽略了它们。

为了构建 LOD map，我们需要对前一步生成的 Terrain Node List 进行处理。对于每一个节点，我们将其对应的 LOD 等级填充到该节点覆盖的 sectors 中。

注意：

• 不要使用 NodeCount 个 threads 来填充 Terrain LOD Map。在最坏的情况下，每个 thread 需要写 32*32 次值。
  
• 应该使用 SectorCount 个 threads，并且从 Terrain Node List 中获取写入的值。每个 thread 只需要写入 1 次或 0 次值。
  

Visible Render Patch List 是最终的数据结构。其为一个简单的 buffer，其包含一个 terrain patches 列表，对应于在单个 instanced draw call 调用中，我们希望实际渲染的内容。该 buffer 还伴随一个 IndirectArgs buffer 用于驱动 Draw Call。

patch 结构包含了 world position，size，以及 patch 所采样的贴图在 texture atlas 中的位置。

我们将 Terrain Node List 中的每个节点分为更小的 patches，并且剔除哪些我们不需要渲染的 patches。
每个节点被划分为 8*8 个 patches。每个 patch 会被渲染为一个 16*16 大小的 vertex grid。这样的划分非常好，因为一个 wavefront 中的 compute shader threads 刚好可以处理一个 patch。

对于每个 patch 我们执行如下操作：

1. Frustum cull
   
2. Occlusion buffer cull
   
3. Back face cull
   
4. Calculate and pack LOD transitions into patch data
   

我们使用了降分辨率的保守深度缓冲区来剔除 terrain geometry.
在 console 平台，我们使用了 GPU 最佳的 occluder pass 来填充 depth buffer 并且提取 HTile.
在 PC 上，我们有一个软件光栅化的 occlusion buffer，我们已经使用它来做 CPU 端可见性检测，我们将其上传到一个纹理。

然后，我们会为 occlusion buffer 生成 mipmap，这样我们就可以在多个不同的物体尺寸上进行深度比较了。

在 culling pass 阶段，我们执行如下操作：

1. 获取 terrain patch 的 bounding volume
   
2. 确定投影到屏幕后的屏幕范围
   
3. 在 mip 层级中，查找 1 个或多个覆盖该屏幕范围的样本
   
4. 测试并进行保守剔除
   

背面剔除需要进行 offline 处理。

在 offline 步骤中，我们为 patch 的每个三角形生成世界空间的 normals。然后，我们在球上找到一个最小的圆，该圆可以包含所有的 normals，可以将其可视化为一个圆锥。
一个 patch 对应的圆锥可以用一个 normal 向量和一个半角表示，将 normal 和 half angle 打包到一个贴图图元中。一个节点有 8*8 个 patches, 存储一个节点的圆锥信息需要 8*8 的贴图，贴图格式采用 BC3，两个颜色通道存储 normal，一个 alpha 通道存储半角。贴图存储方式会有精度问题，所以我们需要为保守测试留一些余地。

Real Time Collision Detection Ericson 论文描述了如何获得 normals 的最小 bounding sphere。

在运行时，我们采样该 patch cone 贴图，并和 camera 方向进行测试，以确定是否可以剔除该 patch。检测方法并非简单比较 dot(cameraDir, coneNormal)和 sin(coneAngle)，因为 cameraDir 在 patch 的不同地方是不同的。为了保守剔除，我们需要检测 cameraDir 和 patch 的 4 个角。

The Cone of Normals Technique for Fast Processing of Curved Patches 论文描述了如何检测 patch 是否背对 camera。

每个输出的 patch description 存储了一个 packed LOD 描述信息。
这个信息是当前 patch 四个方向上与相邻 Patch 的 LOD 差值。该信息为 16 位，每个方向 4 位。

在 culling pass 期间，通过采样每个 patch 周围的 LOD Map，可以得到 LOD 差值。在后续的 vertex shader 中会读取该数据来执行 mesh 缝合。

不包含 rendering 的情况下，GPU Pipeline 总的耗时每帧为 0.1ms。其中大部分可以在一帧的早期异步计算，使得其消耗几乎免费。

当两个 patches 来自不同四叉树 LOD 层级，我们需要保证这两个 patches 的所有相邻顶点能够被缝合，以避免不同 patches 之间的接缝。

我们通过读取在剔除过程中创建的 LOD packed data 来知道一个 patch 是否连接到低 LOD 的 patch。在顶点着色器中，我们可以简单地将 patch 边缘的顶点变形到所需细分级别的最近的顶点。
在下图中，我们看到的是 LOD 相差 1 的情况，两个顶点一组，把第二个顶点直接移动到第一个顶点的位置。

在下图中，我们看到的是 LOD 相差 2 的情况，四个顶点一组，后三个顶点全部移动到第一个顶点的位置。

洞穴/掩体的开口周围需要有洞。在 albedo map atlas(BC1 格式)的 1 位 alpha 通道中，存储 terrain holes.

通过在 vertex shader 中将输出的 projectedPosition 设置为 NaN 来剔除地形的顶点。将输出的 projectedPosition 设置为 NaN 在 Graphics API 中没有明确的说明，但是所有 GPU 硬件似乎都支持。这种方式比其他方案（在 pixel shader 中使用 discard，或者为带有洞的 patches 使用特殊的几何）都要高效。

一个顶点被剔除后，所有关联的三角形都会被剔除。所以，剔除中心的顶点会剔除 8 个三角形，如下图所示：

这使得 hole 的分辨率只有 terrain 分辨率的一半。但对于我们的场景设计师来说，0.5 米的地形对应 1 米的洞是可以接受的。

• 使用我们的 SplatMap 来渲染缓存的 Texture Pages
  
• 每帧渲染 6 个 pages。1Page = 256*256 texels + 4 texel border
  
• 使用 compute shader 将 page 压缩为 BC 格式
  
  • 2 * BC1(Albedo/Smoothness/Specular Occlusion)
    
  • 1 * BC3(Normal Map)
    
• 在渲染下一个 page 时，利用 async compute 压缩刚渲染好的 page
  
• 总的 GPU 消耗为 1ms 每帧
  

我们需要跟踪哪些 texture pages 需要被更新。因此，渲染 terrain 时，我们还会将请求的 pages 写入一个有界的 UAV。然后，我们将该 UAV 读回到 CPU 来确定接下来优先渲染哪些 pages。(UAV is unordered access view)

UAV 的大小为完整 render target 大小的 1/8，从而保证 CPU 读回消耗比较低。我们在 64 帧内，对屏幕空间样本位置进行 jitter，从而保证经过 64 帧后，我们收集到所有的 page IDs。

由于我们使用了虚拟纹理，我们可以用很少的额外成本合成多层的道路和贴花。
你可以在下图中看到实际的视觉效果: 在地形细节纹理渲染的基础上，渲染了一个道路贴花。多个贴花又被渲染在道路贴花上面。

下图是贴花 overdraw 的可视化，我们几乎是免费获得的这种效果。

经典的解决方法是使用 triplanar mapping。按照世界法线和世界坐标轴的夹角来混合世界坐标的 3 个投影。使用 tri-planar mapping，我们需要执行完整的 splat map 计算 3 次，这需要进行 48 次贴图采样。

我们可以使用 virtual texture 代替 z projection 来减少一些采样，但是消耗依然很高。

在启用 triplanar mapping 的情况下，还有另一个问题，悬崖可以在离玩家很远的地方看到，这使的 texture tiling 变得很明显。

如果我们使用一个固定的值作为我们的 texture tiling scale，并针对近处的地形进行调整，得到如下结果：

我们更希望 uv 空间在屏幕空间内更加恒定。这样可以得到如下结果：

现在画面显得更加合理了，地形和悬崖的纹理可以展示出分形，并且在多个尺度上效果都很不错。

但是，基于距离修改 tiling 会导致贴图的不连续。我们需要混合两种不同的缩放结果。再叠加上 triplanar mapping 的消耗，我们现在需要执行 96 次贴图采样!

我们探索了如下一系列更便宜的方案：

1. 为 cliffs 使用不同的着色模型
   
   • 会导致一致性问题。
     
2. 使用几何来代替基于高度图的 cliff，几何中预先烘培好 uv
   
   • 我们在某些地方使用了这个方案
     
   • 但是内存预算和产品成本是个问题
     
3. 根据 projection 分解地形网格
   
   • Ghost Recon Wildlands 使用了该方案
     

我们的解决方案是，生成一个 virtual texture atlas 来容纳 cliffs。

一个略显疯狂的想法是使用随机的方法来混合我们不同的 shading inputs。如下图中，展示了对黑和白进行混合。图上使用了标准的 alpha 混合，图下使用了随机混合。 随机的结果在每个像素上都是不正确的，但 "平均"来看是正确的。

对于地形渲染，对于每个像素我们不再对多个 splat map 采样做混合，我们只需要选择一个 splat map 进行采样。按照随机的方式为每个像素从输入列表中选择一个 splat map 进行采样。我们只需要按照混合因子来对随机选择进行加权，从而可以更多地选择权重大的样本。

我们实验了以上方案，但是效果不够好，噪声很严重，而且不稳定。

在《Far Cry 5》中，我们用 Terrain Displacement Decals 扩展了我们的 virtual texture decal system。Terrain Displacement Decals 是普通的贴花，会被渲染到虚拟纹理中。但它们也有一个匹配的简单 mesh，我们将用它来给地形定形。

mesh 会被放置到 terrain 上与匹配的 decal 相对齐。然后，pixel shader 会采样 terrain virutal texture，其中包含了该 decal。如此得到的结果就可以无缝地混合到地形上(因为 decal 已经通过 alpha blend 到 virtual texture 中了)。

在 Far Cry 5 中，我们随处都使用该技术，用于石头装饰、轮胎痕迹等等。下图展示了 Displacement Mesh 开启和关闭的对比：

Displacement Mesh 关闭时，我们也可以看到石头和树根，这些 decal 已经被渲染到 virtual texture 中了。Displacement Mesh 开启时，这些物体会显得更立体(树根比较明显)。

这种方法是对 terrain tessellation displacement mapping 的一种替代。我们也实现了 terrain tessellation displacement mapping 方法，但由于成本问题而没有采用。

使用 Terrain Displacement Decals 代替 terrain tessellation displacement mapping 的优缺点
优点(Pros)：

• 非常廉价（无需 tessellation shader 和 minimal vertices）
  
• 所有 mesh 可以使用一个共享材质，从而可以 batching 在一起渲染
  
• 可以方便地调整 mesh LOD 和位置以满足性能和画质要求
  

缺点(Cons):

• 需要人力摆放 (但是，我们使用程序化方法来放置)
  

Far Cry 5 添加了一个程序化生成 cliff 的管线，其会将独特的 cliff 几何添加到场景中。cliff pipeline 检测出 cliff 区域，然后在这些区域创建 mesh。

Cliff Geometry 添加了形状和变化性，减少了一些 "height map" 感觉。下图是 Cliff Geometry 开启和关闭的对比：

这些独特的几何只有顶点位置和法线数据，因此非常的轻量。最关键的是，我们可以完全按照地形高度图的方式对 cliff 几何体进行着色。所以我们使用相同的着色器/地形纹理等。这意味着我们可以保证高度图和悬崖网格之间的 shading 是一致的。

最简单方法是为 patch 选择优化的 Shader ID。在 culling pass 中，我们确定使用哪个 Shader ID 并将每个 patch 添加到对应 Shader ID 的 bucket 中。该方法基本是免费的，但是，其并非总是最优的，当 patch 足够大时，该 patch 内会有很大变化。另外这种方法只适用于我们的高度图几何（heightmap geometry）。如果我们还想将地形着色器用于程序化的悬崖几何，那么我们也要为该几何体优化着色器选择。

也可以使用 compute shader 来分析每个 patch，并为每个 Shader ID 生成单独的三角形列表。这与 Ghost Recon 在 2017 年 GDC 上分享的方法很接近。

另一种方案是，按照屏幕空间的 tile 来选择 Shader ID。这允许我们严格限制 expensive shaders 的边界，如下图中对比所示。这种方法还适用于程序化生成的崖壁几何。但是，这也意味着我们需要在屏幕空间进行 shading，我们恰好是这样做的。

首先，执行一个 terrain geometry pass, 其会渲染地形 depth 和 stencil 以及一个类别 RT（classification render target）.

8 位 classification RT 包含每个像素的 最优 ShaderID，其为 5 种渲染方式的位掩码。下图中，我为不同类别(classification)分配了不同颜色，使的更容易区分。

然后，我们执行一个全屏的 Classification Pass，该 pass 使用 compute shader 实现。在这个阶段，会读取 classification buffer，并且按照屏幕 tile，执行 Shader ID 的异或操作，从而得到 tile 对应的 combined Shader ID。最终，为每种 shader variation 输出一个 tiles 列表，以及一个 IndirectArgs，用于驱动下一步的 pass。

我们发现 tile 的大小选 8*8 是最优的。我们可以读取 stencil 来拒绝不包含 terrain 的 tiles，所以我们不需要 clear classification RT。
在 console 平台上，我们可以使用 swizzles 来执行 Shader ID 的异或操作，将 tile 加入列表时，可以使用 ballot 来减少内部加锁操作。

最后，我们为每个 Shader ID 提交一个 tiled 的像素着色器 draw call。该 pass 会读取 stencil 来拒绝不包含 terrain 的 pixels，然后会读取 depth 并将 terrain 渲染到 G-Buffer.

下图展示了这 3 个 Pass 的数据流程：