目前 Unity 提供了多种渲染管道,两种全局照明系统,四种照明模式,三种灯光模式,以及两种 Shadowmask 模式,为开发者在创建面向高配PC、主机、移动和XR设备项目的过程中提供了高度灵活性。但是,作为 Unity 新手,如果不熟悉渲染的话,面对这些选择不免感到茫然,本文来自 Unity Spotlight Team 的分享,XR技术研习社对此进行了编译。
首先看几个重要的图形渲染概念的定义。
以下流程图从内容创作者的角度展示了在Unity中设置照明的过程。
在整个流程中,首先需要选择渲染管线,然后决定如何生成间接照明并选择相应的全局照明系统。在确保所有全局照明设置都对项目进行了相应调整后,可以继续在场景中添加灯光、自发光表面、反射探头,光照探头以及Light Probe Proxy Volumes (LPPVs)。详细介绍所有这些照明对象的用法和功能超出了本文的讨论范围,因此建议读者阅读Unity手册中关于光照部分的相关介绍,以了解如何在项目中正确使用它们。
在 Unity 2018 之前,只有一种渲染管线,现在称之为“内置渲染管线(Built-In Render Pipeline)”,该管线提供前向(forward)和延迟(deferred)两种渲染模式供用户选择。
在2018年1月,Unity 推出了 Scriptable Render Pipeline(SRP),允许开发者通过C#脚本自定义渲染流程。这实际上是游戏引擎领域的一次变革——用户能够自由控制对象的剔除、绘制和后处理,而无需使用像C ++这样的底层编程语言。
Unity提供了两种SRP,目前为预览版,其设计充分考虑了硬件规格及性能:
高清渲染管线(以下简称 HDRP)是一个综合了Deferred/Forward、Tile/Cluster 渲染方式的渲染器,提供高级渲染和着色功能,适用于需要展示高品质视觉效果的PC和主机项目。Tile渲染和Cluster渲染如下图所示:
其中,一个 Tile 代表帧中一小块二维正方形区域中的像素,一个 Cluster 代表摄像机两个截平面之间的三维空间。Tile 和 Cluster 渲染技术均依赖于影响每个Tile或Cluster的灯光,然后在一个通道中中根据与其相关灯光来计算照明。不透明对象最有可能使用Tile系统进行着色,而透明对象则依靠Cluster系统。与内置渲染管道(延迟模式)相比,HDRP 的主要优势是更快的照明处理和更低的带宽使用。
通过使用以下决策树,读者可以使用几个关键条件判断决定使用何种渲染管线。
可以通过 Unity 的 Package Manager (Window > Package Manager) 下载最新版本的 HDRP 和 LWRP应用到项目中。在项目中应用某个 SRP 比较快捷的方式是,在使用Unity Hub创建一个新项目时,选择相应的模板(Template),如下图所示。
如果要手动设置HDRP或LWRP项目,请确保已安装所需的 package。以使用HDRP为例,可通过 Create > Rendering > High Definition Render Pipeline Asset 命令在 Project 面板中新建对应的资源,然后将此资源拖到 Graphics Settings 面板的 Scriptable Render Pipeline Settings 属性中,如果此处不指定任何资源,Unity 将默认使用内置渲染管线。如果使用 HDRP,需要确保在 Player Settings 中选择了线性(linear)色彩空间,并使用 Rendering > Scene Settings 命令在场景中添加一个场景设置游戏对象。
对于理解渲染技术并熟悉C#的开发者,如果需要为项目完全定制渲染器,建议尝试使用SRP的相关概念创建自己的渲染管线。鉴于LWRP拥有较小的着色器库且易于注入、移除、切换渲染通道,使得LWRP具有极强的可扩展性。
在Unity中将项目中的材质从内置渲染管线切换到HDRP或LWRP比较容易,使用 Edit > Render Pipeline > Upgrade xxx 相关命令即可完成,如下图所示。需要注意的是,此操作不可逆,建议事先做好项目备份。
尽管如此,自定义着色器需要进行手动移植,此过程相对比较耗时,具体取决于自定义着色器的数量。由于LWRP 和 HDRP 在物理表现上比内置渲染管道更加准确,尤其是在光衰减和分布方面,所以切换前后的项目看上去会有一些不同。此外,HDRP和LWRP之间互不兼容,因为它们没有相同的渲染特性,两者可以相互转换,但不是一键操作,需要手动重新设置照明、材质和着色器。
最后需要说明的是,HDRP和LWRP目前仍处于预览中,并非所有功能都已针对两种管线实现。比如,某些照明模式尚未完全适用于LWRP,并且HDRP目前尚不支持VR/AR,但是在未来版本中将逐步实现。
Unity 提供两种全局照明系统,可在 Window > Rendering > Lighting Settings 中启用它们。
Progressive Lightmapper 优先计算对于摄像机可见物体的照明,并大大提高的照明计算速度,但代价是增加整个场景的总体烘焙时间。 该技术使用CPU通过路径追踪算法计算间接照明。基于GPU加速的 Progressive Lightmapper 能够大幅缩短场景的烘焙时间,目前正在处在研发中,在 Unity 2018.3.05b 中集成了该技术测试版。由于Enlighten 和Progressive Lightmapper 使用了不同的技术计算光照,所以两者产生的光照效果会有不同。
下图列出了各全局光照系统的主要优缺点,可根据决策树选择项目需要使用的全局光照系统。
无论您使用哪种全局照明系统,Unity 都只会考虑标记为“Lightmap Static”的游戏对象。动态游戏对象需要借助场景中放置的光照探头来接收间接照明。
由于全局光照计算是一个相对缓慢的过程,因此只有具有明显光照变化的大型复杂资源才需要应标记为“Lightmap Static”。接收均匀光照的较小网格可保持为动态设置,然后通过使用 Light Probes 为其提供近似效果的间接照明效果。较大的动态游戏对象可以使用 Light Probe Proxy Volume(LPPV),以便在局部接收更好的间接照明。限制场景中静态游戏对象的数量对于提高烘焙时间同时保持足够照明品质至关重要。
在Unity中可以同时使用烘焙和实时GI技术,但是,必须注意,同时使用会大大增加烘焙时间和程序运行时的内存消耗,因为这两个系统不使用相同的数据。此外,间接照明在运行时的交互式更新将给CPU带来额外的压力,并且在视觉上,烘焙和实时GI提供的间接照明效果会有差异,因为它们使用了不同的技术来模拟间接照明,并且通常在完全不同的分辨率下执行。若同时使用这两种技术,建议将使用范围限制在高端平台或具有可预测性能成本且严格把控场景的项目中,同时,建议由对所有照明设置有很好理解的团队成员负责,因为管理这两个系统相对复杂。
因此,对于大多数项目而言,尽量避免同时使用两种GI技术,选择其一是相对比较稳妥的做法。