BRDF+Lighting 双 PDF 驱动:Lumen 自适应光线追踪底层原理

BRDF反映的是物体表面对光的作用情况、Lighting则描述的是光线本身

BRDF的PDF加上Lighting的PDF，它们同时作用就能帮助我们决策出向哪些方向发射光线，所以接下来我们来看看Lighting PDF，如此一来你的无用光线就更少，可以节省算力。

ComputeLightingPDF Pass的实现

核心目标：为每个ScreenProbe预计算一套方向概率分布(PDF)，用来做重要性采样，不要均匀瞎发射光线，把宝贵的光线预算砸到有光照贡献的方向上。

关键点：这个Pass不做最终光照积分，只产出「方向权重/PDF」，给后面Trace、Compact、细分做采样引导。

整体数据流总览

1、输入

• 上一帧ScreenProbe的入射辐射（球谐Irradiance / 已经gather到的probe光照）
• 八面体贴图坐标划分：8×8 =64个方向bin，八面体投影把球面映射到2D tile
• ScreenProbeAtlas：所有probe打包到大纹理，每个probe占一块8×8 tile

2、CS线程模型

• GroupId.xy = 当前是哪一个ScreenProbe，默认降了16倍分辨率的那个玩意儿
• GroupThreadId.xy = probe内部8×8八面体方向texel

也就是每个Probe分配一个线程组，组内64线程，每个线程负责球面的一个离散方向bin。

3、输出

每个probe的8×8 Atlas Tile：存储每个方向的PDF值，后续会做计数排序、构建简易CDF，用来筛选高贡献方向、丢弃低PDF方向。

此时不要畏惧，不就是个概率统计学嘛，那高维度的数学还没开始呢，这里就是：P、PDF、CDF，这些在速查手册里都有介绍。

PS：图形学要玩转，数学你还是得去看看物理系或者数学系那边的课程表，你不懂的那里都有！而且还是大一大二的课，计算机系压根就不开这些课，这是搞图形学的一碰到数学方面的问题就头大的原因。

线程组内部完整执行流程

步骤1：八面体方向生成

每个GroupThreadId(xy)对应八面体2D坐标，反投影回球面3D方向向量。

这里就是八面体映射：2D[0‑7,0‑7] → normalize(world‑space方向)。

步骤2：拿这个方向去计算该方向的光照贡献，生成原始PDF

用Probe存储的球谐光照，算出该方向的Irradiance。

注意：这里没有做光线Trace！ComputeLightingPDF阶段不trace任何光线。
PDF来源 = 球谐求出的该方向入射辐照度，亮度越高，这个方向PDF越大。

这就是Lumen重要性采样的源头：哪个方向亮，PDF就高，后续就多分配光线。

步骤3：组内计数排序 64个方向PDF

组内64个线程，每个线程拿着自己的Ray(PDF+八面体texcoord+层级)。
NumSmaller统计：组内有多少个其他ray的SortKey(PDF)比自己更小。
用NumSmaller作为排序后的数组下标，把ray信息写入组内共享内存RaysToRefine。
如此这般：共享内存数组里，从前往后PDF从小到大；靠后的位置是高PDF方向。

这是线程组内局部排序，只对当前probe的64个方向生效，跨probe互不干涉。

步骤4：基于PDF阈值做光线细分

MergeThreadIndex = ThreadIndex %3;
MergeIndex = ThreadIndex /3;

逻辑：

1. 排序完，数组尾部是高PDF方向；头部是低PDF。
2. 如果某个方向PDF低于MinPDFToTrace，代表这个方向光照贡献极低，不值得分配完整一条光线。
3. 不是直接删除丢弃：把低PDF的方向预算回收，把预算合并，给到高PDF方向做方向细分（OriginalRayTexelCoord*2, OriginalRayLevel‑1）。

也就是：一个大的八面体bin，拆成更细的子方向，光线预算向亮的方向倾斜。

• TexelCoord*2：八面体空间四叉细分，坐标放大代表切分成子象限
• Level‑1：八面体mip层级下降一级，代表方向粒度更细
• PDF写0占位：这是细分出来的新子ray，PDF后续重新计算。

原始输入是8×8=64个粗糙方向；经过细分之后，实际参与后续Trace的ray数量不一定等于64。低PDF的方向被合并回收预算，转化成高PDF方向的更多子采样。

步骤5：输出排序+细分之后的ray列表

输出到UAV，给到下一个Pass CompactTraces，把需要真正执行Trace的光线信息打包输出。

此时还没有跑TraceScreen / TraceMeshSDF / TraceVoxel。
ComputeLightingPDF只完成：方向打分、排序、预算重分配。
真正的光线追踪是后面的Pass干的。

整个链路逻辑：

先用球谐粗估各个方向会有多亮（ComputeLightingPDF）→ 根据亮度重新分配光线预算，亮的方向多采样、暗的少采样甚至合并 → compact压缩光线列表 → 才真正跑光线追踪拿真实光照。

这就是祢神演讲里“每个像素发射半个光线”的底层由来：不是每条方向都真的发射一条完整光线，暗方向被合并，预算被挪去亮方向，平均每个probe实际trace光线数量低于64。

书院进度

《游戏引擎开发实践》 资料片方面，即将完成2025年的资料片内容Lumen，虽然说是Lumen，但实际上是对整个游戏引擎课程的一次完善，因为Lumen牵涉到了很多章节的知识点，它自己只是一个缝合怪：

• 正在推进TraceVoxel更新的教学(要烂大街啦！)

2026年我们规划中为同学们安排了这些小课程：

• 《Metal萌谷手册iOS版》(刚建好文件夹)
• 《Metal萌谷手册Mac版》(刚建好文件夹)
• 《WebGPU萌谷手册》(刚建好文件夹)
• 《Vulkan硬件光线追踪》(刚建好文件夹)
• 《DXR硬件光线追踪》(刚建好文件夹)

联系我们

• 图形学技师研讨会1：460926233(满)
• 图形学技师研讨会2：719446549
• 微信：battlefireedu
• 官网：https://edu.battlefire.cn
• 做智能硬件渲染有瓶颈的欢迎把设备发过来，帮看渲染性能问题和瓶颈
• GPU厂商欢迎发你们的产品过来，让我们把玩把玩，测评测评

每天进步一点点，来东汉书院躺平，享不卷游戏人生！