PopcornFX version 2 introduces a couple of radical changes compared to version 1

If you are familiar with v1.x, here are highlights of the main differences:

Node-based edition

No more stack of evolvers and spawn scripts, everything has been switched to node-based, which opens the possibility to create reusable templates that encapsulate complex behaviors in easy-to-use nodes.

No more explicit storage / particle fields

There is no more explicit storage: all data flows through wires, and the runtime figures out what it needs to store.

This makes the construction and wiring of an effect faster, more natural, and more dynamic, as you can very quickly change behaviors and try different options without having to manually declare a bunch of “storage” elements to hold your data.
The runtime figures that out for you, and as it is now implicit, it allows for far greater optimizations than were possible in the old paradigm.

It also allows some higher-level concepts to work much more naturally, such as derivative nodes that can automatically compute velocity from position, or multi-update-rate graphs, which will “just work” by flipping a switch on some nodes, instead of having to manage excessively complex storage changes this would normally require.

Explicit storage: Particle fields in v1.13	Implicit storage: Simulation graph in v2.0

No more spawn / evolve sections

A single nodegraph shows the whole particle simulation pipeline, spawn, evolve, and render.

This is pretty different from other node-based realtime VFX tools, which include separate spawn, evolve, and render sections, as we had in v1.

It makes a crucial difference for encapsulation and reusability of custom behaviors though: It means you can very easily create a template (sub-graph) that encapsulates all the spawn, evolve, and even render nodes required for a custom behavior. So for example if you make a “flocking” template, it will appear as a single node in the graphs using it, but will contain everything needed for initialization and updates, instead of forcing the user to drop and link together multiple pieces in different sections.

renderers, spawn script, and evolvers in v1.13	Simulation graph in v2.0, update-rate visualization (with color deficiency mode) blue is spawn, orange is evolve, green is render.

Scripts

v2 has a script node, however, there are some changes to what you can access from scripts, due to the higher-level changes in v2.

• No more ‘spawner’ namespace. There is no more global notion of a ‘spawner’ in the nodegraph, you need to extract spawner data from event payloads.
• New ‘self’ namespace. It contains all particle-related functions and variables.
• New ‘effect’ namespace. It contains functions such as effect.isRunning().
• No more global ‘Life’ and ‘Age’ values, no more particle fields. The only hardcoded value left is ‘self.LifeRatio’, but we encourage you to use the ‘LifeRatio’ template in the core template library.
• No more event functions available from scripts, events have to use nodes.

Scripts now also have a simple experimental autocompletion system. It does not yet detect and process the script input and output pins, the locally declared variables, and the member functions of sampler objects passed to the script, but will complete all the other available functions and namespaces:

Events

Events were used in v1.x to trigger other particle layers from scripts or predefined conditions (such as “OnSpawn”, “OnDeath”, or “OnCollide”).
They were hard to work with, there was no way to see the event connections between layers, and sending data across events was painful.

Events in v2.x have been vastly improved, and are now used extensively. They are the base of particle emission, and event connections between layers are now crystal clear, taking the form of wires between nodes.

Performance of events has also been improved by an order of magnitude.
v1.x was already efficient, v2.0 blasts even more !

Native in-editor seamless CPU / GPU simulation

Unlike the v1.x editor that only supported CPU simulation, the v2.0 editor can now run GPU sims natively, in parallel with CPU sims, like it would in the final runtime / game.

Note: The GPU simulation is still an ongoing work in progress.

Advanced debugging and profiling tools

In v1.x, there was already a fair deal of useful debugging and profiling tools. However, switching to node-based has opened up a door on a whole new landscape of helpful tools, such as seeing the data values on each node’s output pins when debugging selected particles, inspecting data ranges, seeing detailed and easy-to read per-instruction and per-node timings, searching for some data patterns in the selected particles, and more.

Extensive rendering API support

Unlike the v1.x editor that only supported D3D9 rendering, the v2.0 editor natively supports D3D11, D3D12, Metal, OpenGL, and Vulkan.

Multiplatform editor

Unlike the v1.x editor which only supported Windows, the v2.0 editor runs on Windows, MacOsX, and Linux.