用Blender的实时引擎提速日常3D视觉设计——EEVEE in Action

韩国/设计爱好者/4年前/940浏览

版权

面对轻量化的3D视觉设计需求，光追式引擎并不总是最优选择，使用Blender搭载实时引擎EEVEE的方案可以提高输出效率，优化体验。

我记得大概从2014年开始，在Behance、Dribbble等视觉设计网站上，不少前卫的设计师们开始拿起一款叫做Cinema 4D（C4D）的软件做起了3D，以低多边形（Low Poly）风格为主的3D作品迅速占领了各站首页，3D风格体感明显地火了起来。大概也是从那时开始，C4D成了很多非CG行业设计师们的标配。现如今，行业内大部分团队和个人都会使用C4D+第三方光线追踪引擎（Octane, Arnold, Red Shift等）的组合输出3D需求。在Trovo项目的设计中，我们除了这种组合外，还会使用Blender+光栅式实时引擎（EEVEE）的方式输出3D需求，我认为这个组合对于轻3D任务居多视觉设计团队来说，可以很大程度地提高输出效率。这里简单介绍一下这个组合给我们Trovo的设计产出带来的一些变化，希望对存在类似需求的朋友有所帮助。

Trovo是什么？轻3D任务又指什么？

我们负责设计的项目叫做Trovo，它是一个主要面向美洲和欧洲用户的游戏直播平台。3D化视觉输出物在Trovo的应用还是很广泛的，主要应用于直播间礼物和特效、运营活动的主视觉、特定时间节点的宣传视频、社交媒体的传播物料，以及吉祥物和周边商品的设计制作中。

前面提到了一个词叫做“轻3D任务”，与之相对的是“重3D任务”，这是我自己总结的两个概念，主要是为了接下来方便解释实时引擎的使用场景。轻3D任务主要指不以追求照片级真实度（photorealistic）的渲染结果为目的的3D视觉设计任务。比如说下图中这些目前我们在网上很常见的图片或动画，它们经常被用于互联网产品的图标、海报、宣传片等地方。轻3D任务多以风格化（stylized）的形式出现，抽象和萌系居多，视觉上的兴奋点更多地来自鲜艳的颜色、饱满的造型，或者大脑洞的设计点子等，而不是来自逼真的光影和细节丰富的材质。轻3D任务的制作一般不用走特别完整3D流程管线（Pipeline），用一两个软件就可以完成。

相对地，我把重3D任务归类为追求照片级真实光影的，高精度的渲染结果为目的的3D设计任务。大部分3A级的游戏项目，影视级动画和特效，商品的可视化展示等都可以归于此类。重3D任务的完成一般需要经历相对完整的流程管线，对管线中各步骤的精度、细节和专业度的要求也更高，通常要达到最好的效果，要用到的工具软件也更多。

根据这个分类不难看出，我们在Trovo的日常3D输出需求绝大部分属于轻3D任务这个范畴，非CG业务团队的大多数3D视觉产出也属于这个范畴。由此就产生了一个值得探讨的问题。

问题点

把3D任务成这么两类后，我注意到一个问题：两种任务有着不同的渲染输出目标，它们在对待精细度和真实度的优先级也是截然不同的。但目前在面对轻3D任务时，我们却一直在用处理重3D任务的方式和工具渲染输出结果。即，我们总在用耗费算力和时间的光线追踪式引擎（Ray Tracing Renderer）去渲染输出一些对精细度和真实度要求没那么高的需求。这导致的结果就是作业时间的加长，成本的上升。这就好比我们一直在用锋利精密的小手术刀去切肉，虽然也能切得开，但肯定不如专用的切肉刀来得干脆利落。

对策

为了解决这个问题，我尝试的做法是引入Blender，使用它搭载的实时引擎“EEVEE”来处理适合的轻3D任务。

Blender是一款是用来制作和处理3D图像的工具软件，它内置的工具和模块基本完整地覆盖了3D制图的全流程管线，在3D界是像瑞士军刀一样的存在，而且这把刀还是免费的（开源）。但Blender和Maya、3DS Max、C4D等相比，它的知名度一直较低，在非CG行业的视觉设计师中尤是。我从2015年的C4D R17版本开始，断断续续用了4年左右的C4D，后尝试了Blender，两者相较体验后，我认为Blender在管线中大多数方面都要比目前行业里普遍使用的C4D实更适合轻3D任务。理由很多，这里着重介绍最大的理由之一即Blender内置的实时引擎EEVEE。

EEVEE这个名字可能会让人联想起《神奇宝贝》里的同名宝贝伊布，但其实它的全称是Extra Easy Virtual Environment Engine，从名字里也可以看出这款引擎特别强调易用性。它是一款基于传统的光栅绘图算法（后文有简易的原理介绍），并结合了很多黑科技于2019年Blender 2.8版本开始正式搭载在软件上的一款实时引擎（Real Time Renderer）。“实时”意味着EEVEE可以在视窗（Viewport）中实现渲染结果的所见即所得，而不用像光线追踪式引擎一样，哪怕做再小的一个改动都必须等待小方块（tile）逐渐填满整个充满噪点的视窗。EEVEE不仅有着超快的渲染速度，设置得当的话，我们甚至能得到接近照片级真实度的渲染结果。

下面结合在Trovo日常输出中的一些小例子和大家分享下EEVEE究竟是如何提高输出效率和整体作业体验的，以及我们用它能预期得到什么样的结果。

1. 在视窗中实时查看渲染结果。EEVEE可以帮助我们直接在视窗中看到几乎没有噪点的渲染结果（高度接近最终输出的渲染结果），我们可以一边移动视角，一边从各种角度直接查看我们的材质、灯光甚至动画，并实时地做出调整。在如下图中这种不太复杂的场景中，动画在视窗中甚至可以达到满帧速播放。

2. 实时查看修改贴图。我们制作的贴图颜色是否正确，反光与凹凸程度如何，这些问题我们都可以直接在视窗中得到答案，并根据需要直接做出调整。

3. 实时查看并修改耗费算力的效果。我们知道计算机在处理渲染有些效果时会格外耗费时间，比如景深效果、透明材质、次表面散射（sub-surface scattering）、体积光（volumetric lighting）、烟雾和液体效果等。如果用光线追踪式引擎去获取这些效果，很多时候由于时间成本过高，我们不得不做出舍弃。但EEVEE大幅度降低了这些效果的实现成本，让我们可以更自由地发挥创意。

↑ 小黑猫与其背后月亮的景深关系伴随着视窗中焦点位置的移动同步反映在了视窗渲染结果中。

↑ 我们可以方便地在透明玻璃和毛玻璃间切换。

↑ 体积光（volumetric lighting）在营造氛围、创建宏大场景以及增加渲染真实度等方面作用巨大，但在光追引擎中实现的时间成本过高，在EEVEE中该效果的可用性（accessibility）大大提高了。

*Trovo的礼物制作中暂未用到该效果，故演示场景为个人项目。

↑ 次表面散射（sub-surface scattering）是光线穿过一些半透明物体时表现出的现象，最常见的就是逆光观察我们的皮肤时，特别是耳朵和手等比较薄的部分会被一部分光线穿过而呈现出明亮的红色。在Cycles等光追引擎中模拟这种效果通常也要花费比较长的时间，并且由于光追引擎噪点的问题使我们很难准确地判断最终效果。在实时的EEVEE中制作皮肤、果冻、奶酪等会产生类似效果的物体变得容易了不少。

4. 实时制作程序性材质（procedural material）。程序性材质是不依靠手绘或下载的贴图，而按我们预设的逻辑由软件演算后呈现出来的材质。视窗的实时预览特性让我们制作和调试程序性材质的时候变得特别方便，因为增删、调节节点（node）后的效果都可以第一时间展示在我们面前。如下图中类似《塞尔达》中的火焰效果都可以很便捷地在视窗中实时制作完成。

5. 和光线追踪引擎的互通性。Blender搭载的光追式引擎叫做Cycles，实时引擎EEVEE中的灯光和材质很大程度上可以不做任何调整地直接挪到Cycles中使用，我们需要做的只是按一下切换引擎的按钮。这也就意味着即使我们决定最终用光追引擎渲染输出，在制作过程中我们也可以不时地用EEVEE预览灯光和材质，大致判断当前设定在Cycles中的最终表现，极大地节约时间，优化制作体验。

在下图中可以看到，在没有使用EEVEE暂不支持的材质时，同一场景在EEVEE和Cycles的呈现效果是比较接近的，这就给我们更快地预判Cycles的最终效果提供了巨大的便利。

直播间礼物输出案例

以下是我用EEVEE制作的一部分Trovo的直播间礼物。以第一个Mana Bomb为例，按照1000 x 1000像素的分辨率，这样一个3秒（72帧）的礼物的渲染时间大概需要2.6分钟；如果用Cycles引擎渲染则需要约13.2分钟，耗时是EEVEE的5倍。另外需要补充说明的是，这些礼物大部分是用一台2013款的只有核心显卡的iMac制作的，在更高配置的设备下这个时间还会大幅缩短。多出来的时间当然就可以用来尝试更多的点子或者早点下班了。

短视频输出案例

今年5月，Trovo迎来了一岁生日。我们需要制作一个时长1分钟左右的短视频来作为云直播的串场。这个任务的最大难度主要来自于时间上的压力，因为当时组里可以分配到这个任务上人力只有我一个，从想点子到渲染输出有三周时间。

制作动画的时间成本是比较高的，面对这种挑战，我想了几个办法来尽量压缩时间，希望尽可能地减少浪费在反复渲染上的时间，把更多时间留给想点子和做修改。这种情况下，用实时引擎势在必行。

当时我用装有GTX1650显卡的ThinkPad X1笔记本来渲染输出这段动画，平均每帧需要3秒左右，这样算下来长度1分钟的视频完整渲染一遍需要1.2小时。如果用Cycles每帧则需要约100秒，渲染完成整个视频需要44小时，即使我牺牲质量降低一半的样本数量也需要20个小时，对于当时捉襟见肘的排期来说肯定是不能接受的。同时期我们组的另一段周年宣传视频，排期时间相对充足，用的则是C4D+Arnold/Octane的组合，输出每帧平均时间大概在10分钟左右，同时使用了4台电脑。这样两相比较后可见光线追踪引擎渲染动画的成本之高。

当然了，不设前提地去单纯比较实时引擎和光追引擎的速度是不公平且没有意义的，这个必要的前提就是要看我们的渲染输出究竟需要怎样一种精度和真实度。就拿Trovo周年庆的两段视频来说，我们的这两段视频风格都是偏卡通和风格化的，它们从一开始就不是为了追求超真实的光影。在这个前提下，从实际的渲染结果中也看得出来，光追引擎（Cycles/Arnold/Octane）在光影真实度方面的优势在这个案例中并没有明显体现出来。在上图中，我在两段视频中选择了复杂度差不多的两个画面各渲染了一帧，可以看到速度差距非常明显，然而两者的画面光影精细度却几乎看不出来。在这种情况下，如果渲染输出用时更少，那么这种速度比较对我们来说意义就很大了。这也是为什么从一开始我要把3D任务分为轻重两类的原因。

↑ EEVEE渲染的动画（无AE后期）

何时该用实时引擎？

那是否就该轻3D任务用实时引擎输出，重3D任务就用光线追踪引擎输出呢？我觉得要回答这个问题得简单了解下两种引擎工作方式的区别，这样可以更好地理解它们各自的长处和短板，方便我们决定如何选择。

光线追踪和实时渲染是两种计算机绘制3D图形的算法，光线追踪这种渲染算法的出现要晚于实时渲染算法。现实世界中我们所处环境中的光源发射出光线照射的物体表面，经过反射和折射一部分光线进入我们的眼睛，我们就看到了这个物体，这个过程叫做正向光线追踪（forward ray tracing）。光线追踪渲染算法模拟自然界的这个过程，但是光线不是从太阳这样的光源，而是从我们的眼睛（即3D场景中我们布置的相机）中发射出去，一部分光线经过反射或折射会击中场景中我们布置的光源上，这部分光线就被计算机记录了下来，形成了我们看到的渲染的图像。这个过程叫做反向光线追踪（backward ray tracing）。

渲染器之所以不完全模拟正向光线追踪是因为现实世界里光源可以发射出来的光线数量近乎无限，其中的绝大部分不会进入我们的眼睛或相机，如果这样模拟电脑的计算量会大到算不出来；反向追踪可以控制发射的光线数量，让计算变为可能，但也可以想见，如果想要获得接近真实的光影，我们就需要让相机发射出很多光线（提高渲染样本数量），这样计算量也是非常大的，这也是为什么光线追踪式引擎可以准确地模拟出现实世界的光影却比较耗费时间的原因。

↑ 我简易地模拟了一下我们按下“渲染”按钮后发生的事情。彩色的小点是从我们设定好的机位发射出去“追踪”场景中物体的光线，一部分击中物体的光线被反射到我们摆好的光源中，追踪到了光源，这部分光线的信息就被记录了下来，形成了相机对应像素中的图像。

实时引擎算法的核心叫做rasterization，即光栅化。我们创建好的3D场景中的物体的信息会由后至前地被投射到我们设定好的相机位置上，每个像素是否有对应的物体信息被记录在成像器上，材质和色彩信息是由光源与物体每个表面的距离和角度演算出来的，投影则是由光源发射光线到物体表面，在光源角度被遮挡看不到的位置生成图片的形式演算出来的。在相机成像栅格上记录下的像素信息经过后期处理就形成了我们看到的图像。

↑ 所有的物体都会沿着相机的视角（perspective）被压平，在相机平面对应的位置形成图像。

这种算法的好处就是非常的快，因为它并不像光线追踪一样靠模拟光线的真实成像原理，但同时也正因如此它渲染出来的图像的物理准确度会比较低，投影、反射、折射、全局光等这些影响我们判断事物是否看起来真实的效果都要依靠后期演算来复刻（fake）出来。EEVEE的黑科技其实就是这些足以以假乱真的复刻效果。

所以实际选择两种引擎的关键就是平衡渲染时间和渲染精度。结合我在工作和个人项目中遇到的不同需求，我想到了两者各自适合的一些场景：

当然就如前面提到的，由于实时的EEVEE和光追的Cycles有很好的互通性，两者混用也有很好的应用场景，即，使用EEVEE快速预览并调节材质和灯光，最终应用精度更高的Cycles输出结果。

同时需要指出的是实时引擎如EEVEE也并非不能实现照片级的真实度，如果模型、材质、灯光等这些元素的精细度都足够高，我们一样能得到令人惊艳的照片级真实度。同样的，光线追踪类的引擎当然也可以用来制作风格化的项目，光追引擎带来的光影方面的提升能一定程度上模糊风格化和照片级真实的界线，给人一种别样的视觉兴奋点。