渲染，就是將 3D 模型轉換成 2D 影象，並最終呈現在螢幕上的過程。雖然這裡只有一句話，但是這一句話裡面包含了太多的數學、物理和計算機方面的知識，它描述了我們用計算機來虛擬化真實世界的基本邏輯。渲染過程是需要計算機進行運算且消耗時間的。

不同的渲染分類，會用到不同的渲染引擎。

比如實時渲染我們一般會用到 Unity 和 Unreal，離線渲染我們會用到 V-ray 和 Keyshot。但是這些技術和引擎產品都是相通的，所以 Unreal 的實時渲染能力也可以部署在雲端，成為雲渲染的體現。雖然，由於使用場景的不同，引擎本身的渲染演算法都有自己的特點和優勢。但是，隨著硬體計算能力的發展，它們的界限也慢慢變得模糊。

常見的渲染型別有以下幾種：實時渲染、離線渲染、雲渲染、混合渲染。它們中間有重疊交叉，也有技術區別。我們避免太多的專業性描述，嘗試用淺顯易懂的方式來進行解釋。

1、實時渲染

實時渲染（Real-time Rendering）從字面的意思非常容易理解，就是我們要實時的看到渲染之後的 3D 物體或者場景的效果。實時，用數字怎麼理解？至少 24FPS：只有達到或者超過 1 秒鐘播放 24 張連貫影象的速度，人眼觀看時就不會形成卡頓的感覺。

一般的實時渲染場景都是帶有強互動屬性的，比如最常見的 3D 遊戲《王者》《吃雞》，或者是一些帶有互動的 3D 應用，比如智慧城市、智慧園區的視覺化專案。實時渲染的場景中，這些應用都會獨立執行在我們的電腦、手機上，透過本地的硬體能力完成實時渲染的過程。因此，玩大型遊戲的話，硬體效能一定要好。

編輯

2、離線渲染

離線渲染（Offline Rendering）這個從字面意思理解，好像就是 “斷網” 之後在做渲染，但是這種理解是不對的。離線渲染是跟實時渲染相對應的，簡單說就是我們不需要實時的看到渲染效果的場景。

這種場景最常見的就是我們的家裝效果圖。做過裝修的小夥伴應該都知道，如果讓設計公司出效果圖一般都是要收費的（有些為了吸引客戶當然也會免費），他們其實就是在做離線渲染的工作。那為什麼我們不能實時的去渲染一張效果圖，反而要用離線渲染的機制呢？這就要看最後的渲染效果到求要多高了。

編輯

實時渲染，雖然渲染速度快，可以實時生成渲染內容，但是渲染的效果和真實度相對來說是不可能特別高的。對於離線渲染的場景，基本都是對渲染要求非常高的，甚至是完全真實的。

比如剛才提到的家裝效果圖，你可能不需要立刻看到渲染圖，但是如果看到的時候，發現效果不好，就可能要換其他設計公司了。另外一個最常見的就是好萊塢影視大片、3D 動畫等影視場景。他們都需要達到一個非常逼真的渲染效果甚至是完全真實的場景復現，但是對實時性要求不高。所以，一般的好萊塢大片，尤其是特效非常好的那種，拍攝完成後的製作週期都非常長。比如我們耳熟能詳的《阿凡達》，當時動用了 40000 顆 CPU，104TB 記憶體，10G 網路頻寬，整整離線渲染了 1 個多月。

編輯

說到這大家應該會有一個疑問了，怎麼可以用到 40000 顆 CPU 來進行渲染呢？什麼電腦能有這麼多 CPU 呢？其實這就是離線渲染在概念上，容易讓人誤解的地方：離線渲染大多數情況反而恰恰是線上的。

通常情況，如果我們在做家裝效果圖，是可以用自己的一臺普通電腦去進行渲染製作的，但是自己的電腦硬體配置肯定不會特別好。因此，完成整套渲染計算的過程到最終出圖是需要很長時間的，當然電腦硬體越好，時間越短。如果是專業的設計團隊，雖然是需要運用離線渲染達到很高渲染效果，同時肯定也是希望出圖的時間越短越好。

因此就出現了一種新的離線渲染形態：渲染農場。說到渲染農場相信很多人都不陌生，它就是在雲端買了很多渲染伺服器，這些伺服器可以搭建成千上萬顆 CPU 或者 GPU 的叢集，來專門服務那些需要快速完成離線渲染的使用者。

編輯

這就是為什麼《阿凡達》的渲染會用到那麼多 CPU 的原因，當然現在基本都是採用 GPU 來進行渲染工作了。渲染農場其實就是搭建了渲染伺服器叢集，那當然就是線上的了。所以說，只要提到渲染農場，它是離線渲染場景中的一種渲染形式，但是實際上它恰恰是線上的。

3、實時雲渲染

實時雲渲染（Cloud Rendering），這個從字面意義理解就是在雲端完成渲染的意思。但是為什麼上面講到渲染農場的時候，並沒有特意強調它就是雲渲染呢？

其實如果按照渲染髮生的節點來說，渲染農場這種離線渲染就是屬於雲渲染範疇的。但是，我們通常對於雲渲染的理解，一般都是在雲端完成實時渲染的場景。上面我們提到的實時渲染大部分時候都是在我們自己本地的電腦或者手機上完成的，因此對於終端硬體的要求是比較高的，不然 “卡頓” 肯定是無法避免的。

雲渲染的出現就是為了解決這個問題：讓硬體效能不太好的終端也可以實時的渲染效果不錯的 3D 內容。

編輯

雲渲染的基本原理是，把所有的 3D 渲染工作都交給雲端。渲染完成後，編碼成為影片實時的傳送給我們的客戶端，客戶端就變成了一個影片播放器，對影片流進行解碼和播放，這個過程中可以監聽一些滑鼠和鍵盤操作，來完成互動功能。

這樣大量的三維資料和美術資源不用安裝到我們的手機或者電腦的客戶端，而是全部在雲端完成渲染，客戶端只要具備看影片的效能，就可以體驗具有比較好渲染效果的 3D 應用。對於大眾來說，手機裝置不用特別高配，就可以體驗效果很好的遊戲，而且手機一般也不會發燙了。目前雲渲染的場景主要也是體現在遊戲場景中，即雲遊戲。當然還包括一些對渲染質量要求比較高的 3D 視覺化或者數字孿生專案。

編輯

說到這裡，大家對於實時渲染，離線渲染和雲渲染這三種不同的渲染形式，應該有基本的理解了。其實說到渲染本身，就是一個數學演算法在計算機上的運算過程。它們都有各自的優劣和使用場景：

（1） 實時渲染

追求渲染速度，要求比較強的互動體驗。所以即便在客戶端硬體效能較高的情況下，也要做大量的數學演算法最佳化，在不是特別降低渲染效果的同時，減少渲染時間，達到很好的實時性互動。

（2） 離線渲染

追求渲染質量，不要求實時性和互動性。追求的是極致的渲染效果，達到以假亂真的體驗。因此就用最極致最優秀最貼近真實物理原理的渲染演算法，來進行真實度極高的渲染過程。透過渲染農場的雲端計算能力，儘量的減少渲染時間。

（3） 實時雲渲染

追求相對較高的渲染質量同時，也要達到實時性要求。所以雲端算力的部署和排程的能力要求會更高，讓客戶端配置不高的使用者透過雲渲染也能體會到不錯的 3D 應用。

混合渲染（Hybrid Rendering）從字面意思就是非單一方法的渲染機制。這也就使得這個詞，沒有一個完全標準且唯一準確的定義。首先大家需要明白，渲染的最終目的是呈現畫面，不論是圖片、影片，還是實時互動的場景。那為了這個最終的呈現結果，如果渲染過程中採用了很多種方案來混合實現，就可以說它是混合渲染。我們從不同的角度，總結了一些混合渲染的形式。仍然不討論具體的技術實現細節，只是為了方便大家理解概念。

4、基於管線的混合渲染

基於管線的混合渲染，指的是一條渲染管線中，會用到不同的計算承載方式，最終來完成渲染工作。目前的計算承載方式包括：光柵化（Rasterization，包含 Vertex Shader 和 Fragment Shader）、計算著色器（Compute Shader）、光線追蹤著色器（Ray Tracing Shaders）。

渲染管線中，最基本的計算承載方式就是光柵化。原則上，光柵化是為了輸出渲染內容的一整個渲染流程，同時也可以利用流程中的 Vertex Shader 和 Fragment Shader 進行一些計算的處理，但是光柵化過程中是發生在 Render Pass 中，其中有很多 Fix Function，比如剔除、深度測試、顏色混合等，所以用光柵化來進行計算，其實是“不專一”的，效率會相對低下。光柵化對於一些光線不是很複雜的場景仍然是可以勝任的。但是如果光線一旦複雜，它就沒有辦法很好地勝任複雜的光線演算法了，因此渲染效果也就不盡人意。

目前 WebGL 只具備光柵化需要的 Vertex Shader 和 Fragment Shader（Extension 版本除外），計算能力有限且不夠靈活，渲染效果也不會特別優秀。WebGL 為了實現比較好的渲染效果，都是透過預烘焙的方法，將效果附加到貼圖本身，以靜態的方式進行展示，從而失去了對複雜光線變換的實時應對能力。

為了解決光柵化的計算效率低下問題，現代圖形 API 都提供了計算著色器，即 Compute Shader。

WebGPU 也應用了現代圖形 API 的設計原則，同樣支援 Compute Shader

。Compute Shader 本質是一種通用計算的能力（GPGPU），完全運用在 Compute Pass 中的，是“專一”的計算單元，很類似於 CUDA（不過 CUDA 可以透過英偉達的顯示卡做到硬體晶片級別的加速，因此計算效能更高）。有了這種通用計算能力，就不再是光柵化中的“模擬”計算了，而是專業級的計算能力。比如我們用光柵化中的 Fragment Shader 模擬一些演算法，只能限制在二維的平面座標系中，而 Computer Shader 沒有這種限制，也更加的靈活，速度更快。

光線追蹤 Ray Tracing 是一項幾十年前就有的技術，但是因為計算量太大，而無法實現實時渲染。因為 RTX 顯示卡的出現，讓

實時光線追蹤

這個概念再次得到了關注。

光線追蹤是路徑追蹤的一種簡單形式，但是這兩個概念本質上都是一種數學演算法

。光線追蹤著色器（Ray Tracing Shaders）就是特意為光線追蹤這種數學演算法而設計的，它由很多特殊著色器模組的組合而成。下圖是 RTX 光線追蹤的架構圖：

編輯

https：//developer。nvidia。com/rtx/ray-tracing

既然光線追蹤只是一種數學演算法，那麼任何語言和程式設計環境都可以對這個數學演算法進行實現。如果只看圖形領域，我們可以用 CUDA、Fragment Shader（OpenGL， WebGL）、Computer Shader（WebGPU、Vulkan、Metal、DX11/DX12、OpenGL Extension）、RXT（DX12/DXR，、Vulkan）來實現光線追蹤演算法。既然光線追蹤演算法用上面的方式都可以實現，為什麼 RXT 會再次引爆這個概念呢？原因就是它可以實時地實現光線追蹤演算法。RTX 顯示卡針對光線追蹤這一個非常重要且特殊的渲染演算法，單獨做了硬體級別的加速。透過硬體晶片可以直接執行上面提到的光線追蹤過程中的各種著色器模組（可以理解成把 CUDA 的通用計算晶片重新設計，最佳化成更適合執行光線追蹤演算法的晶片），這樣就可以在 3D 場景中實時的完成光線追蹤的運算結果，渲染更加優質的 3D 畫面。

三種計算承載方式：光柵化，計算著色器和光線追蹤著色器都已經介紹完了。它們之間並不是誰要代替誰，也沒有一種完美的方法。而應該對於不同的場景，運用不同的方法。所以，對於混合渲染的概念，相信大家也更加清晰了。只要混合使用了不同渲染方法的渲染管線，我都可以理解成是混合渲染的一種體現。

基於資料的混合渲染

基於資料的混合渲染，指的就是對一個 3D 場景中的不同 3D 資源（模型，場景等）進行分類，相當於對 3D 資產資料進行拆分，把不同類別的 3D 資料放到不同的渲染節點進行渲染，最後透過網路通訊技術，把資料合併到一個需要顯示輸出的節點上，進行最終的呈現。

一般提到這種基於資料的混合渲染，都會和上一期我們聊到的雲渲染有些關聯。因為這種資料拆分的形式可以讓我們天然地想到，把一些複雜度高，計算要求大的任務放到平行計算力更強的雲端，利用渲染叢集進行計算。而我們的個人終端，只渲染計算量相對較小的任務。雲端渲染的結果，最終不論是以影片或圖片的形式傳給客戶端，還是隻把複雜計算的結果返回給客戶端，再由客戶端進行最終的呈現，都會大大降低客戶端的開銷。

在 5G 通訊技術的快速發展下，更加多樣靈活的渲染架構，例如邊，端，雲協同渲染也得到了更多的嘗試和驗證。這種渲染方式，可以充分利用終端及終端附近的邊緣節點的計算能力，避免了全雲端渲染可能會遇到的“卡頓”問題。而且，也是一種“進可攻退可守”的架構設計，透過渲染任務的解耦設計，可以在全終端渲染和全雲端渲染之間靈活切換和調配，進而適應更復雜的渲染需求。

基於硬體的混合渲染

基於硬體的混合渲染，指的就是 CPU 和 GPU 可以同時參與渲染任務的一種混合渲染模式。這裡我們參考 V-ray 的混合渲染模式。首先要說明的是，單純的 GPU 渲染有兩個問題：1）很難進行 Debug：GPU 的程式如果出錯基本都會返回一個 kernel dump（就是核心掛掉了），不會有相應的報錯資訊提示。2）無法充分利用 CPU 的效能：之前的渲染工作基本都是交給 GPU 來進行計算的，CPU 把任務提交給 GPU 之後，CPU 本身其實會處於一段時間的空閒狀態，等於白白浪費了計算能力。為了解決這兩個問題，V-ray 提出的混合渲染就是可以讓 CUDA 同時執行在 CPU 和 GPU 上，這樣可以充分利用 CPU 提交任務給 GPU 之後，本身的空閒時間，同樣可以進行渲染的計算工作。經過測試，V-ray 的混合渲染比單純的 GPU 渲染，完成時間平均縮短了約 20%左右。

這裡需要強調下，這種 CPU 和 GPU 同時進行的混合渲染模式，在 WebGL 的標準下是無法實現的，因為它採用的是全域性狀態機模式，CPU 必須要等待 GPU 的執行結果，才能繼續做下一個任務，簡單說就是同步機制。而 WebGPU 採用了現代圖形 API 的方法，完全遵循非同步形式，這樣才具備實現這種混合渲染的基礎能力

。

https：//www。chaos。com/blog/understanding-v-ray-hybrid-renderin

基於框架的混合渲染

基於框架的混合渲染，指的是渲染過程可以從之前的框架轉移到另外一個全新的框架上實現。2019 年，Unity 提出 Data-Oriented Technology Stack（DOTS）技術，並透過 Hybrid Renderer 來實現。DOTS 的核心就是 ECS（Entities， Components， Systems）的架構設計，也標誌著 ECS 框架在遊戲引擎中的應用（關於 ECS 的細節和優劣勢我們這裡就不做討論了）。Unity 的 Hybrid Renderer 帶來的混合渲染，其實指的是可以讓渲染過程從之前的 OOP 模式（Object-oriented Programming）轉換到 DOP 模式（Data-oriented Programming），是把 GameObjects 轉換成 ECS 中的 Entities。

最終的目的就是利用 ECS 的資料連續記憶體儲存特徵，提高快取命中率，同時引入多核平行計算的優勢，加快渲染過程

。

編輯

https：//docs。unity3d。com/Packages/com。unity。rendering。hybrid@0。50/manual/index。html

講到這裡，我們把一些常見的混合渲染的形式都已經介紹完了。總結下就是，混合渲染沒有一個固定的定義，只要把“渲染”混合使用，都可以叫混合渲染。