Blueprints In-depth - Part 1
Unreal 官方公佈了兩個有關blueprint的深度介紹的影片
Blueprints In-depth - Part 1 | Unreal Fest Europe 2019 | Unreal Engine
https://www.youtube.com/watch?v=j6mskTgL7kU
Blueprints In-depth - Part 2 | Unreal Fest Europe 2019 | Unreal Engine
https://www.youtube.com/watch?v=0YMS2wnykbc
投影片
https://epicgames.ent.box.com/s/hdv4bye3dezabp4duq8pttsha8kjjlde
這篇文章算是摘錄Part 1的一些重點出來~
https://youtu.be/j6mskTgL7kU?t=88
學習BP是很容易，就像畫流程圖一樣。
BP的UI介面其實跟程式的.h以及.cpp是很類似的，所以也容易理解。
使用BP很簡單，但是重點在於如何"正確"使用
如何讓BP盡可能的簡潔
如果有人要接手我的工作，怎麼樣才好理解我寫的BP
在作BP的時候有沒有一併考慮記憶體以及效能相關的問題
有沒有考慮到這個BP未來如果會擴張的情況
https://youtu.be/j6mskTgL7kU?t=752
以一個門作為範例
首先一開始一定都是很簡單一個靠近就會開門的BP
之後隨著需求增加了好幾個門的BP，每個功能都有些微的不同。
然後把有相同的部分往上抽了底層，base BP class BP_EnvironmentObject。
隨著複雜度提升，還繼續往C++層抽，把複雜的功能放進C++。
但是可能玩家會去開門，所以玩家會跟門有關，開門的時候會跟動作有關，所以玩家的動畫BP也會跟門有關。
為了提示門可以開，所以HUD也來跟門參一腳了
可能有開門相關的獎盃，所以獎盃也來攪和。
槍可能可以把門打穿，所以....
以上就是一個從一個簡單的BP到整個複雜專案的情況。
https://youtu.be/j6mskTgL7kU?t=1088
BP比C++慢，但有的時候效能問題的主因不一定是BP造成的
有很多BP轉C++的目的不一定是為了改善效能
不過錯誤的使用BP有可能造成嚴重的效能問題
BP比C++慢10倍，不過實際上還是要根據不同的情況才能算數。
BP效能不好的幾個原因
https://youtu.be/j6mskTgL7kU?t=1133
1. 太多的節點互相連接
2. 數學運算或是複雜的邏輯運算作在BP是昂貴的。
3. 在BP使用迴圈是昂貴的
4. 在BP巡訪大量的actors/classes是昂貴的
5. 在BP處理Tick的行為是昂貴的，也是BP造成效能不好的主因之一
BP的效能根據不同的執行方式：
編輯器執行(Play In Editor)、Development、Shipping
是有很大的差異的
https://youtu.be/j6mskTgL7kU?t=1303
造成BP效能問題的主因之一就是Tick
這裡的Tick指的是廣泛的Tick，例如BP裡面的Tick，AnimBP的UpdateAnimation，UMG裡面的binding
大部分的情況你不需要使用Tick，甚至於可以關掉Tick。
例如使用Timer，使用事件控制，或是只在某些條件成立的時候才執行Tick，或是距離近/玩家面向此Actor的時候才Tick等等
有些時候也可以透過material來處理BP要做的事情，
BP的除錯介面很方便，從圖中就可以知道現在正在執行那些節點，也可以透過Filter功能只看某一個想關注的actor
透過watch介面也可以即時的看到變數值
Visual Logger功能也是很好的除錯對象，在BP內也可以使用，不管是寫一串文字，畫一個sphere，capsule，一個區段等等。
在Editor可以直接叫起Visual Logger並且錄製除錯資訊。
console command stat game可以快速地看到BP的效能資訊
console command dumpticks可以把當下所有有tick的actor資訊寫進outputlog內，可以仔細的觀察有多少actor在tick。
UE4內建的profiller還是最詳細的工具，裡面可以列出哪個Actor的哪個函式占用多少CPU時間。
BP也可以實作自動化測試，只要繼承FunctionalTest這個class並實作對應的函式，以及計算結果的正確與否
BP對記憶體與程式讀取時間的影響是很大的
BP與C++的讀取的行為從本質上就有很大的差別
BP是被視為content，Asset
C++ class則是在程式/遊戲啟動的時候就已經載入到記憶體了，BP則是有需要用到的時候才會觸發讀取。
https://youtu.be/j6mskTgL7kU?t=2429
BP什麼時候會被觸發讀取可以使用Editor內的Reference Viewer來查看。
由左往右連接的意思代表讀取左邊的Asset也會一併讀取右邊的Asset。
BP內的Cast也會建立相依(Reference)
Editor內的SizeMap也可以看出這個BP的大小是因為哪些相關連的Assets組成的
避免一個BP reference到許多其他的BP/Asset。
https://youtu.be/j6mskTgL7kU?t=2736
有需要可以透過增加一層C++ 的base class來迴避BP 彼此reference的問題。
BP的Function Libraries使用要很小心，如果libraries連結到很多不同的class，就會造成災難。
使用Soft reference可以讓BP真的有需要這個asset的時候才作讀取。
Editor與packaged project在讀取時間有很大的差別
Blueprints In-depth - Part 1 | Unreal Fest Europe 2019 | Unreal Engine
https://www.youtube.com/watch?v=j6mskTgL7kU
Blueprints In-depth - Part 2 | Unreal Fest Europe 2019 | Unreal Engine
https://www.youtube.com/watch?v=0YMS2wnykbc
投影片
https://epicgames.ent.box.com/s/hdv4bye3dezabp4duq8pttsha8kjjlde
這篇文章算是摘錄Part 1的一些重點出來~
Author
作者說他自己是artist designer，不是程式出身，所以內容可能有一些是身為程式本來就知道的事情https://youtu.be/j6mskTgL7kU?t=88
Introduction
Blueprint(BP)是Unreal Engine很重要核心的功能學習BP是很容易，就像畫流程圖一樣。
BP的UI介面其實跟程式的.h以及.cpp是很類似的，所以也容易理解。
使用BP很簡單，但是重點在於如何"正確"使用
Feature
https://youtu.be/j6mskTgL7kU?t=409
Feature就是介紹BP跟各種功能/資料類型/類別的關係與說明The Big picture
基本上寫程式想法差不多如何讓BP盡可能的簡潔
如果有人要接手我的工作，怎麼樣才好理解我寫的BP
在作BP的時候有沒有一併考慮記憶體以及效能相關的問題
有沒有考慮到這個BP未來如果會擴張的情況
https://youtu.be/j6mskTgL7kU?t=752
以一個門作為範例
首先一開始一定都是很簡單一個靠近就會開門的BP
之後隨著需求增加了好幾個門的BP，每個功能都有些微的不同。
然後把有相同的部分往上抽了底層，base BP class BP_EnvironmentObject。
隨著複雜度提升，還繼續往C++層抽，把複雜的功能放進C++。
但是可能玩家會去開門，所以玩家會跟門有關，開門的時候會跟動作有關，所以玩家的動畫BP也會跟門有關。
為了提示門可以開，所以HUD也來跟門參一腳了
可能有開門相關的獎盃，所以獎盃也來攪和。
槍可能可以把門打穿，所以....
以上就是一個從一個簡單的BP到整個複雜專案的情況。
Run Time Performance
接下來談到執行的效能部分https://youtu.be/j6mskTgL7kU?t=1088
BP比C++慢，但有的時候效能問題的主因不一定是BP造成的
有很多BP轉C++的目的不一定是為了改善效能
不過錯誤的使用BP有可能造成嚴重的效能問題
BP比C++慢10倍，不過實際上還是要根據不同的情況才能算數。
BP效能不好的幾個原因
https://youtu.be/j6mskTgL7kU?t=1133
1. 太多的節點互相連接
2. 數學運算或是複雜的邏輯運算作在BP是昂貴的。
3. 在BP使用迴圈是昂貴的
4. 在BP巡訪大量的actors/classes是昂貴的
5. 在BP處理Tick的行為是昂貴的，也是BP造成效能不好的主因之一
BP的效能根據不同的執行方式：
編輯器執行(Play In Editor)、Development、Shipping
是有很大的差異的
https://youtu.be/j6mskTgL7kU?t=1303
Tick
https://youtu.be/j6mskTgL7kU?t=1412
這裡的Tick指的是廣泛的Tick，例如BP裡面的Tick，AnimBP的UpdateAnimation，UMG裡面的binding
大部分的情況你不需要使用Tick，甚至於可以關掉Tick。
例如使用Timer，使用事件控制，或是只在某些條件成立的時候才執行Tick，或是距離近/玩家面向此Actor的時候才Tick等等
有些時候也可以透過material來處理BP要做的事情，
Profiling and Debugging
https://youtu.be/j6mskTgL7kU?t=1869BP的除錯介面很方便，從圖中就可以知道現在正在執行那些節點，也可以透過Filter功能只看某一個想關注的actor
透過watch介面也可以即時的看到變數值
Visual Logger
https://youtu.be/j6mskTgL7kU?t=1963Visual Logger功能也是很好的除錯對象，在BP內也可以使用，不管是寫一串文字，畫一個sphere，capsule，一個區段等等。
在Editor可以直接叫起Visual Logger並且錄製除錯資訊。
Console Command
https://youtu.be/j6mskTgL7kU?t=2113
console command dumpticks可以把當下所有有tick的actor資訊寫進outputlog內，可以仔細的觀察有多少actor在tick。
Others
https://youtu.be/j6mskTgL7kU?t=2168UE4內建的profiller還是最詳細的工具，裡面可以列出哪個Actor的哪個函式占用多少CPU時間。
BP也可以實作自動化測試，只要繼承FunctionalTest這個class並實作對應的函式，以及計算結果的正確與否
Memory and Loading
https://youtu.be/j6mskTgL7kU?t=2362BP對記憶體與程式讀取時間的影響是很大的
BP與C++的讀取的行為從本質上就有很大的差別
BP是被視為content，Asset
C++ class則是在程式/遊戲啟動的時候就已經載入到記憶體了，BP則是有需要用到的時候才會觸發讀取。
https://youtu.be/j6mskTgL7kU?t=2429
BP什麼時候會被觸發讀取可以使用Editor內的Reference Viewer來查看。
由左往右連接的意思代表讀取左邊的Asset也會一併讀取右邊的Asset。
BP內的Cast也會建立相依(Reference)
Editor內的SizeMap也可以看出這個BP的大小是因為哪些相關連的Assets組成的
避免一個BP reference到許多其他的BP/Asset。
https://youtu.be/j6mskTgL7kU?t=2736
有需要可以透過增加一層C++ 的base class來迴避BP 彼此reference的問題。
BP的Function Libraries使用要很小心，如果libraries連結到很多不同的class，就會造成災難。
使用Soft reference可以讓BP真的有需要這個asset的時候才作讀取。
Editor與packaged project在讀取時間有很大的差別
留言
張貼留言