ue4用新的pso caching用來替代原來的fshadercache。原來的fshadercache實現的是對shader**（或二進位制的bytecode)進行cache.新的pso caching則是shadercache的超集，它不僅cache了渲染所用的shader**，同時也cache了渲染狀態.pso caching的設計在很大程度是貼合了新的渲染api的方向，向vulkan的pipeline cache致敬
pso caching會把渲染狀態、頂點宣告、primitive型別、rendertarget畫素格式等等的資料儲存到檔案中，或是從檔案中載入它們——因為這些渲染狀態數字類資料大都是一系列的int或列舉類資料，空間大小占用有限，故沒有做額外的處理。
但pso caching中不會直接儲存shader**（不管是源**或是編譯好的二進位制shader)，也不儲存shader的路徑，它儲存的是shader路徑的sha1 hash做為shader唯一的索引，真正的shader是由fshadercodelibrary管理。
lightmass模組是ue4的烘焙渲染器，是乙個單獨的可執行檔案。它工作在cpu上而非gpu上，配合ue自帶的swarm agent和swarm coordinate實用程式，lightmass還能實現分布式的烘焙。除了光照圖，還烘焙陰影、ao，bentnormal、可見性、mesh距離場等等。
相對於暴力path tracing來說，lightmass是有偏的。
lightmass中的光子被存在八叉樹中，jensen實現是基於陣列的kd-tree。
一整個場景中參與投影的mesh在lightmass裡會被組織為乙個碩大的mesh，再使用kd-tree對其進行劃分以加速ray cast求交。ue4有實現一套自己的mesh kd-tree構建，但它預設的並不使用自己的這份kd-tree,而是用的intel的embree庫來表達場景快速求交。
lightmass對幾何體的光柵化是基於平底三角形拆分進行光柵化。
ue4烘焙的基本工作流程
ue4目前支援3種渲染路徑：移動端簡單的forward render path,pc/主機端的deffered render path和forward+。在framegraph尚未完善情況下，每種渲染器對應的渲染pass是人肉組裝的。
ue4用於組織渲染路徑實現h/cpp檔案的字尾均為renderer,每個renderer均由數個渲染pass順序級聯而成，對於具體每個pass的渲染實現和某個單獨的功能性的渲染實現，ue4中的h/cpp檔案字尾則是rendering，如fogrendering,depthrendering等等
renderer的基類是fscenerenderer,當你想實現乙個自己的渲染路徑時，它的核心介面只有乙個：
雖然該介面名為render，但實際上它的工作不止是渲染，它同時負責了更新部分資料、裁剪、遮擋剔除，組織渲染指令等工作。這就容易在和gpu進行渲染指令同步時出現斷供和積壓的情況，為了應對渲染執行緒在幹這些髒活累活時的所帶來的額外延遲，ue4一方面盡可能的把一些耗時大且可並行的任務扔到執行緒裡去實現（如可見性計算，生成渲染指令），另外一方面還專門針對gpu同步的提交實現了乙個rhi執行緒。
ue4渲染資料和命令組織、可視性計算是通過initviews函式實現的，這不是fscenerenderer的介面，但是fscenerenderer的兩個子類均有乙個一樣功能實現。
fdeferredshadingscenerenderer用於其它非移動平台。它內部的實現是同時整合了延遲渲染和forward+。在4.23開發版本中還看到有實現單獨的deffered cluster pass。關於deffered shading renderer具體的渲染過程，每個pass的功能分析，網上資料較為詳實可觀了。
ue4中用於移動端的渲染器叫fmobilescenerenderer，它實現了乙個傳統的forward renderer。mobilerendeer最核心的pass是mobilebasepass ,它的具體實現分兩部分，cpu端的資料組織，shader及其permutation管理在mobilebasepassrendering.h/cpp中，shader本身的實現則在mobilebasepassvertexshader.usf和mobilebasepasspixelshader.usf中。ue4的shader permutation是基於pass和預編譯巨集來組合的，mobilebasepasspixelshader.usf也不利外，它實現了乙個mesh著色的基本過程：從光照圖、shadowmap取樣和計算、反射球取樣、天光、到實時燈光、fog混合等。在硬體支援的前提下，它還基於frame buffer fetch實現了alpha blend。
ue4同時支援硬體遮擋剔除和軟體遮擋剔除，只是它的軟體遮擋剔除目前僅用於es2相關的裝置。
ue4 render path的實現包含在「renderer」這一模組中。
在batch和instancing這兩項減少drawcall的技術方案選型上，和u3d不同，ue4選的是instancing，所以ue4的batch功能是比較弱的，你在場景中放100個一模一樣的box,在沒有instancing時，它就是100個drawcall。
uinstancedstaticmeshcomponent(ism)，靜態的模型instance,即我們在書上和其它引擎中最常見的instance形式——只有位置相異而mesh和材質均完全相同的物體可以合併成乙個actor，在理想情況下只提交一次drawcall。ism好處是drawcall少，壞處是lod計算，裁剪和oc等等都是按乙個物件來做，往往ism的drawcall減少了，但提交渲染的三角形卻更多了。
uhierarchicalinstancedstaticmeshcomponent(hism),ue4中的hism和ism不同之處是它是基於分層實現。目的是為了滿足乙個mesh有大量例項時分區域進行裁剪、計算lod。ue中的植被就是hism的子類。看到hism大量的console variable都直接叫foliage***...可以猜到的是hism大概一開始是為植被系統所準備的。hism的實現有兩部分，一部分是構建分層（自動化的，每次修改它的instance個數、位置等都會觸發）並儲存到檔案中，另一部分則是基於分層的可見性計算、lod和渲染組織。
hism的分層結構是乙個kd-tree，不過它的生成不是基於啟發式平衡的結構去做，而是直接用的最長軸做為當前拆分軸，且簡單粗暴的從長軸中間分開成左右子樹，葉節點所包含的instance數或三角形數由外部控制。
dynamic instance，ue4在4.22中支援的dynamic instance和上述的ism/hism雖同為instancing，但實現上是完全不相關的。ism/hism的實現是靜態的，需要顯示的在場景中對相同物件強制打包到乙個primitivecomponent下面，屬於編輯階段需要確定的資料組織功能。而dynamic instancing則是在渲染指令組織的時候，發現相同的mesh+pipeline state自動組裝的。dynamic instance實現的核心是ue4實現了乙個gpu scene——用乙個buffer來儲存全場景每個primitive的transform等資訊，這樣在組裝出instance buffer之後只需用primitiveid就可以訪問到自己的位置相關資料，從而實現instance渲染了。
dynmic instance在4.22上的移動端沒有實現，但其實只要稍微修改一下ue4使用的rwstructurebuffer為rwbuffer,並且把gpu scene相關的檢測和更新修正，就可以在手機端es3.1 feature上正常使用。
gpu scene的實現可以參考gpuscene.h/cpp。
渲染模組的簡介到這兒就基本結束了，光照的介紹、raytracer的介紹、渲染執行緒之間的分工和互動、shader生成和組織過程、mesh渲染的流程、lod更迭、hlod、streamingtexture等等主題。這些主題因為涉及到具體的演算法和**實現，放到單獨文章裡去介紹會更容易理解。
ue4玻璃材質 UE4 材質
本文中，我們將首先討論基於物理的渲染，什麼是材質域，什麼是材質，什麼是材質例項，什麼是主材質，我們將討論材質的一些建議和禁忌。最後，我們將了解一些材質概念，你可以將其用於各類專案中的材質。pbr 表示基於物理的渲染，基於物理的渲染意味著我們根據現實模擬光線，而不是根據主觀想法模擬光線。光線的最終效果...
ue4材質節點大全 UE4 材質
凹凸貼圖偏移 bumpoffset 是虛幻引擎4術語，就是通常所謂的 視差貼圖 bumpoffset表示式可以使材質產生深度錯覺，而不需要額外的幾何體。深度資訊。高度貼圖的值越亮，材質的 凸出 效果越明顯 當攝像機在表面上移動時，這些區域將產生視差 位移 較遠 其位移程度最小。在不改變原有模型面數的...
UE4 材質 紋理
pbr材質基本上是以下幾張紋理的 融合 1.基本顏色 2.normal 法線資訊，體現凹凸感 3.ao 環境光遮蔽 表面光線的遮蔽效果 4.roughness 粗糙度 5.metal 金屬度 關於尺寸，一般都是1 1，且是2的n次冪。注意 可以不是1 1，但長寬一定要是2的n次冪。原因 因為ue4使...