批量 材质 调整_寒霜引擎的PBR实践3.0（一）材质篇

随着对游戏美术品质要求的提高，对整个开发从流程pipeline到从业人员的素质要求都开始增加。传统的美术工作流因为依赖个人的经验和感觉，所以在制作大体量项目的过程中很难达到理想效果。而这时，由项目组内的Technical Artist和Graphic Programmer来搭建起一套基于物理渲染的管线是非常有必要的。

Physical Based Rendering（PBR）基于物理的渲染，已经不是什么新鲜的渲染技术了。如今的美术从业者也很少会再从原先的手绘流程开始学起，都是清一色的PBR资产创建流程。虽然借助成熟的pipeline工具链已经能够批量生产美术资源，但如何在游戏引擎中正确设置这些资源则是一个大课题，这直接影响到游戏最后呈现出的美术品质。

引擎中往往是需要我们定制更多参数的，只有对Lighting的设置才能来保证这些美术资产能正确接收光照和环境光，从而保证高效的产出效率和相对便捷的pipeline。虽然Physical Based Rendering很早就在行业内开始普及，但仍然有一些制作组的美术/技术人员由于对这一套渲染流程的细节不够重视，认为有一些色感和审美之后自己就是合格的美术，过于依赖眼睛所看到的信息，在PBR的流程中还是按照自己的经验来根据主观判断调整材质中的specular、shadow、diffuse颜色， 最终得到错误的结果。例如在修改物体阴影时不调整Ambient Light而是直接在shader中强行改阴影颜色等操作。

整篇论文结构划分为构成PBR场景的三个要素，材质（Material），光照（Lighting），相机（Camera），本文作为整篇文章的开头，涉及了材质方面的所有内容。作者为Sebastian Lagarde。我们熟悉的Unity HDRP就是Sebastian在巴黎办公室带领团队编写的。作为Graphic界的扛把子，他本人在14年SIGGRAPH发布的这一篇论文就非常有说服力。借此机会，想把这一篇精彩的文章分享给各位。

本文可能也有很多没有理解到位的地方，会在之后不断更新修正，欢迎各位大佬一起交流学习。

Moving Frostbite to PBR - Frostbite​www.ea.com

Introduction

经过前几个月的回顾与反思，我们开始重新评估整个寒霜（Frostbite）^[1]呈现出来的图像质量。我们最终的目标是让它看上去更有电影的质感，所以我们需要让整套流程都基于物理进行渲染（PBR）来达到预期的效果。我们根据行业内现有的一些成功案例来改进寒霜的美术表现，例如《杀戮地带（暗影坠落）》[Dro13]by Decima Engine，虚幻4引擎[Kar13]by Unreal4，Remember Me [LH13]by Unreal 3和《合金装备（Ground Zero）》[Koj+13]by Fox Engine… 在这基础之上，我们需要重新对已有的技术进行定义并解决当下这个领域中已经遇到的许多问题。

在R&D的过程中，我们使用了“经验证据（Ground Truth）”作为参考——去进行测量/渲染后得到的近似值——去评估我们得出结论的准确性。在当时要在引擎内完全实现渲染的物理准确是非常困难的，不像如今的引擎内可以实时对性能进行约束。然而在某些情况下使用近似值也成为了可能，在这样的限制下，我们会更倾向于使用看上去更正确的参数，而不是按照完全物理准确的标准来提升我们的渲染质量。

PBR已经成为了当前游戏行业中常见的术语，但实际上各个游戏引擎对它的定义都有很大区别。对于寒霜来说，一个最核心的PBR原则去确保场景内所有物体在视觉上的美观准确是尽可能的对引擎内的材质（Material）和光照（Lighting）信息进行解耦合（Decouple）。基于这个方法，场景内的物体和各层材质就可以接收到同样准确的光照信息，避免了一系列人为错误，如负值的光照强度或是计算两次光照等。从产品的角度上来讲，这也促进了在不同环境下美术资产和光照组建的复用性。同时，这也可以减少我们的对美术人员开放的参数，让面板看上去更清晰，提高易用性。然而这样完全分离的做法实际上是不现实的，因为会出于性能的考虑，材质和光照的代码耦合性很强，你会在之后的文章中看到更细致的解释。

我们在拥抱PBR时很明确的一点是整个图形的工作流（渲染器和制作工具）都需要进行对应的更新。有了这样一个认知我们在制作这个课程时的目标就需要针对大体量的游戏引擎覆盖到所有不同工具和流程的更新细则。包括对以往文献中遗漏的细节进行补充。首先在第二章节会解释经验证据（Ground Truth）的参考对PBR环境的重要性。第三章则对材质部分有一个更详细的介绍：光是如何与不同材质的物体进行交互的。接下来第四章会讲到光是怎么定义和发散（Emit）的。第五章关注在相机和最后输出的图像质量效果上，涉及到光照结果会经过怎么样的步骤输出到最后的像素中。最终我们在第六章对前面进行总结，回顾寒霜转换到PBR的开发流程，以及我们在这个过程中的一些思考和想法。

在继续之前，我需要先声明的是，这篇论文是许多处在游戏行业的人智慧的结晶。它收集了很多被广大群众分享到社区内的信息。他们应当被Credit为这篇文章的作者之一（具体名字见文章末的Acknowledge一栏）

文章中会用到的一些数学符号及其含义

2. Reference

2.1 Validating Models and hypothesis 验证已有的光照模型和一些设想

游戏行业在近十年都在往渲染更真实（Photorealistic）的画面上努力。但真实感（Photorealism）是一个很模糊的概念，我们无法用一个既定的方法来达到这样的意向，因为每个人对真实的解读都是不同的。不同于基于物理渲染（PBR）用模拟经验证据（Ground Truth）的行为和参数，它得到的结果可以用定量分析来判断。这就对我们的经验证据（Ground Truth）数据有了新的要求。在研究过程中，选择正确的假设和模型也是非常重要的，仔细观察并对比真实世界的现象是一个辅助我们判断这个技术/方法是否适用的好办法。在项目初期阶段可以用这样的方式更快速的抓住要点，比如物体在潮湿情况下的表面效果，在不同光照环境下的表现和其他在视觉上的区别等等，见图一。当把真实世界的物体作为材质参考时，我们需要在不同的光照设置下拍摄来获得更有效的参考。

图一：真实世界（左）和引擎（右）内的灯光效果对比

然而拍摄这样准确的数值是非常耗时的。一些已有的数据库如MERL【MER】使得我们可以直接获取到这些光照信息。在我们的工作中，我们会经常从这样的数据库中获取并验证数据，如光照强度、光照衰减，天空亮度和相机效果等。即使我们是去找现成的数据这样的工作仍然是十分耗时的。

2.2 Validating in-engine approximations 验证引擎内的近似值

目前的PBR光线追踪器（Path Tracer）像是Mitsuba[Jak10]可以渲染出最真实的图像效果。使用这样的软件^[2]是一个非常简单的方式来替代之前所说的各种测量需求。在寒霜中我们编写了一个到Mitsuba的导出工具，用来快速验证对真实材质的模拟是否达到标准。这个导出工具允许我们将引擎内的模型、材质（不包括贴图）、光照设置信息一并导出。有了这样的流程，我们就可以检查材质所使用的光照模型，积分计算（Light Integration）和光照强度和真实材质的出入。实际上我们还可以通过这个流程来检查全局光照（Global Illumination）、环境光遮蔽（Ambient Occlusion）和反射信息（Reflection）。图二显示了在执行导出后引擎会自动生成一个对比引擎内实时渲染和离线光线追踪后的效果对比。在菜单栏你还可以对曝光度进行设置，这一点非常重要，因为在渲染器中最终输出的结果是输出成一张处于线性空间的Open EXR格式 HDR图像。

图二：我们编写的用于对比引擎内实时渲染和离线光追的结果，用于检查材质的准确性

2.3 Validating in-engine reference mode 验证引擎内的参考模式

在上一小节中我们提到了用于验证准确性的导出工具，但在导出后需要渲染场景的时间在几秒到几分钟不等。为了快速在不同的材质效果进行迭代测试，我们在引擎内加入了用于GPU光照计算的内部参考模式（如IBL和区域光），见图三。虽然渲染时间仍然偏长，但在大部分情况下都比之前的导出工具流程快。附录A中会包含我们所测试的所有光照模型数据。

图三：左：（引擎内）由几盏不同类型的区域光渲染的场景。 中：（引擎内参考）同样的场景设置，但使用GPU的重要排序进行渲染。 右：（离