UnrealEngine

花了一些時間把EpicChina在2022台北遊戲開發者論壇的演講看完並做了一些筆記。 題目是關於UE5中的渲染技術。 只是看完影片後覺得資訊量太多，腦袋呈現完全爆炸狀態……然後影片結尾聽到講者說這只是很粗淺的介紹後我就崩潰了。 雖然以下筆記很多內容我都還有點消化不良而且可能也有理解錯誤的地方，但不管怎麼樣先分享出來給需要的人。 想更進一步知道細節的推薦大家去看演講，不能只有我崩潰。 https://www.twitch.tv/videos/1533064361 1:54:37秒 開始 1. 在nanite中大小三角形會分別用軟硬體做，大的用硬體做，小的為了避開overshading的問題，他自己用compute shader寫了rasterization。為什麼呢？在三角型在算pixel的顏色時，由於頂點不會剛好在pixel的中間，因此他必須相鄰的4個pixel拉進來，用一個Quad為單位來考慮。當你的三角型很小而且緊密時，某些pixel會一直反覆被拉進去做計算，這情況稱之為Overshading或者是Quad OverDraw。而Nanite為了解決這個問題，因此大的三角型雖然還是靠硬體做，但小的三角型則是自己用軟體做，在Compute Shader中寫rasterization。小的三角型有一些條件需要達成才會被歸類為小三角型。 2. 整套技術的重點在Cluster生成、Culling跟LOD的選擇，為了高效的達成Culling跟LOD的選擇，引擎從4.22開始就把整個render底層換成retained mode，就是說讓GPU去維護整個場景render object的一些狀態。 這邊是GDC2019演講。 3. LOD的生成機制，其實就是先做graph partition演算法做cluster分組，然後不斷的遞迴減半面數，最終生成一個DAG(Directed Acyclic Graph)。Graph partition的分群的給定條件是共享的邊盡可能的少，面積盡可能的均勻。這出來的結果是每下一級LOD都會是最小的變化，也就是說外觀的變化最小。而衡量外觀變化的標準就是使用QEM(Quadric error metric)。 4. QEM這個衡量標準可以保證我們減面後的error會越來越大，從DAG的Root到Leaf Node，記錄在節點中的error值可以幫助我們做LOD的選擇。 5. 每個Cluster的BoundingBox都會再各別對每級的LOD個別生成BVH(BoudingVolumeHierarchy)後，再掛到一個大的BVH root下面，因為這樣gpu的入口會比較一致。每4個Cluster會組成一個cluster group，最終這個nanite模型會是一個cluster的BVH結構。 6. Culling會利用分群後的資訊進行，經過以下步驟： — a. Instance Culling：用上一個frame的HZB做跟BoundingBox來做剔除，得到一個粗略的可能還可見對象的instance。— b. … Continued

關於Plugin的官方介紹： https://docs.unrealengine.com/5.0/en-US/common-ui-plugin-for-advanced-user-interfaces-in-unreal-engine/ 本篇文章主要是記錄目前我在CommonUI plugin中所看到的一些東西，可能分析的不是很完整，但就是一個簡單的筆記。 版本：Unreal 5.0.3 目前plugin裡面主要有以下幾個功能： 各別平台的Input以及 Icon Mapping：例如xbox跟switch的A跟B是相反的，他有機制處理輸入跟icon的對應。 Styling: 例如CommonText可以做一個Style BP給大家用，之後調整遊戲文字就只需要調該style BP就行了 從GameViewportClient上做Input Rereroute，根據目前是ECommonInputMode::Menu、Game或All決定裡面的行為。在功能面上看起來跟InputMode在機制上類似，Menu對應UIOnly、Game對應GameOnly而All對應GameAndUI，不確定之後官方會想怎麼發展。 UI Manager的機制。 我自己看是覺得整套機制還不是很成熟，在使用上你會覺得缺少很多細節的實作。不過也對，他現在是放在experimental plugin下面，要使用在production上要有心理準備自己需要去補完很多缺少的實作。 關於UI Manager，他實現的機制比較特別，我自己的Plugin是用Actor，但他是拿你第一個AddToViewport的主Widget來當管理器，這時候你會需要在這個Widget上再刻一套需要的功能介面好讓其他系統呼叫。 整套機制主要分為2個元素構成： Widget Container容器：分為UCommonActivatableWidgetStack跟UCommonActivatableWidgetQueue，分別可以進行push跟pop操作，這二個容器的差別在於我們的設計是先進先出或後進先出。我們可以有多個Stack分別對應不同的需求，在Lyra中他是把Game跟Popup Modal拆成二個stack ActivatableWidget：他是一個UserWidget，我們需要繼承下來進行設計的各種UI頁面，用來push進Widget Container的元素。。 他Push跟Pop時內建transition動畫，但他動畫效果是寫死在code中，而不是去呼叫UMG上的動畫，所以不是很符合實際產品製作的需求。內建的Transition動畫效果有：FadeOnly、Horizontal、Vertical、Zoom (ECommonSwitcherTransition)。 由於我以前有解決過UI Manager相關的問題，因此就再來多來聊聊我Plugin的設計思路吧。 以下是我Plugin的連結： Horizon Framework 這個Plugin當初設計的目的是想要做一套通用的遊戲框架(GameFramework)，並做為HorizonDialogue擴建的基礎。只是做到後來發現通用框架難以在一個Plugin裡面實現出來，所以目前就變成了專注在UIManager相關的功能上面。 我的UI管理器做叫HorizonSceneManager，而用來進行Push跟Pop的元素叫做HorizonScene，Scene這個名稱是借鏡於cocos2d，他們都繼承自Actor，因此都會在World上生成一份實體。HorizonScene是用來封裝UserWidget，因此我們在設計完UserWidget之後，需要另外創建一份BP繼承自HorizonScene，並把UserWidget的Class指派進Scene的參數中。如下圖： SceneManager裡面有一份SceneStack跟SceneEventList，裡面有設計一系統的API讓我們可以針對SceneStack進行操作，幾個重要的API為：ChangeScene、PushScene、PopScene、RemoveScene。這幾個Function會建立對應的SceneEvent放進SceneEventList中，SceneManager會在每個Tick的時候逐一拿出來執行，並在適當的時機點通知SceneManager，並把Scene加入進SceneStack中、呼叫對應的delegate通知使用者實作需要的遊戲邏輯。 每個Scene主要會經過以下幾個生命週期： Enter：視是不是處於VR模式決定初始化Widget的方式，並呼叫StartTransIn。 … Continued

分享一下之前專案遇到的一個打包速度優化手段。 之前專案在打包的時候，最後一定出現Waiting for child processes to complete(0/1)這個訊息，當專案越變越大之後，很明顯的卡在這一步的時間變長了。追了一下code，發現他是在做把東西打包進pak的動作，每一個pak只會開一條thread處理，而訊息中的(0/1)，則表示了我們把所有的內容塞進了同一個pak中(completed/numPak)；也就是說若我們沒有啟用Chunk機制的話 (見：https://docs.unrealengine.com/4.27/en-US/SharingAndReleasing/Patching/GeneralPatching/CookingAndChunking/ )，這邊會浪費不少時間在做單核cpu的等待，之前試過，隨便分個8個chunk，就讓整體打包時間加快大約20分鐘左右。 通常會關注到chunk議題，很多時候是因為在做手遊時需要去分第一包跟做patch；但其實分chunk之後帶來的好處還蠻多的，除了打包速度加快之外，我們還可以利用UAssetManager來做Preload相關的機制。 關於打包的細節有興趣可以去看UnrealEngine\Engine\Source\Programs\AutomationTool\Scripts\CopyBuildToStagingDirectory.Automation.cs中的RunUnrealPakInParallel這個function。

UsageFlag文檔：https://docs.unrealengine.com/4.27/en-US/RenderingAndGraphics/Materials/MaterialProperties/ ShadingModel文檔： https://docs.unrealengine.com/4.27/en-US/RenderingAndGraphics/Materials/MaterialProperties/LightingModels/ 本文章是基於4.27 之前有空想要比對一下mobile pass跟SM5 pass到底差在哪裡。有發現在windows editor中，只有SM5跟ES3二種，就算是選了蘋果icon也不是真的metal，真正的metal shader code只能在mac環境下編譯出來。 在追code的過程中相關些名詞一直出現，引起了我的好奇，因此決定仔細研究一下。想要追shader相關的程式碼，這幾個ini參數最好設一下會比較好debug： 在material上有usage跟shading model的選項，usage主要的用途是用來決定哪些shader組合是不是要compile permutation；ShadingModel主要是用來決定計算光源貢獻時要走哪條IntegrateBxDF的路。 在Unreal中shader code的generation主要是靠C++ Template的機制來大量產生各種組合(permutation)，其中可以看到引擎大量的使用Policy-Based Design。我們知道template的機制是compile time產code，所以我們只要有n個base shader，再加上m種policy的話，我們就可以產生n*m種組合。 每個Policy都會實作ShouldCompilePermutation跟ModifyCompilationEnvironment這二個function；前者搭配Usage使用，替BaseShaderType決定要搭配哪些Policy組合的編譯，例如，NoLightMapPolicy，接著實作會呼叫ModifyCompilationEnvironment，他會替Shader加macro，決定某段shader code要不要留下來。 以bIsUsedWithStaticLighting為例，若該usage有勾選的話，在跑IMPLEMENT_SHADER_TYPE時，其相關連到一組的BasePassVertexShader.usf、BasePassTessellationShaders.usf以及BasePassPixelShader.usf(Vertex Shader, Hull and Domain Shader, Pixel Shader)就會被用搭配到的TLightMapPolicy建立出來。 例如在${PROJECT_ROOT}/Saved/ShaderDebugInfo/PCD3D_SM5/AmbientOcclusion/FLocalVertexFactory可以看到類似於下面中的資料夾。其中產生的permutation shader code，針對BasePassVertexShader.usf，產生NoLightMapPolicy以及NoLightMapPolicyAtmosphericFog這二組；針對BasePassPixelShader.usf，則產生了FNoLightMapPolicy跟FNoLightMapPolicySkylight。 這些Policy主要的功能是用來ModifyCompilationEnvironment，替shader code加入需要的macro define，之後每個permutation就會利用mcpp這個preprocess來幫我們濾掉不需要code，並把所有include到的shader結合成一個大檔之後，產生特製的shader code出來。 另外Usage除了決定permutation要不要產生出來外，有一些還會用來附加一些macro進shader中，例如OutEnvironment.SetDefine(TEXT(“USES_DISTORTION”), Material->IsDistorted()); 有發現Usage雖然有八成左右的功能都只是用來決定編譯組合；ShadingModel主要是用來決定計算光源貢獻的做法。但有看到有少部份會直接去加shader … Continued

之前在debug android的時候，有發現一開始的黑畫面特別久，特別在用Visual Studio attach debuger的時候，基本上第一畫面完全跑不出來。好奇追了一下，發現了整個流程是卡在VerifyGlobalShaders這個function上，仔細看了裡面，發現在package build的時候他完全沒做任何事，就只是把所有的shader的permutation撈出來for loop跑過一輪檢查而已，這個foreach的執行次數在4.27有8萬多個(85610)，看起來非常浪費計算量，就算是跳過也不會影響後面的功能，說不定跳過之後能夠省個幾秒鐘的黑畫面時間。試了一下，這個想法是對的，跳過之後確實後面的畫面也能夠正常顯示出來，讓我的debugger能夠順利的往後執行。 但這時候我就好奇了，為什麼引擎要放一個明顯無用的ForLoop在那裡？這段code通常只會在Development build執行吧？為什麼連Shipping build也要跑？把他跳過之後我們能夠省下多少時間？ 為了驗證這個更動能夠帶來更好的遊戲體驗，因此我決定計時看看跳過VerifyGlobalShaders 跟原本不跳過的版本差異在哪。使用的版本是Test並啟用了PGO優化。 但是，結果讓我非常的震驚，數據如下。 機型：Galaxy S21 5G SM-G9910   Skip NoSkip 第一次開啟 12.52秒 7.9秒 第二次開啟 1.87秒 1.66秒 機型：Galaxy S21 ultra 5G   Skip NoSkip 第一次開啟 10.28秒 7.98秒 第二次開啟 2.13秒 1.71秒 這個驚人反直覺的結果，讓我開始思考到底發生了什麼事。為什麼跳過無用的Loop，其執行結果反而比沒跳過的慢？這之間是不是有什麼硬體上的預熱效果在裡頭發揮了作用？思考到這裡，我突然想到，所有的CPU都有所謂的L1、L2 … Continued

這幾天花了一此時間研究了nuget的佈署方式，主要的目的，便是要讓大家在還真的購買plugin之前，有個機會先能夠在editor中進行試用。 雖然perforce使用者有[UGS](https://docs.unrealengine.com/en-us/Programming/Deployment/Unreal-Game-Sync/Unreal-Game-Sync-Overview)可以用，但由於跟perforce綁定，對於習慣於用git的自己而言還是要去思考別的替代方案。 另外，nuget好處是，開放給大家的部份可以發到nuget.org上，如果公司內部要私用的話，也是可以自己架一個nuget server或者是直接弄一個local feed在NAS上，就使用彈性而言，我個人覺得比UGS來得高。 目前我正在開發的幾個plugin都也已經發佈到nuget.org開發大家下載了，有興趣的人可以試試看，使用方法跟步驟已經記錄在對應的Github頁面中了。 plugin marketplace: https://www.unrealengine.com/marketplace/profile/horizon-studioGithub專案連結：https://github.com/dorgonman/HorizonUIPluginDemohttps://github.com/dorgonman/HorizonTweenDemohttps://github.com/dorgonman/HorizonFrameworkDemohttps://github.com/dorgonman/HorizonVRDemohttps://github.com/dorgonman/HorizonDialogueDemo 另外由於我這幾個專案都有進Azure Devops的build pipeline了，理論上只要我這邊有任何更新，都會自動發佈到nuget.org上。