虚幻Niagara特效

它解决什么问题

UE5 的粒子特效统一由 Niagara 承担，老的 Cascade 已经废弃。但 Niagara 的模型并不直观：一个 NS_ 系统里嵌着多个 NE_ 发射器，每个发射器又按 Emitter Spawn/Update、Particle Spawn/Update、Event Handler、Render 等阶段执行。搞不清这套层级，就容易写出“特效生成了但参数改不动”的代码——因为只有 User 命名空间 的参数才能被 Blueprint/C++ 写入。这个技能把层级、执行顺序和参数暴露方式梳理成一条可操作的工作流。

核心能力与关键步骤

1. 理解层级：Niagara System（NS_）是最终放置或生成的特效，内部包含一个或多个 Emitter（NE_，通常是发射器模板）。
2. 用 Module 拼行为：Spawn Rate、Add Velocity、Gravity Force、Color over Life 等模块在各阶段内自上而下执行，后面的模块能读到前面写入的值，顺序敏感。
3. 认清参数命名空间：System / Emitter / Particle 参数只在模拟内部有效；只有 User 参数暴露给 UNiagaraComponent，供 Blueprint/C++ 设置。
4. 运行时生成：UNiagaraFunctionLibrary::SpawnSystemAtLocation 按世界坐标生成，SpawnSystemAttached 绑定到组件或 socket（例如跟随枪口的火光），两者都返回 UNiagaraComponent。
5. 驱动与控制：通过返回的组件写入 User 参数（颜色、生成速率、目标点），并用 Activate()/Deactivate() 控制开关。
6. 验证：在 Niagara 编辑器预览和场景内检查表现，重点核对 bounds（尤其是 GPU 发射器），确认 cull 与销毁逻辑正确。

适用边界与注意点

• 材质/着色器制作是独立话题，交给 shader-programming；特效配套的音频属于 audio-design。
• 不要从 gameplay 代码设置 System/Emitter/Particle 参数，不会生效；先暴露到 User 命名空间。
• 网上大量 Cascade 教程已过时，Niagara 的 emitter/module 工作流并不相同。
• GPU Compute 发射器必须显式设置 Fixed Bounds，否则特效可能消失或 cull 异常。
• 用 bAutoDestroy = false 生成的特效要自行管理组件生命周期，否则会无限循环。
• GPU 粒子数据不回读 CPU；需要 gameplay 响应的碰撞/事件应使用 CPU emitter，或走 Niagara 数据接口。
• Module 栈顺序错误会让 Force/Velocity 读到未初始化的零值，排查时先看模块排列。

C++ 侧需在 .Build.cs 中添加 Niagara 模块，并参考官方 “Overview of Niagara Effects” 文档与 UNiagaraFunctionLibrary / UNiagaraComponent API。