從 One Pass Deferred 到 Lumen 光追：《鳴潮》如何把 UE4.26 榨到極限？

如果只看《鳴潮》的 PC 版畫面，很容易猜它是一款典型 Unreal Engine 5 遊戲。

大面積動態光照、水面反射、日夜變化、動畫風角色與寫實環境混合，再加上後來加入的 Ray Tracing、DLSS Frame Generation，甚至 DLSS 4 Multi Frame Generation，整套功能看起來確實很像 UE5 世代產品。

但答案其實不是。

《鳴潮》的核心仍然建立在 Unreal Engine 4.26。

這也是它在技術上最有意思的地方。

庫洛在專案啟動時選擇 UE4.26，原因相當務實：當時這是一個成熟、穩定，而且已經經過大量商業專案驗證的版本。

問題是，一款 Live Service 開放世界遊戲的開發週期可能長達數年。

等到 UE5、Lumen、Nanite 與新一代 Ray Tracing 技術逐漸成熟時，《鳴潮》早已累積大量依賴 UE4 的資產、Shader、工具鏈與製作流程。

直接更換引擎版本並不像電腦更新 Windows 一樣按下一個 Upgrade 按鈕就結束。

大型遊戲專案裡可能存在數十萬甚至更多資產、Material、Blueprint、動畫、特效與客製化程式碼。一旦核心 Rendering Pipeline 改變，任何一個不起眼的 Shader 或工具都可能開始出現問題。

因此庫洛採取另一條路：

不把整個《鳴潮》搬到 UE5，而是把需要的技術搬回 UE4.26。

這讓《鳴潮》逐漸變成一套高度客製化的 Unreal Engine 分支。

為什麼《鳴潮》選 Deferred Rendering？

手機遊戲過去經常偏好 Forward Rendering，也就是物件在繪製時直接完成主要光照計算。

這種方式結構相對直觀，而且在簡單場景下效率很好。

但《鳴潮》面對的是一個持續增加內容的開放世界。

遊戲中存在大量 Material、不同天氣、昼夜變化、角色技能、植被、水面與各種特殊效果。

Forward Rendering 在這種環境下容易出現一個工程上的麻煩：Shader Variant Explosion。

想像一個 Shader 同時需要考慮：

有沒有陰影、有没有霧、有没有反射、是不是角色、是不是下雨、是不是夜晚、是否開啟某個特效。

不同開關組合會形成大量不同 Shader Variant。

功能越來越多，組合數量便可能快速膨脹。

Deferred Rendering 的做法則不同。

它先把場景的 Base Color、Normal、Roughness、Depth 等資訊寫入 G-Buffer，之後再統一進行 Lighting 與其他畫面處理。

這讓材質、光照與後處理更容易彼此分離，也更適合需要 SSR、GTAO、動態天氣與大量內容持續更新的遊戲。

庫洛因此沒有因為《鳴潮》需要跑手機，就放棄 Deferred Rendering。

相反地，它們選擇想辦法讓 Deferred 在手機 GPU 上跑得更便宜。

One Pass Deferred：手機真正昂貴的東西不只是算力

行動 GPU 有一個非常重要的限制：Memory Bandwidth。

GPU 做一次數學運算不一定很昂貴，但如果需要不停把大量資料從外部記憶體搬進來、再寫出去，功耗與熱量就會迅速提高。

桌機顯示卡可以使用數百 GB/s 的顯示記憶體頻寬，而且還有大型散熱器與風扇。

手機 SoC 沒有這種奢侈。

它必須和 CPU 共用有限的記憶體頻寬，最後還得塞進一台厚度不到一公分的裝置裡。

因此《鳴潮》在行動平台採用 One Pass Deferred。

核心概念是盡可能讓 Deferred Rendering 中間產生的資料留在 GPU 的 On-Chip Memory，而不是反覆寫入外部記憶體。

傳統流程可以粗略想像成：

Geometry → 寫入 G-Buffer → Memory → 重新讀取 → Lighting → 再寫回 Memory。

One Pass Deferred 則希望把更多步驟留在 Tile 或 On-Chip Cache 裡直接完成。

庫洛在 Epic Games 官方訪談中表示，這套方式能將相關讀寫頻寬控制到約每秒 1.5G 的程度，同時維持 60 FPS，進而減輕高頻寬造成的耗電與發熱問題。

這說明了一個很容易被忽略的 GPU Optimization 原則：

最佳化並不只是少算幾個 Polygon。

很多時候，更重要的是少搬幾次資料。

Mali GPU 甚至逼工程師重新思考 Pipeline

One Pass Deferred 並不是在所有 GPU 上都可以直接套用。

以部分 Mali GPU 為例，庫洛遇到了相當具體的限制。

使用 Pixel Local Storage，也就是 PLS，進行 One Pass Deferred 時，可用的 On-Chip Cache 只有 128-bit，而且存在 Alpha Blend、Render Target Resolve 與 Depth Fetch 等限制。

這代表某些原本很正常的渲染效果，一旦放到這個 Pipeline 裡，就可能破壞 One Pass Deferred 的優勢。

更麻煩的是《鳴潮》同時還有 Toon Rendering。

動畫風角色需要的 Shader 與一般 PBR Environment 並不完全相同。

因此庫洛並不是單純使用 Unreal Engine 預設 Renderer，而是逐步調整整套 Pipeline，讓 Deferred、Toon Shading、SSR、GTAO 與不同手機 GPU 的硬體限制可以共存。

這也是跨平台遊戲真正困難的地方。

PC 上能跑，和手機上能穩定跑 30 或 60 FPS，是完全不同的工程問題。

SSR 為什麼還需要上一幀？

《鳴潮》手機版另一項有意思的技術是 Screen Space Reflection，也就是 SSR。

SSR 的原理並不是真的從物件發出完整 Ray Tracing 光線，而是使用目前畫面已經存在的 Depth、Normal 與 Color 資訊，推算反射位置。

好處是便宜很多。

缺點則非常明顯：

畫面外的東西不存在於 Screen Space，所以 SSR 根本不知道那裡有什麼。

為了讓 SSR 與 One Pass Deferred 共存，《鳴潮》會利用上一幀的 Depth 與 Scene Color 產生反射資訊，再把結果 Reproject 到現在這一幀，最後進行 Denoising。

這裡又出現一個現代即時渲染非常重要的概念：Temporal Data。

現在很多遊戲並不是每一張畫面都從零開始計算。

上一幀其實是一座免費的小型資料庫。

如果攝影機與物件移動沒有太劇烈，就可以把上一幀算好的資訊搬到現在，減少重新計算的成本。

TAA、Temporal Upscaling、SSR、Denoising，甚至 Ray Tracing 都大量使用這個思想。

庫洛表示，大部分測試行動裝置可以在 Medium Quality 使用 SSR，並在 High Quality 使用 GTAO，而不造成嚴重性能下降。

角色為什麼在任何光線下都看起來像動畫人物？

《鳴潮》的另一個核心技術問題，是怎麼把 Anime Character 放進比較接近 PBR 的 3D 環境。

如果完全按照物理光照處理角色，結果不一定好看。

例如角色站在背光環境，真實世界裡臉可能自然變得非常暗。

但動畫角色最重要的資訊往往就在臉部。

眼睛、表情與輪廓如果被真實光照吃掉，角色辨識度就會大幅下降。

因此《鳴潮》建立了獨立的 Character Lighting Pipeline。

角色亮度會配合 Time of Day 使用 Curve 進行控制，而不是百分之百接受環境物理光照的結果。

另外還包含 Gradient Base Color、Mask Texture、Custom LUT、Fake Volume Fog、Post Material，以及特殊 Facial Shadow Texture。

換句話說，《鳴潮》追求的並不是 Physical Accuracy，而是 Perceptual Consistency。

環境可以像真實世界一樣變亮、變暗、變暖或變冷，但角色必須一直維持動畫美術所要求的可讀性。

這是一種 PBR 與 NPR 混合的思想。

PBR 負責讓世界具有空間感與材質感，NPR 則負責讓角色保留動畫設計語言。

一棵樹也值得花很多 GPU 工程時間

開放世界最可怕的東西往往不是 Boss，而是樹。

因為一棵樹很便宜，一整片森林卻可能出現成千上萬棵。

《鳴潮》因此依照平台與距離使用不同層級的植被表示方式。

PC 與主機大致採用：

近距離 → 真正 3D Tree

中距離 → Billboard

遠距離 → Imposter

手機則更加激進：

近距離就可能開始使用 Billboard，中遠距離則主要依靠 Imposter。

Billboard 可以把真正的 3D 樹替換成幾張始終面向攝影機的平面。

庫洛表示，其 Polygon 數通常只需要原模型約 30% 到 40%。

但這會產生一個有趣問題。

Billboard 始終面對 Camera。

如果拿同一片 Billboard 去產生 Shadow，當玩家轉動攝影機時，樹本身的幾何方向也在變，Shadow 就可能跟著奇怪地轉動。

庫洛的解法是在一般 Rendering 時讓 Billboard 面向 Camera，但進入 Shadow Rendering 時改為面向 Light Source。

也就是同一棵假樹，在玩家眼睛與太陽眼睛裡，看的是不同方向。

遊戲圖學很多時候就是這樣：

畫面是真的，方法不一定是真的。

為什麼後來又加入 Ray Tracing？

SSR 很有效率，但永遠存在 Screen Space 的先天限制。

例如一座建築就在玩家背後，它理論上應該出現在前方水面的 Reflection 裡。

但 SSR 看不到攝影機後面的 Geometry，因此沒有資料可以反射。

Ray Tracing 就能解決這個問題。

光線可以真正進入 3D Scene，透過 Acceleration Structure 尋找碰撞，因此能取得螢幕之外的物件資訊。

《鳴潮》在 PC 端後來逐步加入 Ray-Traced Reflection，以及更加完整的 Ray Tracing Lighting 技術。

困難在於，它仍然是一款 UE4.26 遊戲。

庫洛因此研究了數套方案，包括 ReSTIR、SHaRC、NVIDIA NRD，以及 UE5 的 Lumen。

最早測試 ReSTIR 時，在 RTX 4060、2K 解析度環境下，ReSTIR 本身可能需要約 5 到 10 ms，而 NRD Denoising 又需要約 3 到 4 ms。

對一款目標 60 FPS 的遊戲而言，整張 Frame 的時間預算只有大約 16.67 ms。

光這兩個步驟就可能把時間幾乎吃光。

因此團隊最後把目光移向 Lumen。

在 UE4.26 裡自己重新做一部分 Lumen

Lumen 原本是 Unreal Engine 5 的核心 Global Illumination 與 Reflection 系統之一。

UE4.26 本身沒有完整 Lumen。

庫洛的做法並不是直接 Copy and Paste。

團隊分析硬體 Ray Tracing 版本的 Lumen，再將所需架構重新實作到自己的 UE4.26 分支。

其中包括 Screen Probe Gather、Radiance Cache 與 Reflections 等核心功能。

部分 UE5 架構無法直接移植。

例如 UE5 Lumen 使用 Surface Cache 保存物件表面的 Radiance 資訊，而《鳴潮》的 UE4.26 環境沒有直接使用這套結構。

庫洛因此自行實作 Clipmap Irradiance Cache，以多層 Grid 保存不同尺度的間接光資訊。

最後形成的其實不是單純的『UE5 Lumen on UE4』。

更精確地說，是一套以 Lumen 為技術基礎、針對《鳴潮》UE4.26 Pipeline 重建與客製化的 Ray Tracing Lighting System。

經過最佳化後，在 RTX 4060 上，團隊把包含 Denoising 的間接光處理壓到 2 ms 以下，Reflection 同樣控制在 2 ms 以下。

600 盞燈：10.37 ms 變成 3 ms 左右

開放世界另一個 Ray Tracing 惡夢是 Light 數量。

UE4 原本的 Ray Tracing Light Sampling 有數量與成本限制。

《鳴潮》的城市、室內、技能與環境可能同時存在大量燈光。

在 600 個 Light 的測試場景中，UE4 原本的 Sampling 方式需要約 10.37 ms。

這已經無法接受。

庫洛因此導入 ReGIR，也就是 Rendering Many Lights with Grid-Based Reservoirs。

它把世界劃分成 Grid，每個區域優先保留真正影響該位置的重要 Light，而不是讓每條 Ray 都重新考慮所有燈光。

最佳化後，ReGIR 本身約需要 0.43 ms，相關 Ray Tracing 處理約 2.65 ms。

從十毫秒等級降到約三毫秒，是非常巨大的差距。

而這正好說明即時 Ray Tracing 的核心並不是『增加更多 Ray』。

真正重要的是：

哪些 Ray 根本不用射？

哪些 Light 根本不用算？

哪些結果可以重複利用？

Toon Shader 與 Ray Tracing 其實會打架

Ray Tracing 的目的通常是讓光線更自然。

但 Toon Shader 有時偏偏不想要自然。

例如現實世界的 Soft Shadow 通常有柔和 Penumbra，看起來非常漂亮。

但動畫人物的臉部與身體如果全部使用柔軟寫實陰影，角色反而可能失去原本乾淨的二次元造型。

所以《鳴潮》沒有簡單地把 Ray-Traced Shadow 套到所有角色身上。

角色自身陰影仍然保留專用 Toon Shadow，而不完全參與 Ray-Traced Shadow。

但角色仍會接收 Global Illumination，讓人物受到周圍環境顏色與間接光影響，不會像一張貼紙浮在世界前面。

團隊甚至對 Normal 進行藝術化處理。

例如把 Normal 稍微朝 Camera 方向拉近，臉部與頭髮則可能使用更接近球形的 Normal Distribution，減少 Mesh 細微 Polygon 方向造成的碎裂陰影。

Indirect Lighting 也會轉換到 HSV Color Space 後進行限制，避免皮膚受到周圍顏色污染過度。

這非常典型地展示了 Stylized Rendering 的核心哲學：

最準確的光，不一定是最好看的光。

光追最大的 Bottleneck 居然曾經是 CPU

Ray Tracing 通常讓人第一時間想到 GPU。

但《鳴潮》的最佳化案例顯示，事情沒有那麼簡單。

庫洛在 UE4 Ray Tracing Pipeline 中發現，CPU RHI Thread 本身就可能先變成 Bottleneck。

初期測試中：

Gather Instances 約需要 3.2 ms。

Build Acceleration Structure 約需要 2.8 ms。

Bind Shader Binding Table 約需要 2.4 ms。

即使使用 Core i9-13900K，開啟 Ray Tracing 後 Frame Time 一度仍達到約 19.8 ms。

也就是理論上甚至無法穩定 60 FPS。

原因是 GPU 在開始處理 Ray 之前，CPU 必須先告訴它：

世界裡有哪些 Object？

哪些物件需要 Ray Tracing？

Acceleration Structure 怎麼建立？

每種類型的 Ray 該使用哪個 Shader？

如果 CPU 在準備這些資料時太慢，再強的 GPU 也只能坐在那裡等資料。

把 19.8 ms 一路壓到 10.5 ms

庫洛最後分數個階段處理 CPU Bottleneck。

首先做 Culling。

不是所有開放世界 Object 都值得加入 Ray Tracing Scene。

團隊依照 Camera 前後方向、距離與 Solid Angle，把影響極小的物件剔除。

接著把部分原本放在 Local Root Signature 的共用資料轉移到 Global Root Signature，降低 SBT Binding 成本。

Frame Time 因此從 19.8 ms 降到約 16.6 ms。

第二階段則把 Gather Instances 的部分工作拆到其他 Thread，並將可以提前完成的 Acceleration Structure 工作預先執行。

Frame Time 降至約 14.5 ms。

最後，Bind SBT 也被拆分，靜態資源可以先進行 Pre Bind，而不必全部卡在 Rendering 最關鍵的時間點。

完成後，Ray Tracing 開啟時的 CPU Frame Time 約降到 10.5 ms；未開 Ray Tracing 約為 7.35 ms。

這是一個非常漂亮的即時圖學案例。

因為它說明性能最佳化並不永遠等於降低畫質。

有時候你根本不需要少算任何一束光，只需要不要讓 CPU 和 GPU 排隊等彼此。

天空也不用真的拿 Ray 去撞

Ray Tracing 最大的優點是可以追蹤真實 Geometry。

但天空沒有必要這麼做。

如果每一條沒有撞到 Geometry 的 Ray 最後都要進入昂貴的 Sky Rendering Pipeline，成本會相當高。

庫洛的解法非常經典。

把 Sky Rasterize 成 512×512 Cube Map。

而且不是每 Frame 重新更新 Cube Map 六個方向。

每一幀只更新其中一面。

當 Ray 沒有擊中任何 Geometry 時，就按照 Ray Direction 去 Sample 這張 Cube Map。

結果是 Reflection Performance 提升約 25%。

玩家看到的仍然是天空倒映在水面與金屬上。

GPU 看到的則是一張很便宜的 Texture。

這就是 Real-Time Graphics 最常見的智慧：

只要最後的 Pixel 看起來對，就不一定需要用最昂貴的方法得到它。

Ray Payload：64 Bytes 也嫌太胖

Ray Tracing Shader 之間需要透過 Payload 傳遞資訊。

例如 Ray 擊中什麼材質、位置、Normal 或其他相關資料。

UE 原本使用的 FPacked Material Closest Hit Payload 大約為 64 Bytes。

庫洛重新分析自己真正需要的資料後，把它壓縮到 32 Bytes。

團隊甚至測試過 20 Bytes 與 16 Bytes，但最後發現性能與畫質平衡不理想，因此選擇 32 Bytes。

Payload 變小，可以降低 Memory Traffic 與 Register Pressure，也有助於提升大量 Ray 同時執行時的 GPU 效率。

這聽起來只是少了 32 Bytes。

但一個畫面可能存在數百萬條 Ray。

32 Bytes × 數百萬次，就不再是一個小數字。

另外《鳴潮》還研究了 Opacity Micro-Map，用來降低透明 Geometry 的 Ray Intersection 成本，以及 Shader Execution Reordering，讓 GPU 把相似的 Ray 與 Material 工作重新整理後一起執行，提高硬體利用率。

這些都是非常底層的 GPU Optimization。

DLSS 讓最後一段性能問題交給 AI

除了遊戲引擎本身的最佳化，《鳴潮》PC 版也逐步採用了 NVIDIA 的 RTX 軟硬體生態。

遊戲最初支援 DLSS Super Resolution，之後增加 DLSS Frame Generation、NVIDIA Reflex 與 Ray-Traced Reflections。

2025 年 8 月 28 日又正式加入 DLSS 4 Multi Frame Generation，供 RTX 50 系列使用。

NVIDIA 的測試顯示，在 Ray Tracing 與其他設定拉高的條件下，DLSS 4 Multi Frame Generation 可以大幅提高輸出的 FPS。

但這裡必須理解一件事：

Frame Generation 提高的是 Displayed Frame Rate，不等於遊戲真正模擬世界的速度同比提升。

例如遊戲原本真正 Render 60 FPS，再透過 AI 生成額外 Frame，螢幕可能呈現遠高於 60 FPS 的畫面。

視覺流暢度確實會增加，但 Input、Physics、Game Logic 並不會因此全部變成數倍速度。

所以 DLSS 4 並不是讓 GPU 憑空多出四倍 Rasterization 能力。

它比較像是在完整 Render Frame 之間，由 AI 預測合理的中間畫面。

這也是 NVIDIA Reflex 很重要的原因之一：Frame Generation 增加 Pipeline 複雜度後，需要盡量降低其他部分的 System Latency。

《鳴潮》的 GPU Optimization 為什麼值得研究？

因為它展示了一件現代遊戲很重要的事情：

高畫質不再是一項技術完成的。

一幀《鳴潮》的畫面背後可能同時存在：

Deferred Rendering、G-Buffer、One Pass Deferred、SSR、GTAO、Temporal Reprojection、Billboard、Imposter、Custom Toon Lighting、Rasterized Shadow、Hardware Ray Tracing、Lumen-derived GI、Radiance Cache、ReGIR、Acceleration Structure、DLSS 與 Frame Generation。

而每一項功能都有不同的性能成本。

真正的 Rendering Engineer 工作並不是把所有 Feature 打開。

而是決定每一個 Pixel 到底值得花多少錢。

近處的樹用真正 Geometry。

遠處的樹換成 Imposter。

畫面內的反射可以使用 Screen Space Data。

畫面外的重要反射交給 Ray Tracing。

天空不需要 Ray 真正追蹤，就使用 Cube Map。

角色不需要完全物理正確，就保留 Toon Shadow。

靜態 Acceleration Structure 不需要每一幀重新做，就提前準備。

最後真的算不動時，再利用 Temporal Reconstruction 與 AI Upscaling 取得更多畫面品質與 Frame Rate。

整套系統更像是一場大型資源管理遊戲。

GPU 有固定的 Frame Budget。

60 FPS 只有約 16.67 ms。

每加入一項效果，就得問一次：

這幾毫秒值得嗎？

它其實已經不是普通的 UE4.26

所以說《鳴潮》是一款 UE4 遊戲沒有錯。

但如果因此認為它只是使用 2019 年左右的 Unreal Engine 技術，就會低估它實際的 Renderer。

今天的《鳴潮》更接近：

UE4.26 Core + Custom Deferred Rendering + One Pass Deferred Mobile Pipeline + Custom Character NPR Lighting + SSR / GTAO + Billboard / Imposter Vegetation + Hardware Ray Tracing + Lumen-inspired and reconstructed GI / Reflection Pipeline + Custom CPU / GPU Ray Tracing Optimization + DLSS 4 / Frame Generation / Reflex

它並沒有真正變成 Unreal Engine 5。

反而是一個更有趣的例子：一套 Live Service Game Engine 如何在不能輕易更換地基的情況下，不斷把新世代圖學技術搬進舊架構。

而庫洛下一步甚至已公開提到正在研究 Inline Ray Tracing、Bindless、類似 Nanite 的 Mega Geometry，以及更進一步的 Ray-Traced Shadow 與 Transparency。

某種程度上，《鳴潮》現在最大的技術特色已經不是 UE4 或 UE5 的版本號。

而是它證明了大型遊戲真正使用的 Engine，到了開發後期往往早就不再等同於 Epic 原本發佈的那一套 Unreal Engine。

當一款遊戲長期營運數年之後，引擎本身也會逐漸成為產品的一部分。

《鳴潮》就是一個相當漂亮的例子。

Tech English 專有名詞

Deferred Rendering（延遲渲染）：先將材質、Normal、Depth 等資訊保存到 G-Buffer，再統一進行光照計算的渲染方式。特別適合大量光源與複雜後處理，但會產生較高的 Buffer 與記憶體頻寬需求。

One Pass Deferred（單通道延遲渲染）：盡量在 GPU On-Chip Memory 中完成 Deferred Rendering 中間步驟，減少資料來回外部記憶體的次數，對 Tile-Based Mobile GPU 的功耗與頻寬控制尤其重要。

G-Buffer（幾何緩衝區）：Deferred Rendering 中保存畫面幾何與材質資料的一組 Buffer，常包含 Depth、Normal、Base Color、Roughness 等資訊，之後的 Lighting Pass 會利用這些資料計算最終畫面。

Acceleration Structure（加速結構）：Ray Tracing 使用的空間索引資料結構，通常以 BVH 為核心，讓 Ray 不需要逐一檢查場景裡所有 Triangle，就能快速找到可能發生碰撞的 Geometry。

Ray Payload（光線負載資料）：Ray Tracing Shader 在 Ray Generation、Hit、Miss 等階段之間傳遞的資料。Payload 越大，可能增加 Register 與 Memory 壓力，因此壓縮 Payload 是常見的 GPU 最佳化方式。

Temporal Reprojection（時間重投影）：把上一幀得到的畫面、Depth、Lighting 或 Reflection 結果依照 Camera 與 Object Motion 重新投影到目前 Frame，讓遊戲重複利用過去計算結果，是現代即時渲染降低成本的重要技術。