Niagara_Advanced内容示例 4.2 Export Particle Data to Blueprint

粒子效果

从模拟位置不断地向外发射小球，当小球与地板发生碰撞时，会在屏幕坐上角相应地显示出一串文字，显示的是碰撞位置，此外，文字的颜色也各有不同。

Niagara蓝图部分

本例展示的是从粒子中获取数据拿到蓝图中使用，所以会有一个Actor蓝图负责处理Niagara System中传出的数据，以及一个Niagara System蓝图负责生成粒子、产生数据。

可以看到两个蓝图中都伴有非常详尽的注释，先看向Actor类蓝图。

Actor类中，主要实现两个函数：Begin Play和Receive Particle Data。Begin Play时是将自身作为参数设置到了Niagara一个名为“BpCallBackHandler”的变量里。

后者是一个接口事件（interface event），创建方法是进入类配置的细节面板，添加回调句柄到Implemented Interfaces中，然后右键Receive Particle Data，创建事件。

只有当有数据从粒子发出时才会调用这个事件。这里在这个事件内部，将粒子发出的结构体信息包进行了拆解，然后再在这些拆出来的数据基础上进行操作。

再进入到Niagara蓝图中，其中包含两个发射器，分别是CPU粒子发射器和GPU粒子发射器。后面一个小节我们具体看看数据是如何从Niagara流向Actor蓝图的。

效果实现分析

虽然说现在对CPU粒子和GPU粒子都支持数据向蓝图的流动，但是具体效果上，还是会产生些许的不同。蓝图的操作发生在CPU上，即都是在CPU某处寄存器中数据进行存和读，然后再拿到GPU去渲染出图；而GPU粒子的数据是存在GPU内存上的，需要通过一个回读过程（readback）再传回到CPU去处理，这一来一去会造成一个不可预料的延迟，即同一帧里，粒子已经到下一个位置了，而传到蓝图的数据还是前一帧或者前几帧的位置数据。这也是GPU粒子不采用CPU粒子碰撞而采用距离场或者深度缓冲等做法的原因——因为如果还把GPU数据传回到CPU去计算碰撞，粒子可能早就飞出不知道多远了。

还记得上文中提到，Actor类蓝图中在BeginPlay设置了一个Niagara变量，这个变量：

这个变量在模块Export Particle Data to Blueprint中作为回调句柄参数，其余被传输的数据包含有两个vector和一个scaler数据。将现在的这个模块翻译一下，就是在碰撞发生时（CollisionValid），延迟0.1s，将粒子位置、粒子颜色和0组成一个数据包，通过BPCallbackHandler将包发送到蓝图。

回到Actor类蓝图，这里的Data即是一帧内同时受到的多个数据包，后面的操作就是循环解压，将包里的信息展开成两个vector和一个scaler。

总结

本例的内容在实际中非常有用，比如说喷发的火山和玩家的交互等等。它对我更多的启发是关于内存方面的思考，即CPU内存到GPU内存，再回到CPU，以及这中间产生的消耗和时间，也让我意识到GPU粒子的局限。当然，技术在进步，也会有相应的优化技术出现以弥补缺陷，毕竟以后GPU粒子会越来越称为主流。