radiance和irradiance是什么？
这两个分量有着自己准确的物理定义，但我们简单理解：
radiance是某个方向的光照输入，irradiance是某个位置接收的光照
radiance积分后得到irradiance，irradiance某个方向上求导得到radiance
我们最终应用的光照信息都是irradiance的；
游戏中的GI通常是怎么模拟的？
如果我们假设所有全局光照都是由天光提供的话，那么通常包含：
直接天光 * 天光可见性 + 天光多次反弹结果
同理我们也可以推导出，比如对室内的聚光灯，全局光照结果包括：
直接光 * 阴影 + 聚光灯多次反弹结果
我们可以用上面的公式去计算全局光照，也可以离线直接把计算结果存储下来
要注意，运行时光照计算一定是非常简单的
天光是什么？
天光是天空发出的光，来自大气对太阳光的散射
这里有一些比较反直觉的事情，天光是全局光照里的概念，它虽然属于环境光照，提供了环境照明，但是它却是直接光，我们计算天光的时候会考虑它的直接分量和间接分量
一个比较典型的例子就是洞口，越往内天光的贡献度就越低，如果我们能拟合出这个效果，就会让人感觉很真实
GI为什么可以用球谐函数来存储？
天光和直接光相比不同的地方是它的方向非常多，常规情况下需要用cubemap来存储，比较费
但考虑部分信息是低频的，所以通常用球谐函数来存储，比如irradiance，visibility
此外，虽然radiance本身是高频的，但是由于它与传输项相乘后是低频的，如果我们只关心最终的光照结果，也可以用球谐来存radiance
什么信息对GI来说是最重要的？
遮挡信息，重要度远远大于颜色信息
主要是让人眼感受到画面的颜色不是纯“平”的
全局光的颜色信息简化版本可以完全用IBL来提供，如果想做的比较细腻，会去考虑多摆放一些采样点，接下来就是怎么混合这些结果的问题了
为什么我们通常需要提供单独的AO信息？
传统的path tracing中，我们不会去考虑AO，只会去计算光线的前进路径，AO是为了我们方便计算近似的一个概念
每个方向的可见性本身是积分内部的一个系数，我们把它作为一个单独的积分提取出来
probe因为是空间中摆放的，受限于显存占用，通常是低频的，但是由于我们需要一些比较高频的遮挡信息，所以会把AO存到贴图里或者用屏幕空间AO算法作为补充
可以把AO直接乘到全局光照计算结果上，提供近似的效果
怎么去理解光照的不同分量？
直接天光 * 天光可见性 + 天光多次反弹结果
在这个公式中，我们认为，天光（含可见性）是长距离传输光照，天光反弹结果是短距离传输光照；
对于一些实时的全局光照算法，后者可以用屏幕空间结合世界空间方法来拟合，难点在于可能需要不止一次迭代，因为我们不可能一次就能命中光源方向；前者的难点在于长距离的传播比较耗时，需要依赖于一些加速光线追踪的数据结构；
我们一般怎么存储GI？
有两种形式，一种是存储最终的irradiance，包括直接烘光图，或者irradiance volume，运行时采一次就可以了
前者精度比较高，但显存占用高并且大小和场景物件复杂度相关，后者精度会比前者低一些，但可以作用于动态物件，并且可以集成到延迟光照的时候计算
还有一种是存储一些中间量，比如radiance, visibility, scenedata这些信息，在运行时应用一些简单的计算，这样可以实现一部分动态的效果，比如支持动态光照等；
我们为什么需要体素、SDF这种东西？
本质上都是为了对场景进行建模，对场景建模是为了能加速光线追踪，所以也可以理解为一种遮挡信息
比如SDF记录的是最近深度，体素通常会结合八叉树，那么就可以先以比较大的跨度去做锥形追踪，加快查询速度
虽然说，我们选择对场景做建模相当于拟合了一部分遮挡信息，但是最终是否需要SSAO/SSGI算法，还是取决于数据的精度和频率；这个可以类比到shadow，即使有了阴影，我们也还是需要contact shadow来补充一些近处可能因为bias导致的漏光，或者应对几何复杂度太高常规阴影算法吃不消的case
室内与室外要做什么特殊处理？
室内外最大的差异在于光源来源不一样，室外主要由天光、平行光提供，距离比较远，室内主要由LocalLight提供，距离比较近，如果针对不同的光照特点选择了不同算法，就要做很多区分处理
室内也分为两种，一种是封闭室内，一种是半开放室内，前者比较好做隔离，后者会同时接收两种类型的光源；
还有一个问题是室内外墙壁可能产生的漏光，这个和probe、体素等精度相关，没有什么比较好的通解，更多的都是工程上和内容生产制作团队的磨合
我们实际上在解决什么问题
GI虽然看起来很高级，但大部分人都在解决工程上的问题：
光图的UV和模型缠绕在一起的各种bug
各种probe摆放导致的漏光问题
各种场景中异常发黑/发亮的问题
怎么去做近景、中景、远景的不同处理
如果选择全烘焙方案怎么做流送和压缩来减少包体和显存压力，
如果选择做动态计算怎么做分帧，降分辨率和重要度采样等来减少运行时计算压力
我对Locallight的看法
目前有两种比较常见的做法，一个是基于stencil的，一个是基于cluster屏幕切分的，本质上都是为了省像素计算，但是灯光复杂度一上去性能表现其实都不好，而且遇到了打光范围比较大的情况，基本都束手无策
还有一个问题是，一般这类实时光照算法只会去计算直接光，间接光是不考虑的，这样就会导致对比度很高，就变成了一个非常吃性能效果还不好的东西；所以在我看来如果没能力做好效果，反而不如选择烘焙的方案，如果考虑到希望对动态角色影响，再去考虑probe的形式；
阴影有哪些划分方式？
虽然市面上有很多阴影算法，但本质上都是Fit to Scene或者Fit to View的，在这些基础上会产生很多变体，但基本都是为了针对性的解决不同问题出现的
Fit to Scene的做法效果上会比较稳定，但是划分上可能导致精度偏低，比如如果是想解决转镜头更新问题，那么可以在相机周围去生成，或者多做几级，这样阴影精度低、单次更新量大，但更新频率低；
如果是想解决单次更新量大，有些人可能会去考虑切成tile来更新，但是考虑到阴影剔除的计算方式，这样反而会增加总绘制数量，在应用中要做仔细考量；
Fit to View是利用率最高的做法，精度也是最好的；但是要注意，为了避免更新时的阴影轮廓抖动，需要保证相机的View是固定的，这可能需要我们去用一个球体做包围盒，这样得到的利用率就不是最优的了
也有一些夹在中间的方案，比如上述Fit to View的方案利用率不是最优的，但也意味着它多画了不少东西，这导致镜头移动的时候物件可能还在阴影图上；或者可以不去考虑镜头旋转更新问题，但取比视锥体更大一些的包围盒计算，比如取角色前方的半矩形，来更好地降低更新的频率。
怎么做降配
有一个不得不去考虑的问题就是怎么做降配；
我们不可能给每个分量去提供最准确的计算，比如有些东西不可能实时计算，有些东西只能给近处的提供高精度的计算；我认为有一个非常重要的一点，也反复提及的一点是：不应该通过暴力地砍掉某个分量来做优化，而是要充分考虑到这个分量本身对画面的影响，包括移除后带来的负面影响，以及，是否有更简单的方法去拟合这个分量？
技术方案选型
以下是夹带私货时间：
选择技术方案的时候，我觉得有一点很容易被忽略的，那就是这个方案效果是否稳定
有些东西乍一看在工程上很巧妙，但是使用上有很多瑕疵，我举个例子就是贴花阴影，效果上很容易穿帮，这个会带来很多bug，其实就是测试/美术团队的人力成本，在开发初期一定要和内容生产线对清楚，能不能接受这些问题，如果不太能接受，是不是能作为低配的一个可选方案？
还有一个就是延迟光照发展起来后，需要去选择自己的抗锯齿算法；再加上期望去实时计算一些高级的效果，但是硬件又吃不消，大家就开始盯上了TAA来做拼好帧，越来越多算法依赖TAA来做优化后，技术团队就不得不选择TAA作为抗锯齿算法，再加上DLSS等算法的出现，游戏画面特性可以堆得越来越多，但是观感上反而变得越来越糊了；我觉得在商业引擎当前的发展下，很多算法并不构成技术壁垒，反而是选择用什么才是最重要的
评估方案的时候还有一个很重要的一点是可伸缩性，这个本质上就是降低维护成本，如果一个方案具备很好的可伸缩性，也就是调一下参数就能提升品质/或者做降级，那么也是一个会被优先考虑的做法；但是要注意，不能想当然地认为一个方案具备可伸缩性，比如某些方案可能砍到一定精度后，效果已经完全失真，这个时候只能说明对于想要达到的目标，选型可能是错误的
也还有很多技术方案属于捆绑销售的，比如在场景中生成了SDF，或者生成了HZB，那么其它的算法是不是都可以去用这个数据？一旦有些东西做了完整的基建，那么就会去渗透并且影响到其它的技术选型；以及一些商业引擎主推的方案，也会成为大家的首选，除了能更快看到结果外，还有一方面的原因是降低了解释成本，比如，如果你说我自研了一套全局光照方案，老板很可能会对这个东西产生不信任，这种不信任是人之常情；但如果你说，我用了ue5的Lumen技术，这种疑虑就会被打消，如果越来越多的项目选择使用这个技术，那么对于官方而言也是一种利好；