Latest Posts

前言 寫出一套好用好維護的程式碼相信會是所有程式設計師無意識中追求的目標，而把自己的功能包裝成Plugin是一個非常直接達成這個目的的手段，因為設計的過程會強迫把自己置更高、更抽象的位置往下俯瞰整個遊戲系統並定位出自己的功能應該在哪個位置。 只是，並不是任何的程式碼都適合放進Plugin中。因此接下來我的目的主要是想根據自己過去的經驗，分享一些自己在寫各種Plugin時的大原則。雖然這些想法不一定適用於所有的情境，應該也會有許多我沒考慮到的狀況，但基本上也就只是目前在我有限的經驗中現階段的想法。如果有人有不一樣的觀點也歡迎一起討論，或許可以碰撞出一些東西也說不定。 順帶一提，這邊的Plugin討論的主要是CodePlugin，其他類型的Plugin，例如Asset Only或BP Only，並不在接下來的討論範圍內，除非我有另外指明。 目前我在Unreal Marketplace已經有上架六項產品，內容包括Quest、Interact、Dialogue以及Tween，有興趣的可以參考： https://www.unrealengine.com/marketplace/en-US/profile/horizon-studio 另外我也會不定期的在我的FB頁面上分享一些開發日誌，通常是跟遊戲技術相關的話題，有興趣的歡迎追蹤：https://www.facebook.com/dorgonresearches 本文開始 Unreal中的程式碼我們可以非常粗爆的大致分層如下：EngineModule->EnginePlugin->GamePlugin->GameModule->GameFeaturePlugin。其中EngineModule、EnginePlugin我們頂多修修bug不可能做太大的修改；GameModule則是看專案團隊的風格會有不同的構成方式，我們等一下再回來聊這部份；而GamePlugin跟GameFeaturePlugin則是我們接下來要討論的重點。 EnginePlugin 、GamePlugin相對直觀，大家應該不會有什麼疑惑，但GameFeaturePlugin這個概念或許就有人沒聽過了。這個功能是5.0所引入的最大變革之一，對程式相關職能的人而言，特別是寫Gameplay相關的，我覺得其重要性甚至更勝於Nanite跟Lumen，因為相關機制會從根本性上的改變了我們程式碼的架構方式以及思考模式。 就設計理念看來，他是屬於DLC概念的實現，跟Patch不同，Patch需要蓋掉原本的內容，而DLC必須要做到「熱插拔」的機制。 就傳統UE4 project，我們要達到DLC的這項要求非常麻煩，因為我們只能對「Content-Only」plugin包出dlc包，而哪些dlc需要開啟或關閉則需要你在BaseGame中做出一些可以管理的設計。在GameFeature Plugin 機制出現後，我們總算不需要做這些勞力活了。注：這邊的BaseGame指的是 ${PROJECT_ROOT}/Source 下面所有的Runtime GameModule以及${PROJECT_ROOT}/Content下面所有會打包進去的Asset。 有些人會困惑於我們建出的 GameFeature Plugin 沒辦法跨專案共用，但這個理解並沒有錯，基本上GameFeature Plugin需要依賴於BaseGame而存在，因此我們也可以理解成他是專屬於project的Plugin。若你的功能想要跨專案共用，你要寫的是一般的GamePlugin而不是GameFeature。 在理解了GamePlugin跟GameFeaturePlugin的不同點之後，讓我們先來思考一下，Plugin到底是什麼？就字面上來看的話，形象一點解釋，他就像是一個插頭，把這個插頭插進我們的專案之後就能夠提供各種我們遊戲專案會需要的功能。雖然Plugin不像DLC需要做到「熱插拔」，但大家期望的是功能的插入跟移除是相對簡單的。因此每個GamePlugin在設計上要能做到獨立運作，也就是說在設計上只能依賴於Engine或EnginePlugin，依賴於其他同層級的GamePlugin會明顯造成遊戲專案的使用障礙。移除簡不簡單這件事取決定Plugin的功能與細部設計這邊先不展開討論，但對於功能的插入而言，應該沒有人會希望開啟某個Plugin前還需要去閱讀文件看清楚有哪些相依Plugin需要下載吧？若我們設計的Plugin有依賴於其他同層級的GamePlugin的情形發生，可能要思考看看哪些功能要下放到GameModule給專案自己實作，哪些功能需要整合進同一個GamePlugin中。 由上面的討論我們知道，Plugin在本質上就是對於能獨立運作功能的封裝，而這些功能來自於各種需求各異的不同專案，因此Plugin在設計上必須要放在一個更抽象的位置以滿足不同專案的需求。因此我不建議在Plugin中實現任何的框架機制，因為那個是Engine該做的事；若只是薄薄一層的實作，主要目的只是更改某些Engine的預設設定的話，那個則是專案GameModule該做的事，我們不該假設我們的設定會比Engine的預設更通用；若是覺得Engine的某些Function實作有bug或不夠完美，所以想繼承下來做override來做workaround，那個也是專案該做的事，我們可以寫一些文檔分享給其他團隊說明為什麼我們想做這些修改，而不是寫成某個Plugin要求大家先繼承某個class再做某些事，因為那不一定適用於所有的專案，再次強調，我們不該假設我們的實作會比Engine的實作更具有通用性，若你覺得你的目的是修掉Engine Bug，你該做的是上Github送PullRequest給Engine。 那麼到底什麼東西適合寫成一個Plugin，最好的判斷方法是：先假設把這個Plugin拿到UnrealMarketplace上賣時，我們是否能夠明確的指出這個Plugin想解決的是什麼問題？受眾是誰、有多少人可能會需要這個功能……等等類似的問題，若無法回答這些問題，代表相關功能的想法還不夠成熟，建議先拉回GameModule中等待各種需求的磨練。 那麼在把功能寫在GameModule時我們該注意什麼呢？就我所知，根據專案團隊的風格會有不同的構成方式，有人喜歡使用一個大module放入所有的功能、也有人喜歡依功能的性質導入一些模組化的設計，但不可否認的是，由於這邊的程式碼非常接近Gameplay、更迭會非常快速，有可能一個遊戲企畫的改變導致某個系統在瞬間變成一個沒用的東西。基於這種變動頻繁的特性，因此有些人會覺得不需要在GameModule的層級上浪費時間進行遊戲邏輯的模組化設計，反正就是想辦法用最快的方法將功能做出來，不要因為模組化而導入的各種限制而拖慢了組裝系統的時間。不過我自己倒是有不同的觀點，在GameModule這個層級做模組化反而是我們用來對抗變化的手段，良好的模組化設計應當要考慮到當你想把某個功能移除時需要耗費多少的力氣，理想狀況是直接把該Module移除就行，不過這部份就屬於不同系統的實作細節了，就不再往下討論。除此之外，我認為模組化的練習可以幫助我們慢慢的把相對不成熟的想法粹練出來。我們不需要一開始就用Plugin的高度在思考問題，在個人經驗不足或需求還不明確的情況下很容易陷入寸入難行的地步；相對的在GameModule層級進行設計的話，我們可以先以更貼近專案的需求的方式來思考怎麼進行抽象化的設計。 結論 以上寫了這麼多，大致下可以簡單用以下幾點描述：     1. 每個GamePlugin在設計上要能做到獨立運作，也就是說在設計上只能依賴於Engine或EnginePlugin。     2. 不建議在Plugin中實現任何的框架機制，因為那個是Engine該做的事，不該假設我們的設定會比Engine的預設更通用。 … Continued

這篇文章主要是要記錄自己怎麼把Mixamo中的動畫導出來給Unreal中的Mannequin用，以及除何修正中途遇到的一些坑。 使用版本：5.1 使用的是Third Person Template 第一步當然是先從Mixamo下載看中想使用的動畫。 由於Mixamo的骨架跟Unreal不相容，主要原因Mixamo是少了一個root，這會造成root motion沒辦法正常運作。我們可以下載 mixamo_convert這個Blender Addons來幫我們加上一個root bone。 如下圖，右邊加上root的是我們希望的狀態： 這邊要注意的是，Blender Addons的安裝要使用zip才認的到。 https://github.com/enziop/mixamo_converter 下載完zip之後，從preference選Add-ons安裝，然後把功能打開 接著從右上方打開選單 可以看到Mixamo Rootbaker 可以選擇把bone轉成UnrealEngine公版的bone Name，但我這邊不勾，之後自己再使用UE內建的IK Rig以及IK Retargeter來做map，詳細步驟後面會記錄。另外他的OutputPath目錄不會自己建，所以要自己先開： 之後我們就可以先匯入轉換過後的Mixamo的模型(X Bot.fbx) 接著匯入其他的動畫，記得Import Mesh勾掉，Skeleton選擇剛剛匯入的。 然後就可以開始建立IK Rig，這個檔案的目的是建出組Bone Chain，讓我們可以可以在IK Retargeter中指定Source IK Rig跟Target IK Rig做map。 Source就是剛剛匯進來的Mixamo，我們必須要手動建一個出來(右鍵Animation -> IK Rig 下可以找到)，Target則是Unreal內建的Mannequin，路徑是/Game/Characters/Mannequins/Rigs/IK_Mannequin。 … Continued

SIMD(Single Instruction Multiple Data)指的是用一個指令同時處理多個資料這個概念，只是我們常常被誤導說，在CPU上可以使用SIMD指令來加速──這種說法其實並不精確。對，我就是被誤導的那個。在UE4.23時官方整合了ISPC，以更好的幫助CPU做平行化加速，我之前一直把這東西跟SIMD畫上等號，沒去仔細思考這東西的存在到底想解決什麼問題。 根據指令數跟跟資料的處理方式，這個概念其實是根據Flynn’s Taxonomy來進行分類，而SIMD只是其中一種。 SIMD就現行的計算機架構上，分為以下三種： 不過由於Vector Architecture在商業競爭上輸給了Intel因此逐漸式微，以Scalar Processor為主的設計主宰了過去將近30~40年的時間。輸掉的原因有很多，但主要並不是技術問題，而是那個時代大部份的人不需要那麼強的計算力，客戶太少，再加上摩爾定律的推波助瀾下，人們的注意力自然就只集中在由Intel主推擁有最多客戶的架構上。然而近來由於AI時代的來臨，Vector Architecture架構又重新回到了人們眼界中了，例如google tensor裡面的TPU就包含了Vector processor，以及最近很火紅的RISC-V，由於設想目標是embedded devices，不像個人電腦需要考慮兼容性，因此可以大膽的拋棄舊包袱，轉而使用相關的Vector Operation指令。 另一方面，關於Multimedia SIMD，主要是由於Intel在網路起飛的時代發現我們基於Scalar Processor的架構還是需要Vector Architecture那種一個指令同時處理多個資料的加速能力，因此他的解決方式非常粗暴，就是加入新的register跟指令集的方式來支援這個概念。不過當我們開始疊加register跟指令集之後就開始失控了，每我們加一組新的register，我們就要追加一堆新的指令集來支援相關Vector操作，從XMM(128 bit)、YMM(256 bit)到ZMM(512 bit)。這些指令集的擴充非常快速，從1996年開始，幾乎每2~3年就有新的特性加入，然而為了兼容性，新的指令集在加入x86系統後就非常難被移除，因此現代指令集暴增的這麼快速有很大的原因可以歸究於Multimedia SIMD的發展。 接下來讓我們來稍微看一下這些擴充指令集，感受一下它發展的混亂吧：從1996年的MMX，它總共有57條擴充指令使用，到SSE又追加了70條，接著SSE2加入了144條指令，而SSE3只是在原有架構下的擴充，所以只追加了13條指令。接下來則是SSE4.1跟4.2，又分別加入了47條跟7條。前面的架構使用到的是XMM register，接下來為了增加平行化的數量，Intel推出了AVX系列，使用的是YMM register，然後又更進一步的推出了AVX-512，使用ZMM register。可惜的是我目前沒找到AVX的指令集數量，不過我猜應該有上百個。問了一下AI，他是跟我說要看所使用的具體版本。 對於最新的AVX512，Linus Torvalds在2020年的時曾經破口大罵說：我希望AVX-512可以死的痛苦一點(I hope AVX512 dies a painful death)。希望intel不要靠增加魔法指令來讓跑分好看，要他們回到正軌。 基本上這玩意耗能大，大部份的人享受不到好處，又不是什麼科研計算，也不是server，一般人在使用電腦的時候又常常需要切換process執行，這代表作業系統會不斷的進行Context Switch，要知道，每次Context Switch是需要把當前計算用到的register保存下來，在這一讀一寫之間很容易讓使用者感受到延遲，而且還多佔了空間。 另外在Intel 12th … Continued