Cascade 时代的粒子与它的局限

老一代 UE 开发者对 Cascade 的感情是复杂的：它稳定、直观、上手快，但在项目规模化后几乎必然撞墙。先说它到底"痛"在哪，再理解 Niagara 为什么要重做。

Cascade 的设计逻辑

Cascade 是一个单体式发射器：一个粒子发射器（Emitter）内部写死了"怎么发射、怎么更新、怎么渲染"。编辑器里看到的那些模块（Spawn、Lifetime、Initial Velocity、Color Over Life……）是固定管线的一部分，加一个新行为需要：

• 引擎提供的模块不够用 → 写 C++ 新模块（编译一次引擎或插件）；
• 想复用一段逻辑到别的发射器 → 复制粘贴整个 Emitter，然后逐个参数对齐；
• 想跨发射器共享数据（比如让 A 发射器的粒子躲避 B 发射器的粒子）→ 基本做不到。

三个典型的撞墙时刻

数据驱动的缺失

Cascade 的参数存在资产里，但逻辑本身不是数据。"发射 100 个粒子，每个粒子先上升 1 秒再炸开"——这个行为描述被编译进模块管线，不是一份可以被读取、批量修改、程序生成的数据。这导致：

• 无法做"特效配置表"（策划改不了，必须找美术打开编辑器）；
• 无法批量体检（"哪些 Emitter 用了 GPU 粒子？""哪些发了超过 500 个？"答不上来）；
• 无法程序化生成（一个"枪口火光模板"不能由代码按武器类型参数化产出）。

一句话总结

Cascade 的问题不是"功能不够"，而是架构前现代：逻辑与数据不分、资产不可组合、行为不可编程。Niagara 的全部设计都在回答这三个问题——这也是后面四章要展开的内容。