When we talk about an “effect”, it can be a full explosion, a muzzle flash, falling snow, butterflies with complex state-machine logic and scene interactions, or even a smart spell that seeks and follows particles from other effects.

A PopcornFX “effect” in itself is an asset which contains and defines the behavior of various “layers” of particles. Each of those layers represent a specific type of particle, with their own behavior and rendering properties. All layers, when put together, form the final visual “effect”.

At its core, a particle in PopcornFX v2.0 is only defined by its simulation graph, which will tell how it should initialize, update, and be rendered.

Internally, a particle is a simple data container, with various compiled bytecodes attached, to update the state of that data.

Once the game engine loads an effect, it will need to “instantiate” it to get it simulating and drawn onscreen. For example, a single explosion asset will be instantiated multiple times in different places in a specific scene. We refer to these as “effect instances”.

Effect production pipeline

The effect asset lifetime from creation to final application goes through 3 main stages we refer to as the effect production pipeline.

Effect creation

Main roles affected in production: VFX artist

The VFX artist authors the source effects in the PopcornFX editor. These effects are saved as .pkfx files, containing all original nodes, scripts, and meta-data necessary for edition.

Baking

Main roles affected in production: Toolchain engineer, Integrator

The source .pkfx files then need to be baked down into a runtime-optimized version. These baked .pkfx files contain the compiled optimized nodegraphs, and compute-shader bytecodes for GPU simulation. The original nodes and scripts are stripped away.

Note: Baking is mandatory but it is up to the integration to decide how to handle it, and whether or not to expose it to the VFX artists.

For instance, the UE4 PopcornFX plugin performs baking silently when hot-reloading the effect. In most cases, VFX artists do not have to care or even think about baking.

For the rare cases where this is not the case, baking paths can be configured in the editor’s project settings, and an asset can be manually baked via a command-line tool, or via the editor using Ctrl+B or contextual menus.

Runtime (C++ SDK)

Main roles affected in production: Integrator, engine / rendering programmer

Baked effects are then loaded by the PopcornFX runtime running into the game engine, instantiated in a scene, and simulated on the CPU and/or GPU.

Once the current frame has been simulated, the integration into the game-engine can access the current state of the simulation, collect then render the particle streams.

Note: All rendering is up to the game engine to allow for a deeper integration into its own shaders and rendering pipeline. The C++ SDK provides an example rendering framework the integrator can build upon.

More details are available in the C++ SDK documentation.

Runtime (Level editor)

Main roles affected in production: Game / level designer, VFX artist

The integration into the game engine can expose all user-defined parameters of the effect to the level editor so that game or level designers can place, trigger, tweak, and morph effects to their liking.
Effects can interact two-way with gameplay scripts and code, by feeding back high-performance simulation events and data into game logic.