㈠ ue4先學藍圖還是代碼
先學藍圖，如果是想用代碼寫游戲的，可以先學透藍圖，因為藍圖所需要的編程思維，和其他所有面向對象的編程語言是一樣的，之後學習c++就比較簡單了。
藍圖在UE4中非常容易創建，並且更新快，編譯速度也快，可以直觀的展示流程。就實用性來說，藍圖與c++的實用性都很強，用UE4做大型游戲就用C++，做小型游戲使用藍圖就可以。
藍圖本身就是c++做成的藍圖可視化腳本，藍圖所調用的函數也是用C++寫的。但如果使用虛擬機運行，藍圖成本會非常高，並且藍圖的性能無法和c+保持一致，對於程序中較為復雜的邏輯關系，還是推薦使用C++，藍圖比較偏向圖形資源的控制上。
㈡ 使用FastBuild給UnrealEngine編譯Shader加速
提升Unreal Engine Shader編譯速度的實操指南
使用FastBuild加速編譯Shader，優化流程，從環境搭建到具體配置，詳細步驟如下：
1. 下載並安裝FastBuild
前往FastBuild官網，下載適用於Windows平台的FastBuild可執行文件，解壓後獲得FBuild.exe和FBuildWorker.exe。
2. 替換引擎目錄文件
將FBuild.exe和FBuildWorker.exe復制到``目錄下，替換現有文件。
3. 創建網路共享文件夾
創建一個網路共享文件夾，確保所有參與編譯的機器都能訪問。步驟如下圖所示。
4. 配置環境變數
在系統變數中添加`FASTBUILD_BROKERAGE_PATH`，值為創建的網路路徑。
5. 運行測試聯機環境
確認網路文件夾是否可訪問。運行`FBuildWorker.exe`，界面應顯示網路文件夾中的發起機IP，並檢查網路路徑中是否存在發起機IP的文件。
6. 開啟Shader編譯
在項目`DefaultEngine.ini`中添加配置以開啟Shader編譯。
7. 遠程機配置
將FBuild.exe和FBuildWorker.exe拷貝至遠程機，確保添加環境變數`FASTBUILD_BROKERAGE_PATH`與發起機一致。遠程機運行`FBuildWorker.exe`，確認連接成功。
8. 運行Shader編譯
打開項目Shader編譯開關，直接運行編譯Shader。如需測試，刪除`DerivedDataCache`文件夾，確保Shader編譯。
進階步驟
根據需要，調整編譯參數，限制CPU使用量，開啟編譯緩存，使用更多遠程機加速編譯。
編譯UE4項目代碼
如果需要編譯UE4項目代碼，需修改FastBuild源碼。下載源碼，配置環境變數和路徑，使用命令行編譯FastBuild，確保所有配置與編譯Shader一致。
開啟編譯代碼Cache
通過調整`BuildConfiguration.xml`文件，啟用編譯緩存，顯著提升編譯速度。
進階優化
限制本地編譯代碼的核心數，避免CPU負載過高。利用編譯緩存和更多遠程機，提高整體編譯效率。
使用FBDashboard監控
啟動FBDashboard.exe，查看編譯進度、使用資源等詳細信息，便於調整優化。
結語
通過上述實操指南，可有效利用FastBuild加速Shader及UE4項目代碼編譯。如有疑問或建議，歡迎在下方留言交流。
㈢ 不減變體，從機制優化UE Shader內存(Vulkan)
全文8000+字，多圖。
在游戲項目中，減少shader所使用的內存有多種方法，如本文將分享在UE4.26和Vulkan環境下如何通過優化shader使用機制來減少內存的經驗。
在gl語境中，「Shader內存」通常指shader program的內存，而在Vk等現代API的語境中，它可能指單獨的shader code/spirv內存，或者一切與Shader相關的對象（如shader mole，pipeline等）的內存總和。本文涉及的內存優化將涵蓋上述內容。
創建一個Pipeline需要使用多少內存？哪些是可以卸載的？首先，我們將shader code/spirv序列化到內存中，然後將其傳入VkShaderMoleCreateInfo.pCode創建VkShaderMole。創建好VkShaderMole後，傳入.mole，最後使用創建Pipeline。如果不進行釋放，內存中會有三份shader，分別在shader code，shader mole和pipeline中。
根據Vulkan的Spec，VkShaderMole創建好後，spirv中的數據可以被free掉。創建好VkPipelineCache之後，即使在使用pipeline時，其ShaderMole也可以被Destroy掉。理論上，在創建好pipeline之後以及在我們可以正確索引、使用這個pipeline的前提下，所有pipeline以外的內存都是可以釋放的。
然而UE沒有及時釋放這些用於創建pipeline的內存。下面將分析UE本身的PSO cache機制。
已有許多文章介紹PSO機制，這里簡單提幾個重要點。*.upipelinecache是PSO的描述文件，體積很小，一般在2M以內。PSO binary cache一般指vkCreateGraphicsPipelines中VkPipelineCache這個參數，這部分binary data可以在runtime中作為cache，也可以主動提取數據並保存到硬碟中。
以下是UE4 Shader的載入和創建流程圖。硬碟中的shader code由FShaderCodeArchive管理的file handle從硬碟中被讀取出來，這部分數據如果走的是preload流程，則會保存在一份在內存中，創建好FVulkanShader後被釋放；如果是在CreateShader的時候實時讀取出來的，則會使用UE自己的FMemStack來載入，並被實時釋放掉。
接下來將談談卸載掉這些用過的shader code的具體操作。
卸載前提：不影響pipeline的索引。UE的PSO cache和索引分了很多層級，其中作為Key的和FVulkanPSOKey的主要信息可以概括為ShaderHash保存在FRHIShader的成員變數Hash中，FRHIShader又被保存在FShaderLibraryInstance::RHIShaders中，獨立於shader code存在。
卸載ShaderMole：上面提到，vkCreateGraphicsPipelines返回後就可以destroy掉，而UE4不僅沒有在創建pipeline之後銷毀，甚至在pipeline釋放之後，其shader mole也沒有釋放。猜測是為了避免重復創建shader mole導致的開銷，但是shader mole本身其實是shader code外很薄的一層封裝，其創建和釋放的開銷相比pipeline的創建開銷相差幾個量級。
索引錯誤導致同樣的PSO被多次創建：筆者在開發過程中發現一個現象，明明在載入界面預編譯PSO的過程中已經把將要使用的PSO在內存中載入好了，但進入場景之後，又創建了一次這些PSO。排查之後，發現是和FVulkanPSOKey的hash函數和compare函數有問題，導致在Map中，同一個PSO有多個key（多個entry）。
卸載、不載入不必要的FShaderPreloadEntry：在material serialization時，會由GRHILazyShaderCodeLoading來決定是採取preload或者lazy load其中一種策略來載入shader code。
卸載Spirv：這一部分可以說是從機制上擠出shader內存的最後一點水分。上面提到，在game cache和user cache中的PSO預編譯結束後，理想的狀態下，內存中已經包含游戲需要的絕大部分的PSO了，又由於用於索引的信息獨立於Spirv，所以可以安全卸載。
優化全部應用後的流程圖項目大致數據分享：註：從左到右為疊加應用，而不是單一開啟一項feature。可以看到，優化很有成效。
未來可能的改進：iOS同思路優化，Shader mole的卸載時機，Spirv重載後的卸載。
一些感受：熟悉工具，迭代速度，借鑒他人解決方案的同時保持質疑，重視測試。