版本UE5.1

(資料圖片僅供參考)

因為最近需要做一個功能性的效果。A B 粒子都在一個位置持續發射，并且B粒子發射的多個粒子要跟隨著A做變化性的運動

比如B發射5個粒子圍繞A的運動方向做環繞運動

因為自己對Niagara也不太熟悉。如有不對的地方希望大家指出

下面是我的測試和最后的解決辦法

首先想到的是去看官方的案例找相關的例子。最后在粒子高級案例里面找到了相關的案例

這兩個采用的就是Partile Attibute Reader ??用這個讀取A粒子的相關數據，也可以讀取自身前一幀的數據

具體用法就是要么：B粒子中的Emitter Sapwn 中創建一個，并且在Emitter Name中輸入要讀取發射器的名字。或者在引用的地方輸入

有個前提就是得把粒子的ID先固定就是如下圖

然后我們在Module里面就可以讀取相關的很多數據比如：Bool、Int、Float、Vector2D、Vector、Vector4、Color、NiagaraID、Quaternion

引用的數據的方式有兩種：粒子的ID或者Index索引。但是難就難在最初的我不太了解這兩個是啥。大致知道是某種編號。ID的話倒是了解一點，但不知道它結果分為Index 和Acquire Tag組合在一起的。

在官方高級案例2.2中提到：這個ID與Index不同，它被保證在每一幀之間是穩定的。索引是一個從0到NumParticles-1的值，因此可以隨著粒子的死亡和出生而改變。

似懂非懂的感覺⊙﹏⊙∥（結果一入ID的坑這才剛開始，掉進去了一個星期）

回到正題

在Niagara工具中我找到了多個ID和index

這個工具可以幫助我們查看粒子的信息，以幫助我們找到我們需要的和驗證

經過我的研究發現Array Index 是持久固定的數量（場景中存在的粒子個數決定），好像也就是Execution Index。而且每個粒子會經歷這里面的所有數值。就是第一個發射出來的粒子是0，后面發射出來的就依次增加成為 1 2 3 ....但是當第一個粒子死亡時候之前是1的就變成了0 ?2就變成了1。

中間的兩個Index和Tag 和起來就是上面說的ID。ID是唯一的這也是能精準找到我們想要的粒子的數據重要的東西

UniqueID是持續增加的并且不會因為粒子死亡而改變。出生就被按順序賦予?

還有一個工具就是UE5后才有的Debug功能，這樣在場景中就能看到數據就方便了很多

并且還能暫停和緩速播放

官方案例中基本上都是用的瞬間發射Burst，這樣的話它的ID這些就能很好的獲取。理解起來也相對于持續發射簡單。（雖然開始我也理解了很久(? ?_?)? ）

先把準備工作做好

因為要一直跟著A運動，那么就每幀都得去獲取A的信息，那么就在Particle Update里面創建一個Module。

Num是我建立的參數代表B粒子發射的數量

我想的是如果B要跟著A走那么就得獲取A的位置Position。

或者和A做相同的運動，那么就得獲取速度Velocity。速度里面也包含方向

但是通過我測試發現獲取粒子的速度比獲取位置要好的多，因為每一幀都在獲取，獲取位置不方便粒子變化，因為變化后下一幀就又會被定義到新的位置，這樣粒子容易出現閃現和顫抖的感覺。處理起來就沒有速度方便，獲取位置就得去做比速度多的處理，做過渡等，所以后面就都獲取A粒子的速度了

這里呢需要我們操作的地方有三個

Attribute是需要填入我們需要獲取的數據的名字

ParticleReader需要鏈接信息的來源

最后就是這里粒子的信息我還不知道用ID 還是Index

3.1使用粒子ID獲取

我一開始就獲取粒子的ID開始（因為獲取輸入ID就出來了）ID是B粒子的ID

結果卻大不相同，當1對1是確實什么問題都沒有。但當1對N時它讀取的信息就不對。通過工具發現都發射一個粒子時候ID是一樣的，B發射多個的時候只有一個和A一樣。

但是通過工具就發現了同一時間發射出來的粒子ID后面的tag是一樣的，只是前面的Index不一樣。所以做了一個數據處理就能解決

到這里基本上的效果已經實現了。A B粒子都采用Burst發射，然后一秒循環一次。

3.2使用Index獲取

順勢獲取ID拆分處理的Index，以為一切順利

結果當A的第一個粒子死亡時，它的采樣卻又不對了，采樣ID都沒出現。當時也不知道啥原因，去官網也找了，也沒找到。都是當我最后研究出來才知道這里Index并不是ID里面拆分出來的Index。它是用的Execution Index

4.使用持續發射Rate

4.1使用粒子Index

把AB粒子就按照上圖那樣鏈接方式。把發射方式改成Rate，但是就出現了下面的問題。當A粒子第一個死亡后。B粒子同一秒中發射出來的粒子先發射出來的粒子運動軌跡不一樣，有種突然被拉扯過去的感覺

這種應該就是官方說的Index不穩定，它會隨著粒子死亡發生改變。所以還是改成ID采集

4.2使用粒子ID

但是把也不順利，因為粒子B是持續發射，它的每一個Acquire Tag都是不一樣的，就算把ID的Index統一了但Tag不一樣，所以就出現了只有一個粒子跟隨，其他粒子采集的ID不對，就只能再原地

所以就得把Tag解決。通過我們的觀察可以發現Tag是個很大的值，而且持續增加。而且只有同一時間發射出來的粒子Tag就是完全一樣的，所以Tag應該就和時間相關。這方面我也是通過https://zhuanlan.zhihu.com/p/427618536里面了解到的。AcquireTag 就是粒子系統的TickCount，也就是運行的tick次數

但是呢我需要統一Tag，持續發射的值都不一樣。我們需要和A粒子一樣的Tag，所以我們再A粒子生成的時候去獲取相應的Tag

但是問題還是沒有得到解決，思路應該是對的，所以我又增加了兩個值來Debug

通過這樣發現當B粒子死亡時，原來執行Index為N的變成了N-1。如當第一個粒子死亡時候原來為4的變成了3，那么它通過取整就從取2 Index的值變成了取1 Index值，這樣就不太對。所以我們還得增加點判斷

先把兩個不同的Index儲存起來，然后獲取當前需要跟隨的A粒子的ID，并通過Get ID by ID這個節點來做判斷依據。當Index01（執行索引）發生變化的時候，那么B粒子肯定采集不到相同ID的A粒子，那么就會給出一個False。那么我們這時候就把Index01（執行索引）加1，然后重新定義Index01（執行索引）

最后我們再來獲取A粒子的速度，這樣就解決了

最后就是如果修改了東西后結果場景中沒反應，或者編號這些不對，那可能是Niagara編譯問題。我們可以在點擊保存和編譯，并且把場景中粒子的自動激活重新取消打勾再勾上。選中粒子再按按/，它就會恢復正常。

要是還是不對那就得多檢查寫對了嗎

希望大家如果有不對或者更好的理解，歡迎大家討論討論

標簽： BURST INDEX 粒子系統 工具介紹 ATTRIBUTE DEBUG VECTOR COLOR 數據處理 FALSE 只有一個 解決辦法 似懂非懂 準備工作 不一樣的 HTTPS