实时粒子与 VFX 工程 2026：从 Niagara 到自研 GPU 粒子引擎
把实时粒子与 VFX 工程从 CPU 逐粒子更新推到 Compute Shader + ring buffer + indirect draw + emitter-system 数据解耦的 GPU 数据流驱动范式,拆成四元组契约、Niagara 2.0 解耦、自研引擎装配、跨平台落地、性能推论、工作清单,让引擎开发者在做技术选型与重构时有一份可落地的工程蓝图。
约 28 分钟阅读8,351 字1 次阅读博主
把实时粒子与 VFX 工程从 CPU 逐粒子更新推到 Compute Shader + ring buffer + indirect draw + emitter-system 数据解耦的 GPU 数据流驱动范式,拆成四元组契约、Niagara 2.0 解耦、自研引擎装配、跨平台落地、性能推论、工作清单,让引擎开发者在做技术选型与重构时有一份可落地的工程蓝图。
一句话摘要：在 2026 年的游戏引擎底层，实时粒子与 VFX 已经从 CPU 端逐粒子更新 + 顶点缓冲渲染的"传统流派"，迁移到 Compute Shader + ring buffer + indirect draw + emitter-system 数据解耦的"GPU 数据流驱动流派"。本文把这套迁移路径拆成四元组契约、Compute 管线内核、Niagara 2.0 解耦、自研引擎装配、跨平台落地、性能推论、工作清单 9 个部分，让引擎开发者在做技术选型与重构时有一份可落地的工程蓝图。
2018 年之前，几乎所有商业引擎的粒子系统都是"CPU 逐粒子 + 顶点缓冲渲染"的形态：粒子在 CPU 端按 Emitter → Particle → Render Instance 的层级更新，每帧把变换矩阵写回顶点缓冲，再走传统 draw call。这种架构在"万级粒子"以下没有任何问题——彼时主流特效（火、烟、爆炸、魔法光环）峰值粒子数也就在 5000–20000 之间，CPU 单核更新的开销完全可以承受。
2022 年之后出现了三个结构性变化：第一，AAA 单机游戏的视觉密度爆炸，《赛博朋克 2077》《黑神话：悟空》《战神：诸神黄昏》的单场景峰值粒子数跨过 50 万大关，CPU 端更新已经成为不可接受的瓶颈；第二，DLSS/FSR/XeSS 的普及让特效纹理分辨率从 1080p 拉到 4K，材质与光照开销翻了 3–4 倍，GPU 端粒子的"自给自足"（自带 sim + render）价值大幅提升；第三，UE5 Niagara 2.0、Unity VFX Graph、自研 GPU 粒子引擎（米哈游 HoYoverse Cascade、网易 Messiah、腾讯自研 Cascade）相继落地，标志着 GPU 数据流驱动范式成为行业事实标准。
但迁移路径并不平滑。许多团队 2024 年还在用 UE4 Cascade 的 legacy CPU 路径，到 2026 年被迫整体重写——重写过程中最容易踩的坑是"以为只是把 CPU 代码搬到 GPU 上"，结果数据布局没改、ring buffer 没设计、indirect draw 没接好，最终性能比 CPU 端还差。本文的目标就是把这条迁移路径拆成可验证的工程契约，让任何一家中型工作室在 6 个月内完成自研或迁移工作，并把产能、数据所有权和性能三者统一在一个装配里。
为了避免在后续章节里反复回到"什么是粒子"，我们先把实时粒子系统的四元组形式化：
pos、速度 vel、寿命 life、年龄 age、旋转 rot、大小 size、颜色 color、自定义属性 custom_a/b/c/d（Niagara 提供了 8 个自定义属性槽）。P。P 投影到屏幕，通常用 mesh shader / indirect draw 把粒子实例化为 quad / mesh / ribbon。把这四元组压成 GPU 数据布局后，整套系统就有了一个非常清晰的契约：
// 粒子实例的 GPU 数据布局 (HLSL, 64-byte aligned, std430)
struct ParticleGPU {
float3 pos; // 0
float3 vel; // 12
float life; // 24
float age; // 28
float4 rot_size; // 32: xyz=旋转四元数, w=大小
float4 color; // 48: rgba
float4 custom; // 64: 自定义 1
};
// sizeof(ParticleGPU) = 80 bytes，cache line (64B) 对齐后 padding 一次
整个管线的运行契约可以画成下面的 Mermaid 数据流：
图表加载中…
这条契约的工程意义有三层：第一，每一阶段都是 GPU Compute 阶段 + 一个 buffer hand-off，没有任何 CPU 端回读（这点对延迟和吞吐都至关重要）；第二，死亡粒子通过 free list 在 GPU 端复用，避免 CPU 端 malloc/free 的开销；第三，渲染阶段的 indirect draw 完全基于 append buffer 的真实 count，不需要 CPU 端预计算 instance count。这三层契约一旦定型，下面章节的所有性能数字、Niagara 2.0 的设计哲学、自研引擎的横评取舍，都将围绕这张图展开。
Compute Shader 粒子管线的内核，由四个相互衔接的 compute pass 组成。下面逐一拆解。
Spawn Pass 接收一个 EmitterGPU 结构（描述发射形状 + 速率），按 DispatchIndirect(num_groups) 的方式启动，每个 thread group 处理 N 个粒子。它的核心逻辑有两段：一是根据 EmitterGPU.shape（点 / 圆锥 / 球 / 网格 surface）采样初始位置与初始速度；二是从 free list 取出空闲槽位写入新粒子。这里有一个 2026 年才被普遍采纳的优化——所有"并行安全"的随机数都用 hash-based PRNG（如 pcg3d 或 hash33），避免 rand() 同步带来的性能塌陷：
// HLSL: hash-based PRNG (NVIDIA 推荐, UE5 内部实现)
uint3 pcg3d(uint3 seed) {
seed = seed * 1664525u + 1013904223u;
seed.x += seed.y * seed.z;
seed.y += seed.z * seed.x;
seed.z += seed.x * seed.y;
seed ^= seed >> 16u;
seed.x += seed.y * seed.z;
seed.y += seed.z * seed.x;
seed.z += seed.x * seed.y;
return seed;
}
// Spawn kernel (简化版, 实际还有贴附表面采样)
[numthreads(64, 1, 1)]
void CSpawn(uint3 id : SV_DispatchThreadID) {
uint slot = FreeList.Consume(); // 从 ring buffer 取空闲槽
if (slot == INVALID) return; // pool 满, 跳过
ParticleGPU p = (ParticleGPU)0;
float3 r = float3(pcg3d(id.xyz + FrameSeed)) / 4294967296.0; // [0,1)
p.pos = EmitterPos + SampleEmitterShape(r);
p.vel = EmitterDir * Speed + Turbulence(r);
p.life = lerp(LifeMin, LifeMax, r.z);
p.age = 0;
Particles[slot] = p;
}
Update Pass 是粒子管线最热的 pass，每帧要遍历所有活粒子，应用重力、风、湍流（curl noise）、碰撞（与 SDF 网格、与简单几何体）、寿命衰减（age += dt; if (age >= life) recycle）。它的输入是上一帧 Particles[]，输出是新一帧 Particles[]。
这里有两个性能关键点：
第一，双缓冲（ping-pong）避免读写冲突：标准做法是 ParticlesA[] + ParticlesB[]，奇数帧从 A 读写入 B，偶数帧从 B 读写入 A。如果只用一份 buffer 强制 MemoryBarrier + 拆 pass，开销会接近双倍。第二，SIMD 友好的标量化：UE5 / Unity VFX Graph 都把 4 个粒子打包成 float4 对齐处理（NVIDIA / AMD 都建议用 float4 而非 float3），可以减少 LDS（Local Data Share）和 cache miss。
[numthreads(64, 1, 1)]
void CUpdate(uint3 id : SV_DispatchThreadID) {
ParticleGPU p = ParticlesIn[id.x];
if (p.life <= 0) return;
p.age += DeltaTime;
if (p.age >= p.life) {
FreeList.Release(id.x);
return;
}
// 重力
p.vel += Gravity * DeltaTime;
// 湍流 (curl noise, 简化版)
float3 n = CurlNoise(p.pos * 0.1 + FrameSeed);
p.vel += n * TurbulenceStrength * DeltaTime;
// 位置积分
p.pos += p.vel * DeltaTime;
ParticlesOut[id.x] = p;
}
Cull Pass 是连接"模拟世界"与"渲染世界"的桥梁。它遍历所有活粒子，根据相机的视锥、距离 LOD、shadow caster 标记，决定哪些粒子进入渲染 instance list。标准做法是用 AppendBuffer 或 ConsumeStructuredBuffer：
[numthreads(64, 1, 1)]
void CCull(uint3 id : SV_DispatchThreadID) {
ParticleGPU p = Particles[id.x];
if (p.life <= 0) return;
if (!InFrustum(p.pos, ViewFrustum)) return;
if (DistanceSq(p.pos, CameraPos) > MaxDrawDistSq) return;
uint slot = RenderList.Append({ id.x, packed_color });
VisibleCount.IncrementCounter();
}
2026 年的工程经验是：Cull Pass 的 SIMD 利用率是整个粒子管线的瓶颈，因为它的分支密度最高、内存访问最随机。两个常见优化：一是把 cull 与 update 合并（if (alive && in_frustum)），省一次内存往返；二是用 wave intrinsics 做"4 粒子一批"的 lane mask。
Render Pass 接收 VisibleInstanceBuffer，用 mesh shader（或传统 VS+GS）生成 quad / ribbon / mesh，然后走 indirect draw 把它们提交到光栅化阶段。Mesh Shader 在 DX12 Ultimate / Vulkan 1.3 都已经普及，它的好处是"amplification shader 自动按 meshlet 分组"，对粒子的 quad batching 几乎是免费的。
到这里，整条 Compute Shader 粒子管线的内核装配就完整了。可以看到，它的核心是"4 个 compute pass + 2 个 buffer hand-off + 1 个 indirect draw"——这套装配在 2026 年的 UE5 Niagara 2.0、Unity VFX Graph、自研 GPU 粒子引擎里都有体现，只是细节取舍不同。
UE5 Niagara 2.0（2024 年 Epic 在 UE 5.4 里完成的主线重构）最大的架构突破是 emitter 与 system 的解耦。在 UE4 Cascade 时代，一个 Niagara 系统就是一个 "effect"，里面可以放多个 emitter，但 emitter 之间是紧耦合的——它们共享 EmitterState 和 Spawn Burst Instantaneous 配置，要修改任何一个 emitter 都得整体打开。
Niagara 2.0 引入了 System / Emitter / Module 三层架构，加上面向美术与 TA 的"模块编辑器"，把数据驱动范式推到了行业前沿。下面是三层架构的核心契约：
Initialize Particle、Update Acceleration、Color over Life、Mesh Renderer）。每个模块都有自己的 input/output pin，参数可暴露到 System 层。这套解耦的工程价值有三层：
第一，模块复用率从 ~30% 提升到 ~80%。一个 Initialize Particle 模块在火焰、烟雾、爆炸里都能用，避免了过去"复制一份 emitter 改参数"的低效流程。第二，TA 与美术的工作流分离。TA 写模块（带 input/output 契约），美术通过模块编辑器拖拽组合，不需要写代码。第三，热重载与变体管理。Niagara 2.0 的"模块重载 + 参数实时绑定"让美术在编辑器里改一个 Color over Life 曲线，30 ms 后就能在 PIE 看到效果——这在过去 Cascade 时代需要 5–10 秒的 reload。
下面是一个简化的 Niagara 2.0 emitter 模块图：
图表加载中…
但 Niagara 2.0 也有它的代价：模块越多，编译变体（shader permutation）数量爆炸。一个复杂的火焰 effect 可能有 200+ 变体，shader compile time 在 PSO 预热阶段会卡顿 5–15 秒。2026 年的主流解法是用 Material Function + Static Switch Parameter 把"可有可无"的模块编译分支化，把变体数控制到 50 以内。这是 Niagara 2.0 的工程取舍核心——解耦换来了复用，复用换来了变体爆炸，变体爆炸换来了编译时间与内存压力。
对于希望摆脱引擎绑定、或追求极致性能（米哈游、网易、腾讯、字节）的工作室，自研 GPU 粒子引擎是必经之路。下面是 2026 年自研引擎的统一装配清单：
现代引擎的渲染层都走 Render Graph（UE5 FRDG、Frostbite FG、自研 FG）。粒子系统要作为 Render Graph 的一个 PassGroup 注册，包含：
ParticleSimPass：compute pass，执行 §3 的 spawn/update/cullParticleRenderPass：mesh shader 或 indirect draw passParticleShadowPass：深度 pass，给 directional / point light 投影Render Graph 的依赖追踪会自动处理这些 pass 之间的 buffer transition（UAV → SRV → RT），避免手动 ResourceBarrier 的负担。
粒子数据用 SoA（Structure of Arrays）布局，而非 AoS（Array of Structures）。原因是 SoA 对 SIMD 更友好：
// SoA 布局 (cache friendly, SIMD 友好)
RWStructuredBuffer<float4> ParticlePos; // xyz=pos, w=age
RWStructuredBuffer<float4> ParticleVel; // xyz=vel, w=life
RWStructuredBuffer<float4> ParticleRot; // xyz=rot quat, w=size
RWStructuredBuffer<float4> ParticleColor; // rgba
每个 buffer 都是 16-byte 对齐，4 粒子打包成 float4 时可以一次 SIMD lane 处理 4 个粒子。
粒子池用 ring buffer 实现，固定大小（如 256k 个粒子），用 free list 跟踪空闲槽位。Ring buffer 的好处是 allocator 开销为 O(1)，free list 在 GPU 端用 InterlockedAdd 维护。
自研粒子引擎必须内置 RenderDoc / PIX / Razor 的 annotation 标记，每个 compute pass 都要有命名（Partices::Spawn、Particles::Update、Particles::Cull、Particles::Render），否则出问题时没法快速定位。
粒子引擎的 Compute Shader 要做到三平台通用。最稳的做法是用 HLSL 写 compute shader，用 DXC 编译到 SPIR-V（HLSL→SPIR-V cross-compile），再通过 SPIRV-Cross 转成 MSL（HLSL→SPIR-V→MSL）。Vulkan 与 Metal 都能直接消费 SPIR-V，DX12 消费 DXIL。
下面是自研 GPU 粒子引擎的横评表：
| 引擎 | GPU 模拟路径 | 变体管理 | 跨平台 | 自研程度 |
|---|---|---|---|---|
| UE5 Niagara 2.0 | Compute + Mesh Shader | Module Permutation | DX12/Vulkan/Metal | 半自研（基于 UE） |
| Unity VFX Graph | Compute + VS+GS | Variant Shader | DX11/12/Vulkan/Metal | 半自研（基于 Unity） |
| HoYoverse Cascade | 自研 Compute + Meshlet | 静态变体 + 烘焙 | DX12/Vulkan/Metal | 全自研 |
| 网易 Messiah 粒子 | 自研 Compute + Hybrid | 编译期变体消除 | DX12/Vulkan | 全自研 |
| 腾讯自研 Cascade | 自研 Compute + GPU Culling | Permutation 预算化 | DX12/Vulkan/Metal | 全自研 |
从表格可以看出，2026 年的自研粒子引擎有两条路径：第一条是基于 UE5 / Unity 做深度定制（适合大多数工作室），第二条是从零自研（适合资金充裕、视觉要求极致的工作室）。两者的工程取舍核心都围绕"变体管理"——变体越多，灵活度越高，但 compile time 与 memory pressure 也越大。
GPU 粒子在 PC / 主机上是一等公民，但在移动端（Mali / Adreno / PowerVR）有大量坑。下面是 2026 年的主流取舍：
移动 GPU（Apple / Mali / Adreno）都是 TBDR（Tiled-Based Deferred Rendering）。在 TBDR 上，粒子的"全屏 quad + alpha blend" 会触发 framebuffer read，每像素多 8–16 字节带宽开销，4K 分辨率下一帧可能多 30–60 MB 带宽。主流解法是 "把粒子先渲染到一张 tile 上，tile 内 alpha blend，再 resolve 到主 framebuffer"——这本质上是把粒子转成 deferred transparency。
WaveActiveSum、WaveActiveBallot 在 DX12 SM6.0 / Vulkan 1.2 都已普及，但在 Mali / Adreno 上需要 SM 6.0 wave 模拟（部分老 GPU 仍需 fallback）。工程实践是用 [[wave_size(4)]] 显式指定，避免 driver 假设错误。
NVIDIA / AMD 的 wave size 是 32，ARM Mali 是 16/8，Apple GPU 是 32。粒子内核要按 wave size 调 numthreads，避免 32 thread group 在 Mali 上浪费一半 lane。
移动端粒子池一般限制在 32k–128k 粒子，远小于 PC 的 256k–1M。这意味着移动端特效需要更严格的 LOD——远距离粒子用更简单的 mesh + 更小的粒子池。
下面是移动端粒子 vs PC 粒子的关键差异表：
| 维度 | PC / 主机 | 移动端 |
|---|---|---|
| 峰值粒子数 | 256k–1M | 32k–128k |
| Wave size | 32 | 8/16/32 (GPU 异构) |
| 带宽预算 | 50 GB/s+ | 8–25 GB/s |
| 渲染路径 | Forward+ / Deferred | Forward / Forward+ |
| 变体数 | 200+ | < 50 |
跨平台的工程取舍核心是 "按 GPU 特性降级"——同一个 emitter 在高端 GPU 上启用全部模块，在低端 GPU 上禁用湍流、降低粒子数、关闭软光、降低分辨率。这是 2026 年的工程共识：粒子的跨平台不是"一份代码走天下"，而是"一份数据 + 多份变体"。
PC 端可以用 RenderDoc / PIX / Razor / superluminal 全套 GPU 抓帧工具，但移动端几乎都没有等价方案。Apple Metal 的 Xcode GPU Capture（Xcode 15+）是移动端唯一靠谱的 GPU 帧抓取工具，能抓到 compute pass 与 render pass 的全部时间戳，但只能连真机调试。Mali / Adreno 的 GPU profiler 都需要厂商私有工具链（如 Mali Streamline、Adreno Profiler），抓帧流程长 5–15 分钟，且无法像 PIX 那样逐 pass 拆解。这是 2026 年移动端粒子调试的最大痛点——profile 难、bug 难定位、性能难量化。主流应对策略是"在 PC 端先 profile 到 OK，再迁移到移动端做端到端验证"，把移动端调试成本压缩到最后的 20%。
当 GPU 驱动不支持 compute shader 路径（如 WebGL2、老 OpenGL ES）时，粒子系统必须有 fallback CPU 端路径。2026 年的工程实践是维护一个轻量级 CPU 粒子 runtime（同 API、同数据布局、同发射语义），仅在检测到不支持 compute shader 时启用。这种 "single source of truth, two backends" 的设计让同一份 emitter 描述可以跨平台无缝切换，避免"移动端看不到特效"的体验降级。
把前面四节装配整合后，对游戏性能工程有六条可直接落地的推论：
推论 1：把粒子系统从 CPU 端搬到 GPU 端，5–10 倍性能提升是下限。在《黑神话：悟空》《赛博朋克 2077》《战神：诸神黄昏》的实际工程数据里，CPU 端粒子从 50ms/帧 降到 GPU 端 5ms/帧 是常态。性能提升主要来自三处：消除 CPU/GPU 同步、消除顶点缓冲上传、消除 draw call overhead。
推论 2：变体管理是 GPU 粒子工程的二阶问题。第一阶问题是"能不能跑"，第二阶问题是"变体怎么管理"。变体越多，灵活性越高，但 PSO 预热越慢。工程实践是把变体数控制到 50 以内，超过这个数就用 material function + static switch 编译期消除。
推论 3：ring buffer + free list 是必备基础设施。任何 GPU 粒子系统都需要 ring buffer + free list，否则 allocator 开销会击穿性能底线。这是 2026 年所有自研粒子引擎的共识。
推论 4：跨平台路径需要 HLSL→SPIR-V→MSL 三层 cross-compile。自研粒子引擎的 compute shader 必须能跨平台，否则就会被绑定到单一 GPU 厂商。
推论 5：移动端的 TBDR 带宽墙是粒子渲染的硬约束。任何全屏 alpha blend 都要走 deferred transparency，否则 4K 分辨率下带宽会成为瓶颈。
推论 6：Render Graph 集成是渲染层的最佳实践。把粒子 pass 注册到 Render Graph 的 pass group 里，自动处理 buffer transition，避免手动 ResourceBarrier 的负担。
这六条推论不是"理论结论"，而是 2026 年主流工作室的工程共识。下面是六条推论对应的可执行 checklist：
| 推论 | 可执行项 |
|---|---|
| 1. CPU→GPU 5–10x | 把所有 Update Particles 从 Tick 搬到 Async Compute |
| 2. 变体数 < 50 | 用 Material Function + Static Switch Parameter |
| 3. ring buffer + free list | 固定大小 + GPU 端 InterlockedAdd 维护 |
| 4. HLSL→SPIR-V→MSL | 用 DXC + SPIRV-Cross 三层 cross-compile |
| 5. 移动端 TBDR | 粒子先渲染到 tile 再 resolve |
| 6. Render Graph | 把粒子 pass 注册到 pass group |
推论 7：粒子系统是引擎"工程债务"的主要来源之一。在 5 年期项目里，粒子系统的代码量通常占整个渲染模块的 15–25%，但性能问题占比往往超过 40%。原因是粒子发射器的"行为契约"非常难形式化——美术可以通过模块编辑器快速组合新效果，但每加一个新模块就意味着新增变体、新增内存路径、新增跨平台分支。工程债务是粒子系统的隐性税。2026 年的主流应对是"模块审核 + 变体预算"——每个新模块必须经过 TA 审核、给变体预算分配上限（默认 5 个），超出预算的模块要走"复用现有模块组合"的路径而非新增。这条工程纪律能把粒子系统的变体爆炸控制在设计阶段，避免后期重构。
推论 8：粒子与 gameplay 的耦合点必须契约化。Gameplay 代码触发粒子（"刀剑命中"、"技能释放"）时，调用的不是"emitter 实例"，而是"effect handle / ID"。effect handle 关联到当前可用的 emitter 实现（可能是 GPU 版本，也可能是 CPU fallback），并通过参数表传入。这条契约让 gameplay 代码完全不知道粒子系统的内部细节，可以在不动 gameplay 的情况下替换整个粒子实现。这是 ECS 架构在粒子系统里的应用——把粒子系统当作独立 subsystem，对外只暴露数据驱动的接口。
尽管 2026 年的 GPU 粒子工程已经相当成熟，但仍有五个未解决或半解决的问题：
第一，碰撞精度与确定性。GPU 粒子的"碰撞"在复杂几何体（曲面、软体）下精度仍然有限，且跨帧 deterministic 难保证。对竞技类、对战类游戏来说，粒子碰撞的"视觉一致性 vs 网络确定性"仍是 trade-off。
第二，长寿命粒子的内存增长。寿命 > 60 秒的粒子（如远景云、星空）会让粒子池持续增长，没有"永久池 vs 临时池"的成熟抽象。
第三，AI 驱动的粒子参数生成。2026 年开始出现用 LLM 自动调参（"生成一个适合赛博朋克氛围的火 emitter"）的尝试，但工程上还没有稳定的工具链。
第四，神经辐射场（NeRF）/ Gaussian Splatting 的 VFX 集成。把 3D Gaussian Splatting 当作粒子来渲染，在 2026 年还是研究阶段，尚未进入商业引擎。
第五，端侧 LLM 驱动的粒子参数实时调试。理论上可以用端侧 LLM 根据 gameplay context 实时调整粒子参数（如"紧张场景下火焰更剧烈"），但实际工程链路尚未打通。
这五个局限在 2026 年的工程实践中只能部分绕过，没有银弹。读者在做技术选型时要把这些局限写进风险管理表。
把全文拆成可执行的 9 步工作清单，供引擎开发者 / TA / 图形程序员参考：
Particle Update Time 排序），top 5 优先做 GPU 化。Particles::Spawn 等），方便后续调试。这 9 步走完，6 个月内可以完成一套自研或深度定制的 GPU 粒子系统。后续的迭代主要是 emitter 库的丰富（火焰、烟雾、爆炸、魔法、自然现象）、跨平台覆盖、调试工具完善。
回到开头那个问题：实时粒子与 VFX 工程的代际跃迁，本质上是"CPU 逐粒子 → GPU 数据流驱动"的范式迁移。这条迁移路径的工程契约已经在 2026 年定型——四元组 + ring buffer + Render Graph + 跨平台编译。剩下的是把它落地到自己的项目里，把产能、数据所有权和性能三者统一在一个装配里。
最后再补一条工程纪律：粒子系统要避免"功能丰富 → 性能崩溃"的陷阱。许多团队在系统上线初期堆砌大量 emitter 模板（火焰、烟雾、爆炸、魔法、自然现象各几十种），导致变体数、shader compile time、内存压力同时爆炸。正确做法是"小而精 + 可复用"——保持 emitter 模板库在 30–50 个核心模板以内，每个模板有清晰的复用场景（如"火焰核心"可在篝火、爆炸、灼烧伤害里复用），新需求优先用现有模板组合而非新增。这样既能保证视觉丰富度，又能控制工程债务。这是 2026 年所有成功工作室的共识，也是 GPU 粒子系统能持续迭代 5–10 年的关键。
Engine/Source/Runtime/Niagara/, GitHub Mirror, 2024.com.unity.visualeffectgraph, GitHub Mirror, 2024.Conversation
0 条