介紹

在大約四個月的時間裡（2021 年11 月至2022 年2 月），我們與Pablico Fournier 和Hjalti Hjalmarsson 一起，在Andy Goralczyk 的監督和Francesco Siddi 的幫助下，為Snow 角色製作了一個簡短的宣傳動畫。 （操縱：Demeter Dzadik，管道支援：Paul Golter，附加建模：Julien Kaspar，FX 和幾何節點：Simon Thommes，佈局/動畫回饋：Rik Schutte）

這個想法是將斯諾置於一個反烏托邦的阿茲特克風格的大城市中，躲避兩架無人機。在被第三架無人機困住後，他使用了自己的秘密力量，動畫結束。

早期的黏土渲染

我們想要創建一個簡短的動畫來在生產環境中測試 Eevee。使用 Eevee 與 Cycles 相比有何優點和障礙？渲染時間是多少？哪些因素會增加渲染時間？這些是我們想要找出的一些事情。

請記住，此處提到的某些方面將因 Eevee 重寫 而改變。

快速瀏覽鏡頭 0040

管道和性能上下文

紋理 (Krita) 和著色器被設計為以半程序方式重複使用。紋理的「熱點」技術用於指定物件的面（基於比例和比例）。使用頂點繪製創建各種效果，如水坑、污垢和鐵鏽，使它們看起來更清晰但更流線型。

熱點色彩紋理

Krita 中的紋理範例

場景的建構就像您在 Cycles 中渲染它一樣。這意味著不會像現代遊戲中那樣對模型進行最佳化。此作品中沒有 LOD、烘焙法線貼圖或重新拓樸。意識到這一點，添加細分曲面或斜角等修改器僅限於更重要的物件。抽取用於優化場景幾何形狀，有些是破壞性的，有些是非破壞性的。

透過在設定檔中添加燈光，簡化了製作結構。這會帶來更高的一致性，但性能不太友好。 lighting.blend 包含無人機聚光燈、佈景照明和雪景照明裝置。這是一個空物體，約束在有主光、補光、邊緣和其他燈光的裝備上。

快速統計

博的機器：

• 作業系統：Pop!_OS 21.10
• CPU：Intel Xeon(R) CPU E5-2697 v3 @ 2.60GHz × 56 執行緒
• GPU：NVIDIA Corporation GA102 GeForce RTX 3080 10GB 記憶體
• RAM：4 x 16 微米 64GB DDR4-2133 MT/s
• 儲存：ATA 三星 SS 860 512GB

保羅的機器：

• 作業系統：Pop!_OS 21.10
• CPU：AMD Ryzen 7 3800X 8 核心處理器（16 執行緒）最大速度：4550 MHz
• GPU：AMD RX 590 16GB 記憶體
• 記憶體：4 x 8 32GB DDR4-3200 MT/s
• 儲存：三星 SSD 970 EVO 1TB

卡通：

• 鏡頭 = 13
• 解析度 = 1920 x 1080
• 幀率 = 24
• 每幀平均渲染時間 = 3 分鐘
• 紋理包括雪 = 141

---

經驗

Eevee 和 Cycles 在渲染動畫時各有優缺點。 Eevee 可能具有渲染速度更快、影像清晰度更好的潛力；然而，在合成階段，通道缺乏基於樣本的「組合」通道的細化。具體來說，景深和運動模糊將恢復為較低的保真度版本，並且任何具有 Alpha Blend 的材質都將從圖像中丟失。

這最終導致重建影像雜訊更大且不完整，從而導致合成效率降低。這就是為什麼在創建最終渲染之前進行了大量較小的調整和迭代的原因。

當使用所有通道重建組合結果時，目前的合成受到限制

當渲染 (F12) 時，CPU 用於物件評估，此過程位於單一執行緒上。在花時間記錄效能之後，我們更明顯地發現，無論 GPU 功率如何，單執行緒效能在決定渲染時間方面發揮更大的作用。這是上下文相關的，主要適用於雪和具有細分錶面修改器的無人機（下載生產文件時，限制渲染時間的一個好方法是啟用簡化）。

如下圖所示，Paul 的機器具有更快的單線程效能（請參閱上面「快速統計」下的 Paul 機器）。雖然我的機器有更好的 GPU，但伺服器處理器的單執行緒效能要低得多。這可以在 GPU 相同但 CPU 不同的情況下進行更多測試。

日誌概述

實用性

Eevee 需要編譯著色器才能載入到 GPU 上才能進行渲染。這在製作開始時可能需要一些時間，幸運的是，當幾乎所有著色器都已編寫完畢時，這會更快。

在視窗中進行渲染以更改具有八個或更多樣本的照明會大大降低響應速度。這就是為什麼視口樣本設定為兩個，並縮小視口的原因。為了提高效能，我們使用「簡化」來縮短物件評估時間。

藝術性

Cycles 中的光線會影響各種通道（例如漫反射通道和光澤通道）的開啟和關閉。但 Eevee 中的燈光透過將「漫反射」、「光澤」和「體積」視為滑桿參數，可以進行更多控制。這是我在 Eevee 工作中最喜歡的方面之一，尤其是將數值提高到 1.0 以上以提高頻道的影響力。

為了避免無人機聚光燈的均勻性並賦予其更多變化 - 就像舊的手電筒 - 放置小型“著色投射器”物體來阻擋光線。有兩個聚光燈，一個用於照亮場景，另一個僅影響音量（見下圖）。

著色投射器靠近聚光燈的光源

不帶著色腳輪和著色腳輪的區別

紋理的創建方式可以以多種方式重複使用。透過複製現有材質並使用 ColorRamp 節點分配不同的顏色。或透過使用頂點混合或紋理來驅動獨特的變化。

創造變化的簡單而有效的方法

頂點繪製和使用修改器偏移來創建變化

在專案期間第一次使用資源瀏覽器來拖曳和分配材質是迭代和實驗的好方法。我建議使用資源瀏覽器來概覽您需要建立的材質。

---

建議

我的一般建議是像外部遊戲引擎一樣建立和創建場景。這是為了在 Eevee 中渲染動畫時優化模型並烘焙圖像紋理。

幾何學

• 強烈建議不要使用任何細分錶面改質劑。在 Eevee 中渲染時，模型始終是三角形數量的兩倍（三角測量且沒有細分錶面修改器）。例如，將等級設為 2，將使用基本三角形計數的 16 倍！
• 重新拓撲或簡化模型以降低場景幾何形狀。

著色

• 使用任何凹凸或位移節點進行著色都會降低效能，需要計算額外的兩個圖表。如果可能的話，烘焙到法線貼圖。
• 避免使用 Alpha Blend 渲染自身重疊的玻璃。使用帶有折射著色器的不透明材質進行近似。
• 目前的次表面散射 (SSS) 實施可能會導致口腔區域「出血」或「發光」。若要解決此問題，如果這些區域不太明顯，請刪除 SSS 值。

燈光

• 限制光線影響的距離，以防止對著色進行額外的計算（並具有更多的藝術機構）
• Eevee 中的燈光具有各種性能成本，特別是需要計算著色的幾何通道。每個燈使用的「投影」越多，效能成本也會增加。
  • 點光源需要 6 個投影，這使得它們的性能變得很重。
  • 區域光始終使用 5 個投影
  • 聚光燈只能使用 1 個投影，這是基於錐角的。如果角度 <90 度，它將使用 1 個投影（可能會導致輕微的不精確）。透過將角度增加到 >90 度，效能成本與區域光相當。
  • 陽光使用級聯著色貼圖，這與級聯數量和場景的複雜性有關。級聯著色始終更新。
• 如果您希望在照亮場景時獲得最佳效能，請使用角度低於 90 度的聚光燈，以節省著色的計算時間。
• 依照接觸著色將光線分成不同的集合。這樣可以更輕鬆地追蹤哪些燈具有更高的性能成本。
• “立方體大小”和“級聯大小”著色解析度幾乎始終為 1024 像素。原因是為了避免更長的渲染時間和明顯緩慢的視窗。如果場景非常詳細，請小心增加著色解析度。

渲染

• 重疊體積效應可以透過縮小圖塊尺寸和增加樣本來解決。
• 作品使用了一套文件，其中包括帶有烘焙探針的佈景照明。不可能在場景之間交換烘焙數據並更有效地重新使用它，我們必須為每個鏡頭重新烘焙照明。在不同檔案中渲染相同場景時請記住這一點。
• 啟用運動模糊但設定為零步將使用向量運動模糊，該模糊不那麼準確但渲染速度更快。
• 留意運動模糊步驟的數量，不要使用超出您所需的數量。

合成

• 如前所述，重建影像以匹配「組合」輸出是不可能的。唯一的解決方案是在渲染之前確保一切正確。
• Alpha Hashed 材質在通道中可見，但缺點是會產生額外的噪音。解決方案可能是增加渲染樣本，不幸的是，這將顯著增加渲染時間。

結論

在 Eevee 中創建雪地跑酷非常有趣，但也需要更周到的方法。例如：烘焙輻照度體積和立方體貼圖，決定哪些燈光使用接觸著色，避免凹凸或位移節點，以及螢幕空間效果帶來的限制。另一方面，Eevee 在使用燈光、出色的體積效果以及在沒有太多或任何噪音的情況下進行渲染時提供了巨大的創作自由。

正如「建議」中所提到的，在 Eevee 中進行渲染的最佳方法是盡可能有效地建立場景，例如將模型匯出到遊戲引擎。這包括優化模型並將所有通道烘焙到紋理檔案。並儘可能避免使用會增加物件評估時間的細分曲面修改器。

在談論著色器節點時，靈活性和效能之間存在著有趣的平衡。更大的靈活性（例如使用頂點繪製來混合紋理）需要 Eevee 額外的著色器圖形處理時間。雖然性能友好地使用烘焙紋理可能會使用更多的 vram，但在著色器圖中加載速度更快。這取決於項目的藝術方向和目標。

---

如果您想了解有關 Eevee 的更多信息，請查看文件

感謝克萊門特·福柯更深入的解釋