Niagara核心架构：三层结构与数据流动
聊Niagara之前，我先问大家一个问题：
你以前用Cascade做特效时，有没有遇到过这种情况——想改一个粒子颜色，结果要翻遍整个发射器？
嗯，我遇到过。而且不止一次。
Niagara的出现，说白了就是要把这种混乱彻底干掉。
它把整个特效系统拆成了三个清晰的层级：System → Emitter → Module。
每一层各司其职，数据流动也井井有条。
第一层：Niagara System（系统层）
System是最高层级，你可以把它理解成一个「特效容器」。
一个System里可以塞多个Emitter，每个Emitter又可以跑不同的粒子逻辑。
我个人习惯是：
把System当作一个「完整的特效实例」。比如一个爆炸特效，里面可能包含火花、烟雾、碎片三个Emitter，它们共享同一个生命周期。
第二层：Emitter（发射器层）
Emitter是真正的「粒子生产车间」。
每个Emitter都有自己的生命周期、生成规则和更新逻辑。
我记得有一次做火焰特效，一开始把所有的粒子逻辑都塞在一个Emitter里，结果性能炸了。
后来拆成三个Emitter：一个负责火焰核心，一个负责火星飞溅，一个负责烟雾飘散。每个Emitter的粒子数量控制在合理范围内，性能瞬间就稳了。
Emitter层有几个核心属性你需要记住：
- Emitter Duration：发射器持续时长
- Spawn Rate：每秒生成粒子数
- Spawn Burst：一次性爆发粒子数
- Emitter Update：每帧执行的更新逻辑
第三层：Module（模块层）
Module是Niagara最灵活的部分。
每个Module本质上是一段「可复用的逻辑片段」。你可以把它拖到Emitter或Particle的更新栈里，像搭积木一样组合出复杂效果。
举个例子：
你想让粒子做螺旋运动。传统做法是写一大段脚本。
但在Niagara里，你只需要拖一个「Add Velocity in Cone」模块，再配合一个「Orbit」模块，两下就搞定了。
数据接口与命名空间
Niagara里最让人头疼的，可能就是数据怎么在不同层级之间传递。
别怕，其实规则很简单。
每个层级都有自己的命名空间：
| 命名空间 | 作用域 | 典型用途 |
|---|---|---|
| Engine. | 全局 | 时间、DeltaTime、系统状态 |
| System. | 整个System | 系统级参数、用户输入 |
| Emitter. | 单个Emitter | 发射器生命周期、生成速率 |
| Particles. | 单个粒子 | 位置、速度、颜色、大小 |
数据流动的方向是：Engine → System → Emitter → Particles。
你不能让一个粒子去修改Engine的时间，但Engine的时间可以影响粒子的行为。
我曾经犯过一个低级错误：
在Particle Update里直接写死了粒子的初始位置，结果所有粒子都从同一个点发射，完全失去了随机感。
后来才意识到，应该用Particles.Position配合Random Range模块来生成初始位置。
一个简单的实战例子
假设我们要做一个「粒子跟随鼠标」的效果：
1. 在System层添加一个用户参数：User.MousePosition（Vector类型）
2. 在Emitter层，把Spawn Rate设为100
3. 在Particle Update层，添加一个「Set Position」模块
4. 把Position的值绑定到 User.MousePosition 上
你看，数据从System传到Emitter，再传到Particle，路径非常清晰。
Particles.Color，但实际模块里用的是Particles.Colour（美式拼写），引擎不会报错，但效果就是出不来。
总结一下
Niagara的三层架构，说白了就是：
System管大局，Emitter管生产，Module管细节。
数据通过命名空间在层与层之间流动，清晰又高效。
下一章我们会深入Module的内部结构，看看那些「搭积木」的模块到底是怎么工作的。
到时候我会分享一个我踩过的坑——关于Module执行顺序的，保证让你少走弯路。