我們在引擎架構篇裡介紹了大致的開發範圍和第三方依賴：
star.e：遊戲引擎開發新感覺！引擎架構篇zhuanlan.zhihu.com
已經有很多人問啦，渲染怎麼跨平台，這篇大致介紹下渲染引擎部分的設計。
首先讓我們回想一下，我們作為引擎、圖形程式設計師，心裡到底想要什麼。
引擎簡單易用，做了很好的圖形api封裝（比如unity），能很方便地呼叫api，繪製內容。
能夠完全控制硬體，呼叫原生api，完全按照使用者的意圖執行，沒有任何意外或者限制。
跨平台方便，能寫一次**，復用到多個平台。
能充分挖掘平台潛力，發揮出硬體的全部功能，做出意想不到的效果。
引擎容易修改，能方便地新增自定義新功能，不受任何限制。
引擎容易公升級，每次都能有新的feature加入。
有沒有發現什麼問題？需求全都前後矛盾了好不好！
對圖形api做了封裝，怎麼利用原生api
一套**跨了平台，怎麼挖掘平台效能
引擎被大改特改，公升級衝突怎麼解決
（提這些需求的如果是策劃，估計要倒霉啦）
這些問題很麻煩，都是逃不掉的兩選一，我們沒法全都要，只能被迫選擇。
既然對圖形api做了封裝就會有限制，那麼我們索性不做封裝了。但是呼叫不方便啊！好吧，通過配置來實現功能吧。實在不行，手擼平台**吧。
既然一套**沒法復用多個平台，那就寫多套**吧。這工作量不是成倍增長嗎，怎麼可以？好吧，那只能把工作量削減為原來的幾分之一了，實現相同功能的情況下。
引擎已經被改的面目全非了，公升不了了。那我們盡量不讓改引擎，準確講是讓使用者沒有改引擎的需求。
這和unity、ue4是截然相反的設計思路，所以用起來感覺不一樣。能不能實現，就需要思考和實踐了。
這種設計傾向會帶來一些好處，比如我們不需要跨平台shader編譯了。複雜的編譯工具鏈，對我們來說不需要。我們把全部重心放在shader**的維護上，只要維護容易，多套shader也不怕。
再比如我們也不怕渲染管線的平台適配了，乙個平台一套渲染演算法。我們把全部重心放在渲染管線的快速實現上。
所以我們對生產力有著迫切的需求。starengine想要解放生產力。
對於shader，我們會有shader graph提公升shader的生產力。
對於render pipeline，我們會有render graph增強管線的可定製性。
對於場景組織與gpu資料遞交，我們想交由使用者靈活實現。
對於資源，我們想抽象出跨平台的資源描述，方便客戶端、編輯器、dcc使用。
說起來，render graph + shader graph這並不新鮮嘛，其他引擎也是這麼設計的。這裡簡單闡述下：render graph/frame graph的出現是由現代圖形api決定的。現代圖形api把資源狀態、利用情況交給了使用者決定，然而這些狀態跟蹤起來過於繁瑣以至於根本無法手動管理，所以一定會催生那麼個render graph進行統籌。這是api的內蘊屬性，所以大家的設計一定是趨同的。shader graph也是同理。但是這些演算法如何實現，各引擎的處理方式是各不相同的；如何使用，也將是各不相同的。starengine會探索其中的一條道路，這裡應該是區別於其他引擎的。
總之，starengine會對渲染引擎進行激進的重新設計：
資料驅動。連渲染框架整體，都是資料驅動的。修改渲染管線，比如從forward到deferred，一鍵發布不需要編譯引擎/客戶端。
非oop。主要模組統統靜態化，我們用更長的編譯時間換取更全面的靜態檢查、靜態多型、靜態反射，多重分發(multiple-dispatch)。完全去掉繼承結構、依賴注入、動態反射、rtti。以此簡化**結構，避免深邃難懂的繼承層次。
不抽象rhi。針對d3d12、vulkan、metal2各寫一套**，爭取做到對圖形api的全方位支援（畢竟可以硬寫）。消除使用者學習rhi的額外負擔。
編輯時決定。在編輯時決定一切（渲染）資源利用情況，預先決定好記憶體、gpu使用、執行緒排程順序。爭取在執行時做到0記憶體分配、吞吐量最大。
圖形/邏輯分離。邏輯部分只能「設定引數」，不能更改圖形流程。將圖形和邏輯開發完全解耦。
渲染引擎流程圖
大致是使用者通過各類dsl（domain specific language）描述渲染框架、shader演算法、資源利用情況。然後交給各個編譯器進行離線編譯，組合生成render bytecode。最後各平台的渲染引擎讀取bytecode並執行。所以渲染部分是不需要**參與的，可以熱更新。並且我們把引擎的設計、驗證、實現、執行進行完全解耦，以此方便修改和迭代。
注意：我們只是資料驅動（執行），做不到資料驅動（資料），有些問題暫時不好處理。比如動態大小的render target（我們是預編譯好的render pipeline資料，執行時沒法改變，只能選取大小合適的pipeline)。我們暫時不解決這個問題。
到這篇為止，starengine的基本介紹就完結啦。說實話，心裡還是沒底的，寫不出來就尷尬了。talk is cheap，show me the code！
之後的章節就開始陸續放**啦！我需要好好整理，更新進度就沒那麼快了哦。
ue4 載入材質 UE4渲染引擎模組簡介 2
ue4用新的pso caching用來替代原來的fshadercache。原來的fshadercache實現的是對shader 或二進位制的bytecode 進行cache.新的pso caching則是shadercache的超集，它不僅cache了渲染所用的shader 同時也cache了渲染狀...
UE4 虛幻引擎，預設渲染方式 PBR
預設情況下，虛幻引擎使用基於物理的渲染管線，即pbr 基於物理的渲染 管線，該管線將基於物理的材質與基於物理的光照相結合，以實現盡可能真實的渲染效果作為預設環境。預設情況下，虛幻引擎使用延遲渲染器，它會輸出每個材質的gbuffer即基礎顏色 金屬 粗糙度等，也就是所謂的 渲染目標 合成器 使用緩衝資...
UE4 虛幻4的網路適合開發什麼遊戲
使用虛幻4開發網路遊戲的兩種方式 一 虛幻4只做客戶端，伺服器端獨立開發，適用於任何網路遊戲 二 使用虛幻4同時開發客戶端和伺服器 使用虛幻4內建的伺服器 適用於一部分網路遊戲。如果使用虛幻4作為遊戲客戶端，最好也是要虛幻4的內建伺服器 這樣可以解決很多問題，同時節省很多巨大的工作量 自己開發伺服器...