1.概括想法

版本UE5.1

因?yàn)樽罱枰鲆粋€(gè)功能性的效果。A B 粒子都在一個(gè)位置持續(xù)發(fā)射，并且B粒子發(fā)射的多個(gè)粒子要跟隨著A做變化性的運(yùn)動(dòng)

比如B發(fā)射5個(gè)粒子圍繞A的運(yùn)動(dòng)方向做環(huán)繞運(yùn)動(dòng)

因?yàn)樽约簩iagara也不太熟悉。如有不對的地方希望大家指出

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

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

這兩個(gè)采用的就是Partile Attibute Reader ??用這個(gè)讀取A粒子的相關(guān)數(shù)據(jù)，也可以讀取自身前一幀的數(shù)據(jù)

具體用法就是要么：B粒子中的Emitter Sapwn 中創(chuàng)建一個(gè)，并且在Emitter Name中輸入要讀取發(fā)射器的名字?；蛘咴谝玫牡胤捷斎?/p>

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

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

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

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

似懂非懂的感覺⊙﹏⊙∥（結(jié)果一入ID的坑這才剛開始，掉進(jìn)去了一個(gè)星期）

?

2.工具介紹

回到正題

在Niagara工具中我找到了多個(gè)ID和index

這個(gè)工具可以幫助我們查看粒子的信息，以幫助我們找到我們需要的和驗(yàn)證

?

經(jīng)過我的研究發(fā)現(xiàn)Array Index 是持久固定的數(shù)量（場景中存在的粒子個(gè)數(shù)決定），好像也就是Execution Index。而且每個(gè)粒子會(huì)經(jīng)歷這里面的所有數(shù)值。就是第一個(gè)發(fā)射出來的粒子是0，后面發(fā)射出來的就依次增加成為 1 2 3 ....但是當(dāng)?shù)谝粋€(gè)粒子死亡時(shí)候之前是1的就變成了0 ?2就變成了1。

中間的兩個(gè)Index和Tag 和起來就是上面說的ID。ID是唯一的這也是能精準(zhǔn)找到我們想要的粒子的數(shù)據(jù)重要的東西

?

UniqueID是持續(xù)增加的并且不會(huì)因?yàn)榱Ｗ铀劳龆淖儭３錾捅话错樞蛸x予?

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

并且還能暫停和緩速播放

?

3.正式的操作 AB粒子均采用Burst發(fā)射

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

先把準(zhǔn)備工作做好

因?yàn)橐恢备鳤運(yùn)動(dòng)，那么就每幀都得去獲取A的信息，那么就在Particle Update里面創(chuàng)建一個(gè)Module。

?

Num是我建立的參數(shù)代表B粒子發(fā)射的數(shù)量

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

或者和A做相同的運(yùn)動(dòng)，那么就得獲取速度Velocity。速度里面也包含方向

但是通過我測試發(fā)現(xiàn)獲取粒子的速度比獲取位置要好的多，因?yàn)槊恳粠荚讷@取，獲取位置不方便粒子變化，因?yàn)樽兓笙乱粠陀謺?huì)被定義到新的位置，這樣粒子容易出現(xiàn)閃現(xiàn)和顫抖的感覺。處理起來就沒有速度方便，獲取位置就得去做比速度多的處理，做過渡等，所以后面就都獲取A粒子的速度了

?

這里呢需要我們操作的地方有三個(gè)

Attribute是需要填入我們需要獲取的數(shù)據(jù)的名字

ParticleReader需要鏈接信息的來源

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

3.1使用粒子ID獲取

我一開始就獲取粒子的ID開始（因?yàn)楂@取輸入ID就出來了）ID是B粒子的ID

?

結(jié)果卻大不相同，當(dāng)1對1是確實(shí)什么問題都沒有。但當(dāng)1對N時(shí)它讀取的信息就不對。通過工具發(fā)現(xiàn)都發(fā)射一個(gè)粒子時(shí)候ID是一樣的，B發(fā)射多個(gè)的時(shí)候只有一個(gè)和A一樣。

?

但是通過工具就發(fā)現(xiàn)了同一時(shí)間發(fā)射出來的粒子ID后面的tag是一樣的，只是前面的Index不一樣。所以做了一個(gè)數(shù)據(jù)處理就能解決

?

到這里基本上的效果已經(jīng)實(shí)現(xiàn)了。A B粒子都采用Burst發(fā)射，然后一秒循環(huán)一次。

3.2使用Index獲取

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

?

結(jié)果當(dāng)A的第一個(gè)粒子死亡時(shí)，它的采樣卻又不對了，采樣ID都沒出現(xiàn)。當(dāng)時(shí)也不知道啥原因，去官網(wǎng)也找了，也沒找到。都是當(dāng)我最后研究出來才知道這里Index并不是ID里面拆分出來的Index。它是用的Execution Index

4.使用持續(xù)發(fā)射Rate

4.1使用粒子Index

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

這種應(yīng)該就是官方說的Index不穩(wěn)定，它會(huì)隨著粒子死亡發(fā)生改變。所以還是改成ID采集

4.2使用粒子ID

但是把也不順利，因?yàn)榱Ｗ覤是持續(xù)發(fā)射，它的每一個(gè)Acquire Tag都是不一樣的，就算把ID的Index統(tǒng)一了但Tag不一樣，所以就出現(xiàn)了只有一個(gè)粒子跟隨，其他粒子采集的ID不對，就只能再原地

所以就得把Tag解決。通過我們的觀察可以發(fā)現(xiàn)Tag是個(gè)很大的值，而且持續(xù)增加。而且只有同一時(shí)間發(fā)射出來的粒子Tag就是完全一樣的，所以Tag應(yīng)該就和時(shí)間相關(guān)。這方面我也是通過https://zhuanlan.zhihu.com/p/427618536里面了解到的。AcquireTag 就是粒子系統(tǒng)的TickCount，也就是運(yùn)行的tick次數(shù)

但是呢我需要統(tǒng)一Tag，持續(xù)發(fā)射的值都不一樣。我們需要和A粒子一樣的Tag，所以我們再A粒子生成的時(shí)候去獲取相應(yīng)的Tag

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

通過這樣發(fā)現(xiàn)當(dāng)B粒子死亡時(shí)，原來執(zhí)行Index為N的變成了N-1。如當(dāng)?shù)谝粋€(gè)粒子死亡時(shí)候原來為4的變成了3，那么它通過取整就從取2 Index的值變成了取1 Index值，這樣就不太對。所以我們還得增加點(diǎn)判斷

先把兩個(gè)不同的Index儲(chǔ)存起來，然后獲取當(dāng)前需要跟隨的A粒子的ID，并通過Get ID by ID這個(gè)節(jié)點(diǎn)來做判斷依據(jù)。當(dāng)Index01（執(zhí)行索引）發(fā)生變化的時(shí)候，那么B粒子肯定采集不到相同ID的A粒子，那么就會(huì)給出一個(gè)False。那么我們這時(shí)候就把Index01（執(zhí)行索引）加1，然后重新定義Index01（執(zhí)行索引）

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

?

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

?

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

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

?

?