鑽石舞台

最近在工作中越來越多地接觸到一些3D以及相比常見特性更酷炫的效果，因此萌發了想要自己從0開始打造一個渲染引擎的念頭，一方面是為了更好地實現公司業務的需求，另一方面則是可以學到整個渲染流水線上的方方面面。

因為之前做的大部分都是在特效這塊，對OpenGL會比較熟悉一些，但是放大到渲染引擎上就很多方面不熟悉了，甚至有些是完全0基礎，在給自己今年定下這麼一個目標時也是一頭霧水，有種瞬間不知道該向哪裡邁出第一步的感覺。因此這幾天基本都在尋找和渲染引擎甚至遊戲引擎相關的一些基本信息和資料，自己給自己提問題，再從問題出發去尋找答案，一步步地去理清自己的思路，從而形成了這一份文章。

文章裡面的很多內容都是自己整理各位大神的文章/回答中的摘要而來（所有引用均會註明出處，在此對各位大神表示感謝和仰望），而且只靠一篇文章是肯定不足以完全講述清楚整個引擎所需要了解到的內容的，只是從我自己的角度來說，這篇文章之於之後構建渲染引擎之路來說，無異於撥雲見日的作用。

另外這系列文章假定各位對OpenGL具有一定的基礎，因此不會過多地介紹OpenGL的一些基礎知識如渲染流程、着色器用法等。

且不論遊戲引擎這樣的龐然巨物，就只說渲染引擎所需要涉及的內容就非常，你可能要考慮怎麼去封裝渲染API，還要考慮怎麼去整合各類效果系統，初版效果出來了，要不要考慮搞搞Vulkan搞搞Metal，什麼樣的方案才是最佳的等等。

因此如果沒有一個方向就開始尋找資料的話和大海撈針沒有什麼區別，也容易因為一時間接收的資訊過多進而打擊信心和興趣，因此在開始找資料之前我給自己定了幾個問題，以這個幾個問題為方向去找資料為自己解答：

一個渲染引擎是由哪些系統組成的？這些系統都是不可或缺的嗎？

實現一個渲染引擎需要點亮哪些技能點？哪些是必須技？哪些可以邊做邊點亮？

渲染引擎的基本渲染流程是什麼樣的？

目前有哪些出色的渲染引擎？怎麼篩選參考引擎？參考哪些？

而在尋找答案的過程中，自然而然就也會接觸到其他方面的內容，比如一些自己之前見都沒見過的名詞，或者是大多數引擎都在用的成熟方案等等，這些也都會一併記錄下來。

其實這篇文章是有一個檢驗收穫的方式的，這個方式在一開始是沒有的，但是在找資料的過程中看到知乎大佬的回答有所感悟，在這篇文章結束時再回過頭來看看下面這句話，如果大致明白了，那麼這篇文章就起到作用了：

而這段話正是這一輪資料搜尋下來個人覺得最精煉的對渲染流程的描述了，至於裡面具體各個名詞所指則會在後面的內容進行補充，當然各個渲染引擎的流程在細節之處甚至一些環節上都會做出有所區別，這些則會在後面針對一些參考引擎做分析的時候再逐步整理出來。

那麼，啟程！

先貼一下找到的知乎上的回答：

是不是有種看一眼就想放棄的衝動 ？(╯°Д°)╯︵ ┻━┻

但是正如我們在日常開發中突然遇到一個新的技術需求的時候一樣，一般我們也不會把一個技術學到精通來才開始落地，而是會先預研一下方案，做下對比，掌握好基礎，對一些風險提前做好功課，保證好大方向上的正確性，然後就會開始逐步落地，在過程中慢慢打磨。

類比到上面的內容也是如此，按照我自己的想法，我覺得首先C++的基本語法、內存管理、標準庫的使用等基礎內容以及OpenGL的渲染管線和基本的glsl、矩陣這些是在開始之前必須要先打好底子的，否則可能會連參考第三方開源引擎都成問題，更不要說自己去寫了，而在自己寫項目或學習第三方開源項目的過程中則可以對遇到的不明白或者不完全理解的內容進行進一步的學習，不求快但求吃透每一點，以這樣的方式去持續擴大或加深自己的技能，在這個過程中儘量以點及面，每一個細節儘可能多去了解一些邊邊角角涉及到的地方，以便自己能夠儘快完成一個又一個的閉環，最終對整個領域的理解越來越清晰。

其次就是合理安排出一部分時間來進行理論方面的系統學習，比如計算機圖形學等，系統性的學習個人還是比較推薦通過書籍來進行，雖然周期更長，但是可以讓你對這個領域的方方面面能夠有一個更清晰的認識，從而形成一個更大的閉環。

而至於dx、metal、編譯知識這些如果暫時不需要做這方面的需求的話倒不是非常關鍵，可以放到上面的技能學習之後，甚至可能很長一段時間你都不會使用到，當然也可能你現在是需要用dx而不需要opengl，那麼就是dx的基礎知識是必須的opengl排到後面，總之因人而異吧。

這部分內容是我在尋找渲染流程過程中的額外收穫，雖然說的是演化史，但是裡面的內容正好是對啟程章節里對渲染引擎主要流程的描述的擴展，通過對多種着色方式的了解，可以間接對渲染流程里的幾個主要步驟有一個初步的感知。

該章節的內容起源是3D渲染引擎着色方式的演化史，原文對各個着色方式的介紹比較簡明扼要，在閱讀完這篇文章後我又自己去對裡面的各個名詞和許多不理解的地方進行了搜索，因此大綱上還是會按照這篇文章的幾大部分進行，在內容裡面再補上自己找到的額外的資料，主要來源於實時渲染中常用的幾種Rendering Path 和其他針對其中細節講解的文章。

這部分個人認為在這篇文章的階段不需要深究裡面的實現細節，這個可以在後續分析開源引擎流程以及自主實現的時候去深入研究，在這裡更多地是對這些Render path有一個印象並且知道他們的大致渲染原理、彼此之間的區別以及能解決什麼樣的問題，從而能在後面的引擎中因地制宜地使用不同的着色方式。

Rendering Path其實指的就是渲染場景中光照的方式。由於場景中的光源可能很多，甚至是動態的光源。所以怎麼在速度和效果上達到一個最好的結果確實很困難。以當今的顯卡發展為契機，人們才衍生出了這麼多的Rendering Path來處理各種光照。

在介紹各種光照渲染方式之前，首先必須介紹一下現代的圖形渲染管線。這是下面提到的幾種Rendering Path的技術基礎。

現代的渲染管線也稱為可編程管線（Programmable Pipeline），簡單點 說就是將以前固定管線寫死的部分（比如頂點的處理，像素顏色的處理等等）變成在 GPU 上可以進行用戶自定義編程的部分，好處就是用戶可以自由發揮的空間增大，缺點就是必須用戶自己實現很多功能。

下面簡單介紹下可編程管線的流程。以 OpenGL 繪製一個三角形舉例。首先用戶指定三 個頂點傳給Vertex Shader。然後用戶可以選擇是否進行Tessellation Shader（曲面細分可能會用到）和Geometry Shader（可以在 GPU 上增刪幾何信息）。緊接着進行光柵化，再將光柵化後的結果傳給Fragment Shader進行pixel級別的處理。最後將處理的像素傳給FrameBuffer並顯示到屏幕上。

名詞解釋Geometry：即我們所要渲染的一個幾何圖形Vertex Shader：頂點着色器，處理每個頂點，將頂點的空間位置投影在屏幕上，即計算頂點的二維坐標。Tessellation Shader：曲面細分着色器，是一個可選的着色器，用於細分圖元Geometry Shader：幾何着色器，是一個可選的着色器，用於逐圖元的着色，可以產生更多的圖元Fragment Shader：片段着色器，也稱為像素着色器（Pixel Shader），用於計算「片段」的顏色和其它屬性，此處的「片段」通常是指單獨的像素後面文章內容中出現的VS、TS、GS、FS（PS）即對應上圖中的Vertex Shader、Tessellation Shader、Geometry Shader、Fragment ShaderFrameBuffer：幀緩衝存儲器，簡稱幀緩存或顯存，它是屏幕所顯示畫面的一個直接映象，又稱為位映射圖(Bit Map)或光柵。幀緩存的每一存儲單元對應屏幕上的一個像素，整個幀緩存對應一幀圖像。

這是最初始的渲染方式，原理是以mesh為單位進行渲染，在光柵化後，對每個PS進行計算時，根據光照進行着色計算，所以這種方式稱為前向着色。

Forward Rendering是絕大數引擎都含有的一種渲染方式。要使用Forward Rendering，一般在Vertex Shader或Fragment Shader階段對每個頂點或每個像素進行光照計算，並且是對每個光源進行計算產生最終結果。下面是 Forward Rendering 的核心偽代碼：

For each light: For each object affected by the light: framebuffer += object * light

比如在 Unity3D 4.x 引擎中，對於下圖中的圓圈（表示一個Geometry），進行 Forward Rendering 處理：

將得到下面的處理結果：

也就是說，對於 ABCD 四個光源我們在Fragment Shader中我們對每個 pixel 處理光照， 對於 DEFG 光源我們在Vertex Shader中對每個 vertex 處理光照，而對於 GH 光源，我們採用球調和（SH）函數進行處理。

這種方式存在以下弊端：

如果像素被其他像素遮蔽了，就浪費了寶貴的處理結果

光源多起來後管理很麻煩，Shader也不好寫。

因此，Deferred rendering就應運而生了。

很明顯，對於Forward Rendering，光源數量對計算複雜度影響巨大，所以比較適合戶外這種光源較少的場景（一般只有太陽光）。但是對於多光源，我們使用Forward Rendering的效率會極其低下。因為如果在Vertex Shader中計算光照，其複雜度將是O(num_geometry_vertexes ∗ num_lights)，而如果在Fragment Shader中計算光照，其複雜度為O(num_geometry_fragments ∗ num_lights)。可見光源數目和複雜度是成線性增長的。對此，我們需要進行必要的優化。比如

多在 Vertex Shader 中進行光照處理，因為有一個幾何體有 10000 個頂點，那麼對於 n 個光源，至少要在 Vertex Shader 中計算 10000n 次。而對於在 Fragment Shader 中進行處理，這種消耗會更多，因為對於一個普通的 1024x768 屏幕，將近有 8 百萬的像素 要處理。所以如果頂點數小於像素個數的話，儘量在 Vertex shader 中進行光照。

如果要在 fragment shader 中處理光照，我們大可不必對每個光源進行計算時，把所有像素都對該光源進行處理一次。因為每個光源都有其自己的作用區域。比如點光源的作用區域是一個球體，而平行光的作用區域就是整個空間了。對於不在此光照作用區域的像素就不進行處理。但是這樣做的話，CPU 端的負擔將加重。

對於某個幾何體，光源對其作用的程度是不同，所以有些作用程度特別小的光源可以不進行考慮。典型的例子就是 Unity 中只考慮重要程度最大的 4 個光源。

名詞解釋Mesh：網格，任何一個模型都是由若干網格面組成，而每一個面又有若干個三角形組成，也就是說，模型是由若干個三角形面組成的

Deferred Rendering（延遲渲染）顧名思義，就是將光照處理這一步驟延遲一段時間再處理。

具體做法就是將光照放在已經將三維物體生成二維圖片之後進行處理。也就是說將物空間的光照處理放到了像空間進行處理。要做到這一步，需要一個重要的輔助工具——G-Buffer。

G-Buffer 主要是用來存儲每個像素對應的 Position，Normal，Diffuse Color 和其他Material parameters。根據這些信息，我們就可以在像空間中對每個像素進行光照處理。

下面是 Deferred Rendering 的核心偽代碼。

For each object: Render to multiple targetsFor each light: Apply light as a 2D postprocess

這種渲染方式相比 Forward rendering 就是在渲染mesh時，並不進行光照計算，而是按照以下步驟進行：

將深度、法線、Diffuse、Specular等材質屬性分別輸出到GBuffer里（其實就是幾張RT）

然後GBuffer里的深度和法線信息，累加所有光照的強度到一張光照強度RT上

根據GBuffer里的Diffuse和Specular信息，以及光照強度RT，進行着色計算

名詞解釋GBuffer：指Geometry Buffer，亦即「物體緩衝」。區別於普通的僅將顏色渲染到紋理中，G-Buffer指包含顏色、法線、世界空間坐標的緩衝區，亦即指包含顏色、法線、世界空間坐標的紋理。由於G-Buffer需要的向量長度超出通常紋理能包含的向量的長度，通常在遊戲開發中，使用多渲染目標技術來生成G-Buffer，即在一次繪製中將顏色、法線、世界空間坐標分別渲染到三張浮點紋理中

下面簡單舉個例子：

首先我們用存儲各種信息的紋理圖。比如下面這張Depth Buffer，主要是用來確定該像 素距離視點的遠近的。

根據反射光的密度/強度分度圖來計算反射效果。

下圖表示法向數據，這個很關鍵。進行光照計算最重要的一組數據。

下圖使用了 Diffuse Color Buffer。

這是使用 Deferred Rendering 最終的結果。

Deferred rendering的最大的優勢就是將光源的數目和場景中物體的數目在複雜度層面上完全分開，也就是說場景中不管是一個三角形還是一百萬個三角形，最後的複雜度不會隨光源數目變化而產生巨大變化。從上面的偽代碼可以看出Deferred rendering的複雜度為O(screen_resolution + num_lights)。

這種渲染方式也有一些弊端：

由於硬件限制或者性能限制，GBuffer里保存的材質信息有限，對於特殊材質來說，例如人的皮膚、翡翠等，渲染結果很不好

延遲計算光照會大幅增加紋理帶寬和幀緩衝區帶寬的開銷

當光源數量很多時，光源會不斷對光照強度RT進行累加，也會大幅增加幀緩衝區帶寬開銷

由於硬件限制或者性能限制，不能使用硬件支持的MSAA，只能使用類似後期處理的FXAA或者Temporal AA

名詞解釋MSAA、FXAA、Temporal AA都是抗鋸齒（Anti-Aliasing）技術，鋸齒的來源是因為場景的定義在三維空間中是連續的，而最終顯示的像素則是一個離散的二維數組。所以判斷一個點到底沒有被某個像素覆蓋的時候單純是一個「有」或者「沒有"問題，丟失了連續性的信息，導致鋸齒。具體區別可見FXAA、FSAA與MSAA有什麼區別？

Deferred Rendering 局限性是顯而易見的。比如我在 G-Buffer 存儲以下數據：

這樣的話，對於一個普通的 1024x768 的屏幕分辨率。總共得使用1024x768x128bit=20MB， 對於目前的動則上 GB 的顯卡內存可能不算什麼，但是使用 G-Buffer 耗費的顯存還是很多的。一方面，對於低端顯卡，這麼大的顯卡內存確實很耗費資源；另一方面，如果要渲染更酷的特效，使用的 G-Buffer 大小將增加，並且其增加的幅度也是很可觀的；並且存取 G-Buffer 耗費的帶寬也是一個不可忽視的缺陷。

對於 Deferred Rendering 的優化也是一個很有挑戰的問題。下面簡單介紹幾種降低 Deferred Rendering 存取帶寬的方式。最簡單也是最容易想到的就是將存取的 G-Buffer 數據結構最小化，這也就衍生除了Light Pre-Pass方法。另一種方式是將多個光照組成一組，然後一起處理，這種方法衍生了Tile-based deferred Rendering。

這個技術是CryTek這個團隊（該團隊開發了CryENGINE遊戲引擎，即下面簡稱的CE，如果還不熟悉的話，那麼這個團隊開發了《孤島危機》、《孤島驚魂》等遊戲）原創的，由 Wolfgang Engel 在他的博客中提到的，也用於解決Deferred rendering渲染方式里的第一個弊端。原理跟Deferred rendering差不多，只是有幾處不同：

GBuffer中只有深度（Z）和法線（Normal）數據，對比Deferred Rendering，少了 Diffuse Color， Specular Color 以及對應位置的材質索引值

在 FS 階段利用上面的 G-Buffer 計算出所必須的 Light properties，比如 Normal * LightDir, LightColor, Specular 等 Light properties，將這些計算出的光照進行alpha-blend並存入LightBuffer（就是用來存儲 Light properties 的 buffer）

着色過程不是Deferred rendering中類似於後處理的方式，而是渲染mesh，即將結果送到Forward rendering渲染方式計算最後的光照效果

相對於傳統的Deferred Render，使用 Light Pre-Pass 可以對每個不同的幾何體使用不同 的 Shader 進行渲染，所以每個物體的 Material properties 將有更多變化。這裡我們可以看出對於傳統的 Deferred Rendering，它的第二步是遍歷每個光源，這樣就增加了光源設置的靈活性，而 Light Pre-Pass 第三步使用的其實是Forward rendering，所以可以對每個mesh設置其材質，這兩者是相輔相成的，有利有弊。

另一個 Light Pre-Pass 的優點是在使用 MSAA 上很有利。雖然並不是 100%使用上了 MSAA（除非使用 DX10/11 的特性），但是由於使用了 Z 值和 Normal 值，就可以很容易找到邊緣，並進行採樣。

下面這兩張圖，上邊是使用傳統 Deferred Render 繪製的，下邊是使用 Light Pre-Pass 繪 制的。這兩張圖在效果上不應該有太大區別。

其實這種方式也有弊端：

由於不透明物體在主視口中被渲染了兩次，會大幅增加渲染批次，不過好在CE對狀態切換管理的非常好，所以渲染批次的承載力很高

由於某些特殊材質需要對光照進行特殊處理，比如說樹葉的背光面也會有一定的光照，所以這種方式也不太完美

印象里貌似CE對主光，例如太陽光，不累加進光照強度RT，而是着色時單獨處理，這樣的話效果會提升不少，至少室外場景是完全能夠解決問題的；而對於點光源比較多的室內場景，主光着色好看了就會效果很好了，畢竟其他光照的影響占比比較小。

這個方案是對Deferred rendering渲染方式里的第三個弊端進行優化的。原理就是：

先將整個光照強度RT分成很多個正方形區域，計算每個區域受哪些光源影響，並保存起來

然後以每個區域為單位，在一個批次里累加所有的光照

這樣就能減少對光照強度RT上某個像素頻繁讀寫的次數。

TBDR 主要思想就是將屏幕分成一個個小塊tile，然後根據這些 Depth 求得每個 tile 的bounding box。對每個 tile 的 bounding box 和 light 進行求交，這樣就得到了對該 tile 有作用 的 light 的序列。最後根據得到的序列計算所在 tile 的光照效果。

對比Deferred Render，之前是對每個光源求取其作用區域light volume，然後決定其作用的的 pixel，也就是說每個光源要求取一次。而使用 TBDR，只要遍歷每個 pixel，讓其所屬 tile 與光線求交，來計算作用其上的 light，並利用 G-Buffer 進行 Shading。一方面這樣做減少 了所需考慮的光源個數，另一方面與傳統的 Deferred Rendering 相比，減少了存取的帶寬。

在一篇文章中提到目前所有的移動設備都使用的是 Tile-Based Deferred Rendering(TBDR) 的渲染架構，，裡面還提及了使用TBDR的一些注意事項，感興趣的可以看看，以及針對移動端TBDR架構GPU特性的渲染優化，移動GPU渲染原理的流派——IMR、TBR及TBDR

名詞解釋tile：區塊，即將需要渲染的畫面分成一個個的區塊bounding box：邊界框，是一個矩形框，可以由矩形左上角的xx和yy軸坐標與右下角的xx和yy軸坐標確定。從技術上講，邊界框是包含一個物體的最小矩形light volume：體積光，散射是一種非常美麗的自然現象，在自然界中光穿過潮濕或者含有雜質的介質時產生散射，散射的光線進入人眼，讓這些介質看起來像攏住了光線一樣，也就是所謂的體積光。可見遊戲開發相關實時渲染技術之體積光

為了解決Deferred lighting裡面的第一個弊端，從CE3的某個版本開始，換成了這種方式。理由是，對於大多數物體來說，Deferred rendering的方式就很好了，而對於特殊材質，則使用Deferred lighting的方式。這樣，既能保持很好的渲染效果，又能避免渲染批次激增。

更詳細的內容可見Hybrid-Deferred-Rendering.pdf

有時候，你轉了很大一個圈以後，發現又回到了原點。

好，那這就到了終極方式了——前向着色的改進版。這個方案是ATI（著名顯卡生產商，06年被AMD收購）發明的，已經應用於Ogre 2.1（開源的面向對象的3D引擎）。UE4（大名鼎鼎的虛幻引擎）正在針對VR研發前向着色，不知道是不是也是這個。

原理也很簡單：

先用Tile-based deferred rendering里的方式計算好每個區域受哪些光照影響

然後像傳統的前向着色一樣渲染每個mesh——當然，要去光照列表里查找影響當前區域的所有光照，並着色

這種方式只有上述提到的一個缺點，那就是可能和Deferred lighting一樣需要渲染兩遍場景，不過以後應該會有優化的方案。優點則有：

渲染效果好

帶寬開銷低，尤其適用於VR這種每幀需要渲染兩遍場景的應用

可以使用硬件支持的MSAA，質量最高。

Forward+的優勢還有很多，其實大多就是傳統 Forward Rendering 本身的優勢，所以 Forward+更像一個集各種 Rendering Path 優勢於一體的 Rendering Path。

Forward+ = Forward + Light Culling。Forward+ 很類似 Tiled-based Deferred Rendering。其具體做法就是先對輸入的場景進行 z-prepass，也就是說關閉寫入 color，只向 z-buffer 寫入 z 值。注意此步驟是 Forward+必須的，而其他渲染方式是可選的。接下來的步驟和 TBDR 很類似，都是劃分 tiles，並計算 bounding box。只不過 TBDR 是在 G-Buffer 中完成這一步驟 的，而 Forward+是根據 Z-Buffer。最後一步其實使用的是Forward rendering方式，即在 FS 階段對每個 pixel 根據其所在 tile 的 light 序列計算光照效果。而 TBDR 使用的是基於 G-Buffer 的Deferred rendering。實際上，forward+比 deferred 運行的更快。我們可以看出由於 Forward+只要寫深度緩存 就可以，而Deferred Rendering除了深度緩存，還要寫入法向緩存。而在Light Culling步驟， Forward+只需要計算出哪些 light 對該 tile 有影響即可。而Deferred Rendering還在這一部分把光照處理給做了。而這一部分，Forward+是放在 Shading 階段做的。所以 Shading 階段 Forward+ 耗費更多時間。但是對目前硬件來說，Shading 耗費的時間沒有那麼多。

以下是Forward+與Deferred Rendering的對比圖：

感興趣的可以再額外看看 forward框架的逆襲：解析forward渲染這篇文章。

名詞解釋Light Culling：剔除光照

渲染引擎屬於遊戲引擎中的一部分，本章節主要簡要整理一下找到的一些渲染引擎和遊戲引擎，具體內在區別後續進一步深入了解的時候再整理補上。

渲染引擎

bgfx

OGRE 3D

osg

The Forge

gkEngine

three.js

pixi.js

g3d

OpenSceneGraph

LiteScene

webglstudio.js

sketch.js

PlayCanvas

遊戲引擎

Unity3D

Unreal

Urho3D

cocos

godot

在Wiki上也已經有整理了目前為止市面上已有的大量遊戲引擎：Game Engine

Github上統計的開源遊戲引擎：game-engines

通過上面的調查我們發現現在市面上的大小引擎數不勝數，一個個地去看的話時間周期估計要以年為單位，首先我們要先從自身的需求出發定出一些對參考引擎所需要具備的特性的要求，然後再根據要求來篩選出幾個比較貼合我們需求的深入研究。

通過上面的調查我們發現現在市面上的大小引擎數不勝數，一個個地去看的話時間周期估計要以年為單位，首先我們要先從自身的需求出發定出一些對參考引擎所需要具備的特性的要求，然後再根據要求來篩選出幾個比較貼合我們需求的深入研究。

以我自身的角度出發，我列出來了以下一些要求：

開源，但是項目規模還未到非常龐大的程度，避免研究周期過長

具備一定規模的使用人數和影響力

保持更新，所用方案不至於落後行業太久

使用C++語言編寫，具備跨平台特性

支持2D/3D渲染，實現粒子系統、光源、動畫系統、後處理等多項功能中的幾種

具備多平台自動切換渲染驅動的話更好

我從上面調查後的引擎列表里整理出了以下幾個符合語言、使用人數、持續更新、支持效果等方面都比較符合的引擎來優先作為研究的對象，後續的分析系列文章也會先以這些引擎來作為目標：

渲染引擎

bgfx

可實現2D以及文字繪製，3D渲染，光照等效果

可自動切換Metal等渲染驅動

OGRE 3D

老牌渲染引擎，除了渲染之外還包含動畫系統和粒子系統

OpenSceneGraph

中文文檔，粒子系統等功能可通過第三方插件實現

遊戲引擎

godot

用的人多，中文文檔，2D和3D都支持

What are the best 3D C++ game engines with full source code access?：外網評價的截止2019最佳遊戲引擎，下面的GoDot排第二，第一是Unreal

Urho3D

歷史久遠使用人數比Godot少很多，各方面表現比較中庸

輕量級項目，支持在該引擎的基礎上方便地擴展各種效果組件

至此我們完成了在邁出跨平台渲染引擎第一步之前的鋪墊工作，我們梳理了渲染引擎的一個大致流程，以及這個流程裡面的關於Rendering path等方面的細節信息，對這些內容有了一個初步的印象，同時列舉了以下令人望而卻步的技能樹，但是我們可以一步一步地吃成胖子，重要地是邁出這第一步，最後我們整理了一下渲染/遊戲引擎列表，並按照自身要求從中梳理了幾個引擎來作為下一步分析研究的目標。

技術交流，歡迎加我微信：ezglumes ，拉你入技術交流群。

私信領取相關資料

推薦閱讀：

音視頻開發工作經驗分享 || 視頻版

OpenGL ES 學習資源分享

開通專輯 | 細數那些年寫過的技術文章專輯

NDK 學習進階免費視頻來了

你想要的音視頻開發資料庫來了

推薦幾個堪稱教科書級別的 Android 音視頻入門項目

覺得不錯，點個在看唄~