Game104MordernGameEngine

DirectLighting

构建 Voxel Lighting

• Voxel Visibility Buffer
  

  为了完成采样 Surface Cache 的 Final Lighting，需要知道每个 Voxel 在每个方向上 Trace 到的 Mesh DF 信息，这个信息存储在 Voxel Visibility Buffer 中。与我们熟知的 Visibility Buffer 不同的是，这里存储的内容是 Mesh DF ID 以及归一化的 Hit Distance，在 Injecting Lighting 时就根据这些数据对 Final Lighting 采样。Lumen 将所有 Clipmap 的 Voxel 的 Visibility 都存储在同一个 Buffer 中，并且 Visibility Buffer 是跨帧持久化的，因此为了性能每帧会按需更新内容。
  

• Voxel Lighting 构建优化
  

  每个 Clipmap 有 64x64x64 个 Voxel，由于各向异性光照，每个 Voxel 又有 6 个方向，因此每个 Clipmap 生成全部的 Visibility Buffer 则需要执行约 64x64x64x6 ~=157 万次计算，这个开销很大，难以达到 Lumen 的性能目标，Lumen 采用了下列优化方法：
  

  • 只对有变化的 Voxel 更新 Visibility
    为了实现这一点，Lumen 在 FLumenSceneData 中增加了 PrimitiveModifiedBounds 成员，这是一个 AABB 列表，保存发生变化的空间信息，每帧用这个列表中与每个 Voxel 进行简单的相交测试，如果相交则记录对应的 Voxel，这样就可以筛选出发生变化的 Voxel 了。
    
  • 为了极致性能，Lumen 采用了更加优化的方案。Lumen 使用更粗粒度的 Tile 与 PrimitiveModifiedBounds 列表执行相交测试，由于每个 Clipmap 只有 16x16x16 个 Tile，这样可以极其快速的选出相交的 Tile，每个 Tile 包含 64 个 Voxel，等同于 GPU wavefront\warp 的大小，因此可以通过 Compute Shader 每 Thread Group 处理一个 Tile，一个 wavefront\warp 处理 64 个 Voxels，这样可以充分发挥 GPU 的并行性，极大的提升了构建性能。
    
  • 当 Clipmap 原点变化时会导致 Visibility Buffer 的更新，而 Clipmap 又与相机 Camera 位置相关，但不能使用 Camera 位置作为 Clipmap 原点，否则 Camera 连续的移动会导致 Visibility Buffer 更新频率过高，进而导致 Voxel Lighting 更新过快降低性能并且导致 Lighting 不稳定（闪烁），因此需要离散化方式移动 Clipmap 原点。Lumen 以 Tile 为最小移动粒度，在 Camera 移动时按照 Tile 范围计算并对齐 Clipmap 的 Center，当移动超过 1 个 Tile 的范围时 Clipmap 才会更新原点，而 Tile 的范围大小与 Clipmap Level 正相关，因此 Clipmap Level 越大，其 Visibility Buffer 更新频率越低，Voxel Lighting 就会越稳定。这种方式与 Virtual Shadow Map 的 Clipmap 原点更新机制几乎一致
    
  • 在实际游戏中 Camera 必然是频繁移动的，即使有上述的位移更新策略，当移动距离大于一个 Tile 时也难以避免更新整个 Clipmap 对应的 Visibility Buffer 的情况，开销还是很大。因此为了进一步优化，Lumen 使用了 Scrolling 机制，仅更新有变化的 Voxel，而未变化的 Voxel 可以简单的偏移索引来复用已存在的 Visibility。
    
• 更新 Voxel Visibility Buffer
  
  • 构建当前 Clipmap 所有待更新的 Tile 列表
    
  • 清空所有待更新 Tile 包含的 Voxels 对应的 Visibility Buffer
    
  • 获取所有与当前 Clipmap 相交的 Mesh DF
    这一步是获取需要 Ray Tracing 的 Mesh DF 对象列表，用待更新的 Voxel Clipmap 的 AABB 与每个 Mesh DF 的 AABB 进行相交测试，如果相交则累计记数并将 Mesh DF Index 保存到名为 Lumen.ObjectIndices 的 RDG Buffer 中
    
  • 生成 Voxel Trace Data，为下一步更新 Visibility Buffer 做准备
    将每个与 Clipmap 相交的 Mesh DF 光栅化为 Tile，存储光栅化后的 Tile 坐标以及 Mesh DF ID 作为 Voxel Trace 数据。这里的光栅化可类比于传统 2D 光栅化机制，如果将 Clipmap 视为一个 3D 屏幕，一个 Tile 可看做一个 ”Pixel”，因此这个步骤就是找出每个 Mesh DF 在 Clipmap 这个 3D 屏幕中所占据的 “Pixels”，即 Tiles。由于使用 Mesh DF 的 AABB 来进行光栅化，因此属于保守光栅化.
    
  • 执行 Voxel Tracing，更新 Visibility Buffer
    每 Thread Group 对应一个 Voxel Trace Data，每个 Trace Data 对应一个 Tile 和一个 Mesh DF。由于每个 Tile 包含 64 个 Voxel，总计的 Tracing 次数为 Trace Data 的数量 x 64 Voxel x 6 方向，因此每 Thread 需要 Tracing 6 个 Voxel 的轴对齐方向，也就是进行 6 次 Tracing。每方向执行 Mesh DF Ray Tracing，记录最近 Hit 信息，最后更新 Voxel 对应的 Visibility Buffer
    由于每个 Tile 可能会对应多个 Mesh DF，因此 Voxel 可能会与多个 Mesh DF 相交，而 Visibility Buffer 只需记录最近的交点信息，因此将 Hit Distance 编码进最高位，由于归一化，用 8 位即可。对象类型编码在中间位，根据定义 Mesh DF 优先级高于地形。最后是 Mesh ID，保留 23 位，可最多表示 838 万个 Mesh DF，ID 越小同等情况下优先级越高。根据上述编码规则，写入时以原子比较将最小的 Visibility 值写入到 Lumen.VoxelVisBuffer Buffer 中，这样 Visibility Buffer 中就记录了最近 Hit 的信息。
    
• Voxel Lighting
  
  • 清空当前 Clipmap 的 Voxel Lighting
    
  • 紧致化 Visibility Buffer
    为了最后的 Shading 步骤的更好的并行性能，这一步将离散的 Visibility Buffer 紧密的排列在一起。
    
  • Injecting Lighting
    根据 Direction 索引生成轴对齐方向，再根据 Voxel 坐标及方向生成 Ray，以每个 Voxel 当前反向偏移 Voxel Extent 作为 Ray Start，正向偏移 Voxel Extent 作为 Ray End，并根据归一化的 Hit Distance 和 Voxel Size 计算出 HitDistance, 跟具这些信息调用 CalculateMeshSDFDerivedData 函数获取 Mesh DF 的 MeshCardIndex
    以 MeshCardIndex 为参数，调用 SampleLumenMeshCards 函数采样 Surface Cache 的 Final Lighting，作为当前 Voxel 这个方向的 Radiance，然后计算 Voxel 当前方向的 3D 纹理坐标，写入到 Lumen.VoxelLighting 中，完成光照注入
    

Indirect Lighting

Screen Probe Placement

Screen Probe Atlas

Screen Probe Jitter

Importance Sampling

• Incoming Radiance
  
  • 将当前像素投影回上一帧位置，找到对应的上一帧的相邻的 4 个 Probs，得到当前像素点 Radiance 的估计值
    
  • 不需要很昂贵的搜索，因为可以使用射线直接对 octahedral atlas 进行查询
    
  • 若相邻的 Probes 被遮挡，则使用世界空间的 Probe
    
• BRDF
  
  • 对于放置在一面平整的墙上的 probe，整个球的一半对应的 BRDF 都是 0
    
  • 像素点的 normal 是高频的法线，不能直接用来采样 Probe，应该考虑像素对应位置处一小片区域内法线的整体朝向
    
    • 在 32x32 像素范围内，收集附近 64 个像素
      
    • 只接受深度权重大于 0.1 的像素. (不考虑深度差大的 pixel)
      
    • 将这些像素的世界空间法线累计到 SH
      
• Fix Budget Importance Sampling Based on Lighting and BRDF
  
  • 每个 Probe 追踪固定数量的 Ray（64 条 Ray）
    
  • 为每个 Octahedral Texel 计算 BRDF_PDF * Lighting_PDF，对乘积结果进行排序
    
  • 每有 3 条 rays 对应的 PDF 小于给定的阈值，就可以对 1 条大于剔除阈值 PDF 的 ray 进行超采样
    

Denoising and Spatial Probe Filtering

Screen Space Probes Problems

World Space Radiance Cache

• Probe 放置
  
  • 围绕摄像机的 4 级 clipmaps
    
  • 默认的分辨率为 48*48*48
    
  • clipmap0 的尺寸为 50*50*50 立方米
    
  • 每个 Probe 32*32 Texel (每个 Probe 发射接近 1000 个 ray)
    
• Connecting rays
  

  World Space Probe 发射的射线必须跳过 4 个 World Space Probes 组成的立方体的对角线长度，立方体内部的信息由 Screen Space Probe 发射的 Ray 来考虑
  

  
  

  Screen Probe 射线必须覆盖 interpolation footprint + skipped distance
  

  
  

  Light leaking Problem
  当 Screen Probe 射线被物体遮挡，而 World Probe 射线确没有时，会发生漏光，如下图所示：
  

  
  将 Screen Space Probe 发射射线 a，前进最大距离后，直接将射线 a 和 World Space Probe 发射的同交点射线 b 连接起来，如此处理漏光，如下图所示：
  

  
  

• World Space Probe 更新
  
  • 标记出来 Screen Probe 会用到的 World Space Probes
    
  • 对于每个被标记的 World Space Probe
    
    • 复用上一帧射线追踪的数据，或者分配新的 Probe Index
      
    • 只需要对 cache 的一部分子集重新进行射线追踪