随着2022.2 Tech Stream发布,Progressive Lightmapper的光照烘焙迎来了性能和稳定性,以及一些用户使用体验的改进。我们还改动了高清渲染管线(HDRP)的路径追踪,为Adaptive Probe Volumes (APV)预览版加入了几项新功能。另外,我们还将有计划地弃用Enlighten。请在下文了解所有更新的精华内容,在文末了解大致的Global Illumination(GI)开发路线。
在Global Illumination 2021更新的论坛贴中,我们详细介绍了全局光照路线图以及弃用Enlighten的计划。目前该版本的Enlighten Realtime GI并不受计划影响。
对于Baked Global Illumination(烘焙全局光照),我们仍在着重提高GPU Lightmappper的稳定性和兼容范围,以交付一款快速、稳定的解决方案,惠及更多人。
我们正按照既定计划弃用Enlighten,首先就从Enlighten Baked GI开始。Unity的Lightmapper已经作为该GI的替代方案使用了数个版本。如果你正使用着Enlighten Baked GI,并且打算升级至2022.2及以上版本,推荐你在项目里转而使用Lightmapper。
在2022.2版本,API内的Enlighten Baked GI已被标注成“obsolete(废弃)”。该标签默认将作为生成Baked GI的隐藏选项置于编辑器的Lighting设定下。如果项目内使用了Enlighten Baked GI,而引擎已升级至2022.2 Unity版本,Lighting里的相关设定会自动切换到Progressive CPU烘焙(Apple silicon设备则是Progressive GPU)。用户可以在这里选择使用CPU或GPU Progressive Lightmapper。
从Enlighten Baked GI切换至Lightmapper之际,有部分用户肯定想继续使用Enlighten Baked GI。如果用户需要用Enlighten Baked GI过渡,可以打开Edit > Project Settings > Graphics,勾选并重新启用Enlighten Baked GI。但该设定将在2023.1版本删除。
希望大家能成功适应新的Lightmapper。如遇到任何问题,请到Global Illumination论坛留言反馈,或用Unity QA - Bug上报。
随着2022.2的发布,我们继续为Adaptive Probe Volume开发预览功能,首先开始实现光泄露防护/漏光保护功能。
光泄露防护/漏光保护是启用探针光静态几何形(probe-lit static geometry)的一次进步。在特定情况下,光照探针现在能够替换静态对象的部分光照贴图。
此外,我们现在还支持GPU内存流式传输,在光照探针数据并不完全兼容GPU内存的情况下构建并运行场景。
最后,我们还提供有烘焙多个受探针光场景的预览功能,让用户能在制作和运行期间编辑、烘焙并融合多个场景的光照数据。
该功能可做出无噪点的路径追踪图像,应对原先不可能,或需要大量时间积累/合并未过滤样本的情形。注意该功能与离线及非互动渲染降噪相关,所以不支持游戏内的实时路径追踪。
在2022.2中,Lightmapper的Optix降噪器升级到了第7版,降噪将借助平铺法来减少内存消耗。现在,高分辨率的光照贴图在烘焙和降噪时不太可能会耗尽所有内存。
随2022.2的发布,我们将内部的图像降噪功能打包成了一个软件包,以C#公共API访问。用户可以根据目标平台和硬件的处理能力,用API调取不同的降噪后端,例如Optix或OIDN。
我们在错误报告里看到有部分用户在使用Light Probe时,遇到编辑器运行模式下加载和卸载部分场景情况下的崩溃现象。这些崩溃背后有许多根本原因,而最常见的一个就是引擎不清楚当前场景的光照探针组是否做好了渲染准备。于是,光照探针组的状态就可能被损坏。
在2022.2中,改进后的代码现在能清楚定义一组光照探针何时做好了渲染准备,修复了已知的可能导致崩溃的光照探针组状态被损坏情况。
此前,当受探针光对象被移出四面体外壳,会需要搜索整个光照探针的四面体外壳并找到最近的光照探针,耗费大量时间。壳外对象越多,外壳越复杂,这一搜索过程的消耗也就越多(呈线性增长),从而对大型项目产生巨大影响。
为了改进新项目里的默认行为(且能在旧版项目里选用此新功能),Graphics设置中将包含一个新属性用于设定放置在壳外的探针光照对象的采样行为。如此一来,引擎可以用氛围探针替代整个外壳,在一条更快的路径上完成壳外对象的检索。
我们团队最近修复了一个问题:构建好的应用在特定情况下(如场景未经烘焙时)会丢失环境光照。
为了解决新项目加载OpenCL着色器过慢的问题,我们在GICache缓存了二进制文件,加快了OpenCL着色器的加载,防止了此类倒退。在测试中,当 OpenCL 着色器从 GICache 读取时,我们在 GPU 光照贴图方面看到了一定的性能改进(如下图所示)。
不过,编辑器在首次启动时需要建立这些缓存,因此第一次启动的速度并不会变。
在2022.2 中,全局光照还迎来了几处用户体验的小改进:
用户可以在这块Productboard(产品陈列板)了解全局光照的最新路线图。以下是路线图上的一些亮点。
至2023.1,Adaptive Probe Volumes的核心功能和用户体验会得到进一步改进,并最终达到移除“experimental(实验版)/preview(预览版)”标签的目标。我们还在添加通用渲染管线(URP)对该功能的支持。注意第一版功能不会支持Lighting Scenario Blending(光照场景混合),也不保证有性能优化,尤其是在低端平台上。
我们提供了一种实时全局光照解决方案Precomputed Realtime Global Illumination(预计算实时全局光照),相比于Ray Traced Global Illumination(光线追踪全局光照,RTGI)或Screen Space Global Illumination(屏幕空间全局光照,SSGI),该解决方案可在更多平台上扩展。它所采用的预烘焙光照探针数据会在运行时动态地更新探针光照对象的间接光照,让用户能用墙壁、天花板、地形等静态对象传来的动态光照制作、构建和运行实时GI。
为了快速预览烘焙出的光线,我们为烘焙光照数据提供了一条专门的预览路径以加快迭代。我们使用“反向”路径追踪(光线路径从摄像机出发)来计算可见部分的光照,让用户能立即预览场景光照。该功能可以利用硬件加速光追(若设备支持),也可以通过一种备用计算着色器,支持在非硬件光追GPU上工作。
随着GPU Lightmapper的基础性工作继续推进,我们将为更多开发者带来更稳定、可预测的光照烘焙,提高使用效率。
我们希望将这些公共API做成强大、无副作用且受支持的C# API。用户可以用它来定义影响GI烘焙的输入(比如Mesh、Transform、 Material、Light等等), 以及所生成的输出,比如光照贴图和探针及其单独组件,如辐照度(irradiance)、方向性(directionality)、 遮挡(occlusion)和 八面体深 度(octahedral depth)等。
请在Global Illumination 2021更新的论坛贴详细了解Enlighten Realtime GI的弃用路线。
Is this article helpful for you?
Thank you for your feedback!