虚幻4中的物理灯光5——Physical Lights in UE4
续续前言：本文属于闲暇时间的美术向技能吹逼，不保证能适用于任何项目，只阐述制作过程和思路，不打包票能学会。如有错误或不足之处敬请大家指正说明。
续续前言2：目前没有找到其他什么很靠谱的物理灯光解决方案，如果有大佬了解希望留言交流一下。
昨天咱们讲到如何在UE4中根据现实世界的相机参数来设置EV，
今天咱们来讲讲物理灯光的一系列bug
惯例先附上本文主要相关的链接，其他链接放文末。51Daedalus咱这次就不放了。这次还放的是Aesir Interactive GmbH的Lukas Lang所写的有光物理光照的文档，还有社区的物理灯光线程。
然后再插一个Luoshuang's GPULightmass
为什么要另插呢，因为今天这事跟他有关
好，咱们先介绍一下Luoshuang的GPU烘焙工具。
1.Luoshuang的GPUlightmass
在公历二零一八年四月十三日凌晨一点四十四分，伟大无私的Luoshuang先生在论坛中上传了他的GPU烘焙工具（下面简称落霜，本来想写罗爽的/doge，）
这个工具是整啥的呢，它能够让我们的烘焙速度和烘焙效果大幅度提升。
在发现这个工具之前，我对引擎默认的CPU的烘焙设置也算是有所研究，但是很少能够找到一个效率与效果平衡的参数。并且在他的文中有这么一张图吸引了我。
大家可以看到，在CPU烘焙中，常见的物体之间的接缝暴露出来，而GPU渲染中不但没有接缝，并且光线细腻很多。落霜是用了Brute Force算法替换了Irradiance Caching，了解VRay或者其他渲染器的朋友应该都有听过这种BF算法，精度会更好，但是时间会更长，不过落霜使用了GPU来烘焙，速度有很大提升。
那有的朋友会说了，这接缝其实通过调整下光照的参数配置，提升下烘焙质量，调高点lightmap大小，就可以轻松解决掉啦。
而这两张图都是用的一样的lightmap大小，并且GPU的设置非常简单，几乎无需操作，最爽的是，它是用GPU渲染的，速度比CPU快N倍。就相当于，我们用很简单的配置，一样大的lightmap精度，更少的时间，却获得了更好的效果。
GPULightmass usesBrute Forceas its Primary GI Engine and some form of radiosity caching as its Secondary GI Engine, which is very similar to vray.
Brute force is much more accurate than Irradiance Caching (Lightmass's primary GI engine) but it is also slower. It is also more sensitive to lightmap resolution since it actually calculates each lightmap texel, while irradiance caching is more or less resolution independent. You may want to tune down your lightmap resolutions firstly then slowly tune them up when working with GPULightmass.
Luoshuang's GPULightmassLuoshuang's GPULightmassLuoshuang's GPULightmass
而作者也说了这个东西目前有的一些问题，比如不支持固定（Stationary）的skylight，不支持SourceLength和SourceRadius以及IES，（这些将通过CPU计算）
相信用过的朋友都知道这个工具有点意思，出图快，效果干净，很多做效果图的朋友已经替换上了这个工具。
在翻了81页的这个GPU线程之后，我又翻了18页的物理灯光线程，发现有一些其他的问题。
2.GPU的物理天光烘焙问题
rosegoldslugs在55页提出了GPU烘焙使用物理数值出现的一些bug，在高强度的天光下，GPU烘焙没有得到正常的效果，并且有很多人也指出了这个问题。
所以大家在使用GPUlightmass的时候要注意对比物理灯光的效果，目前我所测试的结果都是偏暗的。
当然这个GPUlightmass工具还是非常非常好使的，推荐大家尝试一下。
那么具体是什么问题，这里我们插入一个测试：
左图4.20，右图4.21，
都为CPU烘焙、使用Skylight获取Sphere亮度照亮场景，
左边的skylight的阈值为10000，右边为3000，
Sphere半径同为20000，获得光照结果一致。
上面两张图证明了，skylight阈值小于Sphere半径的时候，将会获得Sphere的照亮。
3.CPU烘焙的阈值问题
但是，
当我们把左边的阈值改成15000的时候，场景变暗了
是引擎版本的问题吗？不是，我们把右边的也改成15000，场景也变暗了，
这搞啥呢？
设置个参数咱们还得猜数字吗？
猜就猜吧，还能咋滴。
咱们把skylight改成固定，然后通过拖动数值，可以发现随着数值的变小，场景开始变亮。
最后咱得到一个数值，阈值13000可以得到跟3000一样的光照效果。
（14000也不行，13333都不行，甚至13133都有误差。所以这个13000:20000的比例我还真想不到是怎么算的）
阈值小于天空球，还得多小那么一小段才不会出错，于是为了防止它太小也会出问题，我顺便试了一下很小的数值5m，发现结果倒是没问题，不过这里需要注意的是，我这个场景五米开外就只有天空球了。
那么CPU的问题咱们先记到这，
接着切GPU烘焙，
4.GPU的skylight物理数值测试
这一换上GPU啊，那这烘焙速度跟烘焙效果，杠杠的。你看这右边什么玩意啊。
而且亮度已经跟CPU不一样了。同为3000阈值，差了百分之一，当然这误差可能是因为CPU烘焙的比较干净导致的。
那么这时候，咱们就上物理数值吧。
先上咱昨天算出来的EV，很好，CPU同学跟GPU同学一起黑了下去。
这天空盒的亮度咱们就肉眼直接拖上去，然后感觉看的到了就停下来，咱这里取个整数，66666，可以发现环境已经亮了起来。
接着就开始烘焙了。
这烘焙速度可真的快，我差点没截到这个GPU提示框出来。
但是，上图其实已经烘焙完了，左边照样是黑的，右边却是正常的。
咱们把阈值调到10000，还是没卵用。
而在skylight在固定的时候，我们是可以看到10000的阈值是可以照亮场景的。
所以这个bug很迷。
而当我们把skylight的强度提上去，改成100的时候，场景才出现烘焙效果。
而这个skylight100相当于在原来的66666强度上叠加上去的
也就是在GPU烘焙的时候，静态的skylight似乎获取不到正确的天空球的亮度，
但是是这个结论吗？
那我们进行另外一种测试，把天空球隐藏掉，直接使用skylight进行照亮场景。
可以看到，左侧的结果仍然不对劲。
所以可能是：使用物理数值的静态skylight在GPU烘焙中有问题。
那咱们也不能瞎说是吧。咱把EV跟skylight强度改回非物理数值，
现在的EV是0，skylight的强度是1，并隐藏了天空球。直接使用skylight+HDRI照亮场景。
然后再多测试一个，天空球强度为1，EV是0，使用skylight捕获天空球亮度的环境。
可以看到GPU烘焙很正常。
这就是咱们今天讲的第一个物理灯光BUG，适配GPU烘焙的BUG。
不过这里要提的是，并不是每次都会出现这种bug。
5.UI显示bug
直接上图
来自Lukas Lang分享的物理灯光文档中提到的bug，ui会过度爆亮，解决方法是在末尾除以个人眼适应的函数。
6.Shader的bug
论坛线程中提到的部分材质的曝光，也可以使用这个人眼适应函数来修改。
7.指数高度雾非常黑。
需要大幅提高雾的亮度。（或者加个人眼适应？）
以上就是大概的使用物理灯光会出现的问题了。
其实说了这么多，从第一篇到现在第五篇，我们讲了物理灯光的原理及引擎中的使用过程，而到最后却发现暂时没有一个很和谐的方法来使用这个灯光。
如果冒然把物理参数使用进制作了一部分的游戏项目，可能会导致大量的shader及灯光修改，还有暂时还没测试过特效在这种物理环境下会不会受到很大影响，估计多多少少也是会的。
那这意思是，这五篇咱们就白说了吗？
当然不是，下次，我们将开始新的内容
如何不物理的使用物理灯光
好了，下次再见
QQ微信同号：342193679
QQ扫码直接加入
