Space-pompom-Technical Artist Notes

新年新的開始，祝大家都心想事成，一切順心! 今年也期許自己能夠繼續保持記錄部落格。 VAT 的全名是 Vertex Animation Texture ，是一種用來實現模型動畫效果的技術。 其基本原理是透過記錄模型頂點的變化訊息，並將這些資訊預先烘培（ bake ）到紋理中，然後在頂點著色器中讀取烘培好的紋理，從而實現模擬物理動畫等效果。 相較於即時運算實體的動畫效果，VAT是一種較為輕量級的解決方案，更 適用於行動裝置 等要較為限制性能的地方。其主要優勢之一是在運行時不需要進行複雜的物理計算，而是直接讀取烘培好的紋理，因此對手機設備性能更友善。 由於是採用烘培的方式擷取動態，因此也能做到回播的效果。重複撥放。 然而，使用VAT也帶來了一些特定的考慮和限制。由於需要記錄模型的位移和旋轉資訊到紋理中，會導致需要額外的儲存空間，並且這些位移/旋轉紋理通常不能被壓縮，以確保動畫效果的準確性和品質。 因此，相對於其他動畫技術，VAT可能會佔用更多的記憶體。需要在製作貼圖時仔細考量動畫時間長度降量減少貼圖使用，來平衡效能和效果。 下面由這張圖來大致示意一下貼圖以及模型的關係: 這邊就結合了大規模渲染必備的 GPU Instancing 方式來呈現大量石頭碎裂的的效果。(碎裂後的底圖則是借用ICON~) 附帶一提API: Graphics.DrawMeshInstanced 可以換成 Graphics.RenderMeshInstanced 可以直接使用 NativeArray ，讓往後接到 JobSystem 可以再方便一些(雖然 RenderMeshInstanced 功能感覺也還沒寫完整) References: https://storyprogramming.com/2019/09/18/shader-graph-rigid-body-animation-using-vertex-animation-textures/

對於美術朋友來說，後製的Bloom泛光需求基本上是標配的存在。而特效美術而言，也常有會希望能有限制範圍的泛光效果，而不是全屏幕的Bloom泛光。此時內建的後製Bloom就無法達成這類需求，所以就須要自己下去客製化Bloom(CustomBloom)。 這次也是基於Unity 內建渲染管線 (Built-in Render Pipeline)上來實現。在CustomBloom上可以為2個部分。 第1部分是我們需要知道特定的物件(特效)的範圍，因此可以在該效果的Shader之下再多加上一個 Pass 用來繪製遮罩部分。 第2部分則是將遮罩部分交由後製的CustomBloom的後制效果，走標準的流程( 高斯模糊 )處理，來達到特定範圍的泛光效果。 References: https://assetstore.unity.com/packages/3d/environments/3d-scifi-kit-starter-kit-92152

上傳到  Unity Asset Store 的工具也有好些日子，這陣子工具終於過審查上架了。這邊就來紀錄一下在上傳準備過程中碰到的一些事情以及介紹一下這個工具。 為了能夠上傳  Unity Asset Store 商店，首先最重要的是必須有個 Unity 的帳號。再來只需要按照官方的影片將帳號內所需要的部分填寫清楚。 How to Publish on the Unity Asset Store 等到帳號的內容準備完成之後，再來就是要準備要上傳的品項了。這時還需要去 Unity Asset Store 當中加入一個套件  Asset Store Publishing Tools 到自己的 Unity Package 當中。 再來就是用 Asset Store Publishing Tools 將商品上傳到自己的  Unity 帳號當中等待官方審核。而等待過審的時間保守來看估計要 一個多月 以上的時間才能通過。而審查後也會回覆你的品項是否通過，或是條件缺少要補圖補資料等，而我就因為宣傳圖不符合規定而被退了2次。1次是因為宣傳圖的尺寸不符，而另1次則是宣傳圖上的文字訊息過多。(當成說明文件在製作了...)而這2次往返的回覆則是挺快的，隔日就收到了通知。成功過審之後則會直接上架在 Unity Asset Store 商店當中。 FBXAnimationEditor 接下來是輪到 FBXAnimationEditor 工具的介紹。這個工具主要是用於協助 動畫師 導入FBX 的 Animation 到 Unity 。用來節省動畫師的寶貴 時間 。 導入流程中 AnimationClip 依照時間長度裁切命名好並且設定是否循環，再將 AnimationClip 從 FBX 取出(複製出來)的過程。同時也支援將動作資訊存成 文字檔(txt) 來協助導入，用來加速這些繁瑣的導入過程，對於需要時常往返調整動作檔的 動畫師 而言可以大量節省這些重複的動作以及時間。詳細可以對照下面的 流程圖 以及 影片 觀看功能以及操作流程。以下歸納工具的好處以及優點: 1. 按照時間裁切動作檔 2. 動作檔命名 3. 設置動作是否循環 4. 支援文字檔(txt)導入/轉出已經編輯過的動作資訊 5. 節省重複性的導入步驟(時間)優化工作流程 流程圖 操作流程...

  這篇來稍微實作一下深度圖的應用效果。 深度圖當中的數值介於 0~1 之間，精度通常為 32 or 16 bits，而且是非線性分佈，因此往往會需要再取到深度之後再轉一次成為線性的過程才比較方便後續使用。 這次的效果是在 Unity 內建渲染管線 (Built-in Render Pipeline)上製作。 一般來說要開啟深度圖可已在代碼當中加上 Camera.main.depthTextureMode = DepthTextureMode.Depth; 來讓攝影機取得深度圖資訊。 而這次是在 PostProcessing 效果上製作，因次需要在後製的 class 上加上 DepthTextureMode GetCameraFlags() 來讓攝影機開啟取得深度圖。 在開啟深度圖之後，所有的不透明物件(Opaque)都會多計算一次 Pass 來取得深度資訊(Z-Pre Pass)。如果有性能考量，須留意 DrawCall 是否增長過多。 如果是在URP環境，就可以使用 CopyDepth 的方式來取得不透明物件(Opaque)的深度圖。 再來便是在 void Render(PostProcessRenderContext context) 內執行相關的 shader 以及參數的設置。 由於我們希望從深度圖轉出世界座標，因此必須給予shader正確的 攝影機矩陣(Matrix4x4)資訊(傳遞目前的VP逆矩陣)。 最後則可以用後製shader得到的世界座標來做出貼地板的掃光效果。 References: https://ompuco.wordpress.com/2018/03/21/9/ https://www.jianshu.com/p/80a932d1f11e https://assetstore.unity.com/packages/3d/environments/landscapes/free-island-collection-104753 https://assetstore.unity.com/packages/3d/props/exterior/rock-and-boulders-2-6947

由於有在Cocos引擎上撰寫shader功能，但是苦於Cocos並未有良好的抓幀輔助工具。 這篇就來紀錄一下使用 RenderDoc 來在 Chrome 抓幀的功能。 1.首先可以先到 官網 上下載版本盡量用舊版本，太新的版本無法網頁抓偵，這邊使用了 RenderDoc_1.20_64 版本。 2.開啟 RenderDoc先到 Tools->Setting 內找到 Enable process injection (restart required) 開啟它。 3.在 Launch Application 找到 Executable Path ，輸入 Cocos/Chrome執行路徑(chrome.exe)，找到 Command-line Arguments ，輸入 --disable-gpu-sandbox --gpu-startup-dialog --disable-direct-composition 4.執行 Launch ，此時會跳出一個提示 Google Chrome Gpu 我們要記住上面的 pid 數字。此時先不要按下確定。  不要按下確定! 不要按下確定! 不要按下確定! 5.從 RenderDoc 左上角找到 File-> Inject into Process 執行，會出現一排數字列表，找到 pid 數字 的位置 Inject 執行，會跳到該頁面。(可以搜尋 Refresh) 6.最後回到 Google Chrome Gpu 按下確定。如果該頁面的 Capture Frame(s) Immediately 已顯示代表接成功。可以開始 Chrome 抓幀。 ps.第一次的可以先去設定系統變數，如果第一次執行需要設置環境變量 References: https://www.jianshu.com/p/85d186db6c2c https://zhuanlan.zhihu.com/p/640962813

  關於Avatar系統，相信有經歷過 MMORPG 的夥伴一定不會陌生，也可以說得上是目前眾多遊戲的一種常規系統。 這邊就寫一下基礎的 Avatar 換裝功能流程。 首先要準備的是一組主骨架，也就是包含全部所有配件都有的骨架。 接下來是依照要拆分的部位，依序拆出來，例如: 頭 / 頭髮 /上半身 /下半身 等部位，而這些部位都必須有綁上跟主骨架相對應的骨架。 再來就是建立一組 Dictionary<string, Transform> 將主骨架的資訊紀錄在內，另一組 Dictionary<int, SkinnedMeshRenderer> 則紀錄上 部位 以及所包含的 SkinnedMeshRenderer 以便之後查找替換。 最後則是製作相對應的按鈕來替換 SkinnedMeshRenderer ，以及重新綁定 SkinnedMeshRenderer.bones 等重複的流程即可。 Avatar系統並不複雜，較為繁瑣的還是在資源的準備上。或是後續要加入的骨骼以及 Dynamic Bone 等細節處理上。 專案一開始要有良好的規範骨架名稱，才能讓 Avatar運作時能正確無誤的替換。 References:  https://assetstore.unity.com/packages/3d/characters/medieval-cartoon-warriors-90079

  基於物理的渲染(Physically Based Rendering)，指的是基於真實的物理原理的 BRDF(雙向反射分佈函數) 模型 所構成的渲染方式。 PBR 的出現其實是為了能夠統一美術的製作流程而產生的一種標準化的生產方式，減少美術之間由於因為能力或者設備環境造成的差異的一種標準化模式。 或許有人會問，PBR在引擎內不是都已經有內建的，那為何還要花時間自己做一套呢? 這是由於 Unity 的標準化材質(PBR)會因為想讓使用者方便使用，所以做了很多的 Shader 開關，無形中會增加很多增加的 變體 (Variants) ，導致容量增加。 而且能客製化也代表了能夠更掌握視覺與性能部分，不會被引擎內建的PBR各種限制。增加了往後專案的可擴充性以及彈性。 關於解釋 PBR 相關的文章相信網路上的資源也是很多了，這裡對原理就不再多說明。只關注於如何實踐這部分。 對於 PBR 的 BRDF 一般可以分為4個項目。 分別為 : 直接光的 Diffuse + 直接光的 Specular + 間接光的 Diffuse  + 間接光 Specular  以下則為客製化的展示效果，以及不同引擎內客製化PBR的效果。由於是自己實現的PBR，因此可以更確保在不同引擎內有極為接近的渲染效果。使用的模型則是以前做的模型重裝騎士。