This post looks at that case for a halo drawn behind a character portrait, with a level label underneath and a Continue button below that. I compared four ways to handle repeated triggers and measured what each one does to the label, the particle count and the timing.

Setup for every number below: PixiJS 8.22.0, nixie-fx 0.1.21, headless Chrome 155 with SwiftShader WebGL, a fixed 1/60 s step and fixed seeds. The portrait is a placeholder drawing, not game art.

The scene

Layers, bottom to top:

1. background (#17131f)
2. the halo, in its own Container
3. the portrait, a 56 px radius circle, opaque
4. the label LEVEL n in #ffe7a3, 18 px bold, no backing plate
5. a Continue button

The halo is behind the portrait, so the opaque portrait hides its center and only a ring shows around it. It isn't behind the label, though. The glow's lower edge reaches about y = 220 px and the label sits at y = 182 to 212, so the label is drawn on top of part of the glow. The button starts at y = 236 and never overlaps it.

const haloLayer = new Container(), portraitLayer = new Container(), uiLayer = new Container();
app.stage.addChild(haloLayer, portraitLayer, uiLayer);

const vfx = new PixiVfxRenderer({
  parent: haloLayer,
  projection: createPixiVfx2dProjection({
    originX: 180, originY: 112, pixelsPerUnit: 100, yAxis: "up",
  }),
});

The effect

The halo was authored as NixieFX JSON and exported with npx nixie-fx export .. Two emitters, both one-shot, additive, gravity and drag set to 0 explicitly:

• glow: one particle, 0.9 s lifetime, 1.5 units (150 px) growing to 1.45x, alpha 0 → 0.6 at 20% of its life → 0
• motes: a burst of 16 small particles on a 0.62-unit circle, moving outward at 0.25 to 0.5 units/s, 0.6 to 0.9 s lifetime

nixie-fx validate reported 0 errors and 0 warnings. The export's support report lists the effect as supported on the Pixi backend and on Three, with no unsupported or partial modules, so nothing in this effect is silently dropped. One instance peaks at 17 active particles.

If you're building this kind of effect with a web game particle editor such as NixieFX, the PixiJS particle effects guide covers the export bundle, loadVfxExportBundle and the renderer setup used here. This post only covers what happens after the effect exists.

How the label was measured

For every frame I rendered the scene with the label hidden, read back the pixels inside the label's 120 x 30 box with app.renderer.extract.pixels, and took the brightest one. The scene starts with an opaque background rectangle, because extract only reads what's in the stage. The background colour you pass to app.init isn't part of it, and without the rectangle the halo is measured against transparent black. Then I computed the WCAG contrast ratio between the label color and that pixel.

That's a worst-case number. It treats the single brightest background pixel as if the whole label sat on it. With no halo at all the label measures 14.97:1 against the background.

Four policies

// stack:    a new instance per level-up
live.add(vfx.createEffect(halo, { position: [0, 0, 0], seed: seed++ }));

// restart:  one instance, reset on every level-up
single.reset({ position: [0, 0, 0], seed: seed++ });

// queue:    one instance; extra level-ups wait for the current halo to finish

// coalesce: one instance; level-ups in the same frame merge, and level-ups
//           during a halo request one follow-up halo when it ends

I ran each policy on three trigger patterns: 3 level-ups in the same frame, 5 in the same frame, and 3 spaced 0.2 s apart.

Contrast is the worst frame in each run. The small 10.69 vs 10.39 difference between restart and the others comes from different mote seeds, not from the policy.

Same frame (0.52 s after the level-ups), same effect file. Left: five instances. Right: one.

What each policy actually did

Stack is what you get by default if the level-up handler calls createEffect. The instances are additive and start on the same frame, so their glow alphas add up: the summed glow alpha reached 1.75 with three and 2.92 with five. Three stacked instances already took the label to 4.27:1, just under the 4.5:1 that WCAG asks for normal-size text. With five, the brightest pixel behind the label went from 0.031 to 0.378 relative luminance and contrast fell to 2.01:1. Particle count scaled with it, 17 per instance up to 85.

Restart keeps one instance, so brightness is capped. The cost shows when level-ups are spread out. reset() clears the live particles immediately. With level-ups 0.2 s apart, the glow alpha climbed to 0.556 and dropped to 0 on the next frame, three times in a row. On screen that reads as a blink rather than a celebration.

Queue looks safe in the table, but the player waits. The halos played one after another, about 0.9 s each. In this implementation the label advanced when its halo started, so after five level-ups it read LEVEL 9 while the player was already level 12, and reached LEVEL 12 3.7 s later. If the number is tied to the effect, the effect is now delaying game state on screen.

Coalesce gave one halo for any number of same-frame level-ups, the same peak particle count and contrast as a single halo, and the label shows the real level immediately. For the spaced pattern it played the first halo plus one follow-up, 1.8 s in total, never more than one follow-up however many level-ups arrive.

The coalesce logic is short:

let playing = false, playedFrame = -1, again = false;

function onLevelUp() {
  level++;
  label.text = `LEVEL ${level}`;          // the number never waits for VFX
  if (playing) {
    if (frame > playedFrame) again = true; // later level-up: one follow-up
    return;                                // same frame: merge
  }
  start();
}

function start() {
  single.reset({ position: [0, 0, 0], seed: seed++ });
  playing = true;
  playedFrame = frame;
}

app.ticker.add((t) => {
  frame++;
  vfx.update(t.deltaMS / 1000);
  if (playing && !single.isActive) {
    playing = false;
    if (again) { again = false; start(); }
  }
});

single is created once with autoStart: false. isActive goes false after the last particle dies, which in this effect is about 0.9 s after the reset.

Drawing on top doesn't block taps, but it does cover the portrait

The NixieFX guide notes that a renderer parented to app.stage draws above your UI in normal stacking order. I checked what that means for input by making the portrait tappable (eventMode = "static" with a circular hitArea) and hit-testing two points on the portrait that the glow covers, 0.2 s after a level-up.

With the renderer parented to the halo layer and with it parented to app.stage, rootBoundary.hitTest() returned the portrait for both points. The particle sprites weren't hit-test targets in this setup, so the halo didn't steal the tap.

The pixels are a different story:

Same frame. Input still reaches the portrait in both, but on the right the additive glow is drawn over the face.

So for a halo that should sit behind something, give the renderer its own layer under that thing. Don't rely on low alpha to keep it out of the way.

Limits

• Software WebGL. These are headless Chrome runs on SwiftShader with a fixed time step. I didn't measure frame time or test a phone GPU.
• Worst-pixel contrast is conservative. It doesn't account for font weight, the label's own anti-aliasing, or how people actually read the screen. Use it to compare policies, not to certify accessibility.
• One layout. The glow touched the label because of these sizes. With a label plate, or a halo that ends above the label, stacking would brighten the ring but not change the label.
• Additive blend only. A normal-blend halo would stack differently, and I didn't test it.
• reset() cut the old particles off in this build (nixie-fx 0.1.21). I didn't look for a fade-out option on reset, so treat the blink as what the default call did here.

My recommendation for a portrait halo: decide the trigger policy before tuning the particles, and test the five-level case instead of the single level-up the effect was designed around.

Drafted with AI assistance and reviewed by me. Every number and both screenshots come from the local demo described above.

This post is about why, what the three possible clocks look like side by side, and the one-line fix. Everything below was measured in PixiJS 8.22.0 with nixie-fx 0.1.21 (released 16 October 2026) in headless Chrome 155 on macOS, stepping a fixed 1/60 s clock so every run is repeatable.

The setup

The effect is a shield shatter made in NixieFX, a visual particle editor for PixiJS and Three.js. It's a project file in the editor's JSON format, validated and exported with the nixie-fx CLI, then played by its PixiJS renderer. Two emitters, both one-shot bursts at time 0:

{ "id": "core",   "duration": 0.25,
  "spawn": { "bursts": [{ "time": 0, "count": 1 }], "shape": "point" },
  "initializeParticle": { "lifetime": { "mode": "random", "min": 0.2, "max": 0.2 } } },
{ "id": "shards", "mode": "mesh", "duration": 1.0,
  "forces": { "gravity": 4, "drag": 1.2 },
  "spawn": { "bursts": [{ "time": 0, "count": 28 }], "shape": "circle", "radius": 0.9,
             "rotation": [90, 0, 0], "sphericalDirectionAmount": 1 },
  "initializeParticle": { "lifetime": { "mode": "random", "min": 0.6, "max": 0.95 },
                          "velocity": { "mode": "shapeDirection",
                                        "speed": { "mode": "random", "min": 1.0, "max": 2.6 } } },
  "mesh": { "renderMode": "pixiShard", "template": "triangleShard" } }

(Trimmed: colour, size and rotation curves are left out.) The projection maps 1 unit to 100 px, so the 0.9-unit circle sits on the 90 px shield ring.

Validation passes with one warning, and the export marks the effect partial for the Pixi backend because of it:

warning [unsupported-module] shield-shatter.json:emitters.1.mode: Mesh mode exports as Pixi 2D shard geometry semantics, not true 3D mesh rendering.

In practice that means flat triangle shards, which is what a 2D game wants here.

The hit-stop works the way many games do it. The damage handler sets timeScale = 0 and starts a counter of six real frames (0.1 s at 60 fps). Game logic runs first each frame, then effects. So on the frame the hit lands, the effects already see the freeze.

Three clocks, measured

I ran the same fight three times, changing only what vfx.update() receives:

• ticker: the real frame time, freeze or not
• game: frame time × timeScale, so 0 during hit-stop, including the hit frame
• game + prime: the same, plus one 1 ms step on the new shatter instance when it's created

Particles on screen and the horizontal spread of all particles, per frame after the hit. The first six rows are the freeze.

The 7 particles in the game column are leftovers from the second hit's small chip effect, frozen in place. The shatter itself has zero particles for all six frozen frames.

Why the game clock shows nothing

Two things in the 0.1.21 Pixi runtime combine here. I read them in dist/pixi.js and the numbers above agree:

1. createEffect() resets the instance and draws it, but doesn't simulate. The time-0 bursts haven't fired yet.
2. update(dt) only advances the simulation when dt > 0. With 0, the instance redraws its current state, which is still empty.

So the bursts fire on the first frame with real time, which is the first frame after the hit-stop. The good news: the new instance already reports isActive === true before its first update, so a cleanup loop that removes finished effects doesn't throw it away during the freeze. I logged that check in the run.

The fix: give the new instance one tiny step

let timeScale = 1;
let hitStopFrames = 0;
const live = new Set();

function onShieldBroken() {
  const fx = vfx.createEffect(shatter, { position: [0, 0, 0], seed: nextSeed++ });
  fx.update(0.001);        // fire the time-0 bursts now; update(0) won't
  live.add(fx);
  timeScale = 0;
  hitStopFrames = 6;
}

app.ticker.add((ticker) => {
  const realDt = ticker.deltaMS / 1000;
  if (hitStopFrames > 0 && --hitStopFrames === 0) timeScale = 1;
  updateGame(realDt * timeScale);   // may call onShieldBroken()
  vfx.update(realDt * timeScale);   // reads timeScale after the hit set it
  for (const fx of live) {
    if (!fx.isActive) { vfx.removeEffect(fx, true); live.delete(fx); }
  }
});

The demo steps a fixed 1/60 s instead of ticker.deltaMS; otherwise its loop is this one. The NixieFX guide to PixiJS particle effects wires vfx.update(ticker.deltaMS / 1000) straight to the ticker, which is right until your game gets its own clock. Then the effects should usually share it.

A millisecond is too short to see: at the fastest shard speed (2.6 units/s, 100 px per unit) the shards move about 0.26 px. With the prime, the freeze shows the burst exactly as it starts. The shards sit on the ring with the core flash bright behind them, and everything continues from there when time resumes.

Two other fixes work if you'd rather not touch the instance:

• Start the freeze on the next frame. I measured this as a fourth run: if effects get the hit frame's normal 1/60 s and the freeze starts after it, the shatter shows 35 particles across 186 px and holds there for the rest of the freeze. It changes frame order for everything else that runs after the damage handler, and the effects freeze for five frames instead of six.
• Keep the shield ring drawn until the freeze ends. Then the screen isn't empty, but the break reads as late.

When the ticker clock is the right answer

Some games deliberately keep effects playing through hit-stop, so the impact flares while the characters hold still. The ticker clock does that. The cost is in the table: by the time the hero can move again, 0.1 s of a 0.2 s core flash is already gone, and the shards have travelled from a 186 px spread to 213 px. If the effect was tuned to the beat of the animation, it now finishes a tenth of a second early. That's a design decision, not a bug. Just make it on purpose.

Limits

• One effect, one machine, headless Chrome 155 on macOS, fixed 1/60 s steps rather than real requestAnimationFrame timing.
• The hit-stop counts frames. On a 120 Hz display, six frames is 50 ms. If refresh rates vary, count milliseconds instead.
• I tested the Pixi renderer only. The Three.js renderer wasn't part of this run.
• Neither effect uses sub-emitters, so I didn't check how child instances behave with a zero step.
• The shards render as flat 2D geometry on Pixi, as the export warning says. That's what this effect is meant to be, but don't expect 3D mesh shading from mesh mode on the Pixi backend.

This post was drafted with AI assistance and reviewed and edited by me. All numbers and the image come from the demo described above.

So I built the same burst in both and measured four things: whether the particles can sit between two layers of the Pixi scene, whether a run can be replayed exactly, whether you can read a frame back for a screenshot test, and what each one adds to a production bundle. Some of the results favour tsParticles.

Setup

• nixie-fx 0.1.20, @tsparticles/engine 4.4.0 (plus basic, plugin-interactivity, plugin-emitters, updater-life), pixi.js 8.22.0, Vite 6.4.4
• Chromium 152 on macOS, Intel Core i9-9880H. One machine.
• A 480 × 300 Pixi stage with three layers: a striped background, an empty effects layer, and a "LEVEL CLEAR" card on top
• The burst starts in the middle of the card, so for the first fraction of a second the sparks should be hidden behind it
• Fixed 1/60 s steps and seed 42 everywhere

The effect: a one-shot burst of 120 warm sparks in a 30° cone pointing up, 0.6–0.9 s lifetime, gravity pulling them back down, fading out at the end.

The burst in NixieFX

NixieFX effects are JSON files you author in the editor (or by hand), validate and export with the CLI. The fields that matter here:

{
  "id": "win-burst",
  "targetProfile": "portable",
  "emitters": [{
    "maxParticles": 140,
    "spawn": {
      "bursts": [{ "time": 0, "count": 120 }],
      "shape": "cone", "angle": 30, "radius": 0.1,
      "rotation": [0, 0, 0],
      "sphericalDirectionAmount": 0
    },
    "initializeParticle": {
      "lifetime": { "mode": "random", "min": 0.6, "max": 0.9 },
      "size": { "mode": "random", "min": 0.1, "max": 0.18 },
      "velocity": { "mode": "shapeDirection",
                    "speed": { "mode": "random", "min": 3.5, "max": 5.5 } }
    },
    "forces": { "gravity": 4 }
  }]
}

One gotcha cost me a few runs. I started from an existing impact effect, and its sphericalDirectionAmount was 1. That blends each particle's direction toward "away from the spawn point", which turns a cone into a radial spray. In a 2D Pixi projection it looked like a firework instead of a fountain. With 0 the cone's local +Y axis is up and the burst goes where you'd expect.

npx nixie-fx validate .
npx nixie-fx export .

Validated 1 effect: 0 errors, 0 warnings.
Exported 1 effect to public/vfx.

The export's support report for this effect says pixi2d: supported and three3d: supported, so the same file would also load in a Three.js scene. I didn't render the Three.js side for this post.

The game loads the bundle and puts the renderer in the effects layer, between the background and the card:

import { loadVfxExportBundle } from "nixie-fx/export";
import { PixiVfxRenderer, createPixiVfx2dProjection } from "nixie-fx/pixi";

app.stage.addChild(background, fxLayer, card);

const bundle = loadVfxExportBundle({ manifest, effectsByPath }, { requiredBackend: "pixi2d" });
const vfx = new PixiVfxRenderer({
  parent: fxLayer,
  pixiRenderer: app.renderer,
  projection: createPixiVfx2dProjection({ originX: 240, originY: 205, pixelsPerUnit: 60, yAxis: "up" }),
});
vfx.createEffect(bundle.effectsById.get("win-burst"), { position: [0, 0, 0], seed: 42 });

// in the game loop, in seconds
vfx.update(1 / 60);

The burst in tsParticles

tsParticles 4 is split into plugins. A one-shot burst from a point needs the emitters plugin, which in turn needs the interactivity plugin, plus the life updater:

import { tsParticles } from "@tsparticles/engine";
import { loadBasic } from "@tsparticles/basic";
import { loadInteractivityPlugin } from "@tsparticles/plugin-interactivity";
import { loadEmittersPlugin } from "@tsparticles/plugin-emitters";
import { loadLifeUpdater } from "@tsparticles/updater-life";

await loadBasic(tsParticles);
await loadInteractivityPlugin(tsParticles);
await loadEmittersPlugin(tsParticles);
await loadLifeUpdater(tsParticles);

const options = {
  fullScreen: { enable: false }, detectRetina: false,
  background: { color: { value: "transparent" } },
  particles: { number: { value: 0 } },
  emitters: {
    position: { x: 50, y: 68.33 },            // percent of the canvas
    size: { width: 0, height: 0 },
    startCount: 120, rate: { quantity: 0, delay: 10 }, life: { count: 1, duration: 0.05 },
    particles: {
      paint: { fill: { enable: true, color: { value: ["#fff08c", "#ffb347", "#ff8c26"] } } },
      size: { value: { min: 3, max: 5.5 } },
      opacity: { value: { min: 0, max: 1 },
                 animation: { enable: true, speed: 1.2, startValue: "max", destroy: "none", sync: true } },
      life: { count: 1, duration: { value: { min: 0.6, max: 0.9 }, sync: true } },
      move: { enable: true, direction: "top", angle: { value: 60, offset: 0 },
              speed: { min: 6.3, max: 9.9 }, outModes: "destroy",
              gravity: { enable: true, acceleration: 7 } },
    },
  },
};

Two gotchas here too:

• My first attempt had opacity: { value: 1, animation: { destroy: "min" } }. With min and max both 1, every particle is already at its minimum, so all 120 were destroyed within five frames. The opacity range has to go down to 0.
• life.duration.sync defaults to false, and in that case each particle's duration is the range value multiplied by a random factor between 0 and 1. A "0.6–0.9 s" lifetime then gives anything from 0 to 0.9 s. sync: true keeps it in the range you wrote.

The units differ (tsParticles speeds are pixels per 60 Hz frame, NixieFX uses world units per second), so I didn't try to convert. I tuned the tsParticles speed, angle and gravity until the bounding box of the live particles matched NixieFX's within a few pixels at three times. Offsets from the burst origin, in pixels (up is positive):

Close enough to compare integration. The colours and fade curves are not identical: NixieFX uses a gradient over each particle's life and holds full alpha until 70% of it, while the tsParticles version picks one of three colours per particle and fades linearly.

Result 1: layering inside the game scene

Top row at 0.20 s, bottom row at 0.45 s.

• Left, NixieFX: the renderer is a child of fxLayer, so the sparks are hidden behind the card until they clear its top edge. That's the intended look.
• Middle, tsParticles over the Pixi canvas: tsParticles draws into its own canvas. Stacked over the game canvas, the sparks cover the card and its text. Put it underneath instead and the game canvas, which has an opaque background, hides it completely. Two canvases give you "in front of everything" or "behind everything", not "between the background and the card".
• Right, tsParticles inside Pixi: tsParticles.load() also accepts an OffscreenCanvas as its element. I gave it one and wrapped it in a Pixi CanvasSource and Sprite in fxLayer. That gets the layering right. The cost is that source.update() re-uploads the whole 480 × 300 canvas to the GPU every frame, 576,000 bytes of RGBA, however many particles are alive. At full-screen size on a high-DPI phone that grows fast, so measure it on your target device before shipping it.

Result 2: replaying a run exactly

For screenshot tests and bug reports you want the same frame twice. I rendered each burst twice with the same settings and compared SHA-256 hashes of the PNGs.

• NixieFX: the seed is a createEffect option and the step is whatever you pass to update(). Same seed, same steps: identical pixels at both test times. Seed 43 gave a different frame at 0.45 s. (At 0.20 s every spark is still behind the card, so the frames were identical for both seeds, which is the right answer.)
• tsParticles: there's no per-effect seed, and it drives itself with requestAnimationFrame. But the engine exports two functions that make it testable: setRandom(fn) replaces its random source, and setAnimationFunctions(nextFrame, cancel) replaces its frame scheduler. With a seeded PRNG and a manual clock, two runs gave identical pixels. Without setRandom, two runs differed.

import { setRandom, setAnimationFunctions } from "@tsparticles/engine";

setRandom(mulberry32(42));                       // any () => number in [0, 1)
const pending = new Map(); let handle = 0, now = 1000;
setAnimationFunctions((cb) => (pending.set(++handle, cb), handle), (h) => pending.delete(h));
function tick(ms) { now += ms; const cbs = [...pending.values()]; pending.clear(); cbs.forEach((cb) => cb(now)); }

const container = await tsParticles.load({ element: canvas, options });
tick(0); for (let i = 0; i < 27; i++) tick(1000 / 60);

Both overrides are engine-wide, not per container. If two tsParticles effects run on the same page, they share one random sequence, so adding a second effect changes the first one's particles. NixieFX keeps a separate seed per effect instance.

Result 3: reading a frame back

This one caught me out. tsParticles 4.4 calls transferControlToOffscreen() on the canvas you pass it. After that, canvas.toDataURL() returns a blank image, and canvas.getContext("2d") throws "Cannot get context from a canvas that has transferred its control to offscreen". The pixels are still reachable through the container:

const blob = await container.canvas.renderCanvas.convertToBlob({ type: "image/png" });

If you have visual tests that grab the canvas with toDataURL(), they'll silently compare blank images after upgrading. NixieFX draws into the Pixi renderer, so the usual app.canvas.toDataURL() (with preserveDrawingBuffer: true) or Pixi's extract API works.

Result 4: bundle size

I bundled only the imports each version of the demo uses with esbuild 0.25.12 (--bundle --minify --format=esm), with pixi.js marked external because the game already ships it:

The minimal tsParticles build is about 25 KB smaller gzipped than the NixieFX Pixi runtime. If bundle size is the deciding factor and the effect can sit on top of everything, that matters.

Which one to use

tsParticles fits well when the particles decorate a web page rather than a game scene: backgrounds, confetti over a DOM layout, hover and click interactions (it has a large set of interaction plugins), presets you can drop in, and no build or export step. It doesn't need a game engine at all. It's also far more widely used: in the week before I wrote this, npm counted about 460,000 downloads of @tsparticles/engine against about 1,300 for nixie-fx, so answers are easier to find.

NixieFX fits better when the effect is part of the game: it renders inside your PixiJS (or Three.js) scene graph, so it layers with sprites and UI; it steps on your game loop's delta; each effect instance has its own seed; and effects are authored in an editor and shipped as an export bundle with a per-backend support report. The NixieFX runtime docs cover the export bundle, the support report and both renderer adapters.

Limits of this comparison

• This NixieFX vs tsParticles comparison covers one effect, one machine and one browser. I didn't measure frame time, because CPU timings from a hidden test tab weren't trustworthy and GPU cost is the interesting part for both.
• The two bursts are matched by measured bounding boxes, not by identical physics, colour or fade.
• The OffscreenCanvas-as-texture route is something I made work for this test, not a documented tsParticles integration. Its per-frame upload cost is computed from the canvas size, not measured on a device.
• I only rendered NixieFX's PixiJS side. The Three.js claim rests on the export's support report.

Reproduce it

1. Install the versions above in a Vite project, with a 480 × 300 pixi.js app and a stage of background, an empty Container for effects, and a card on top.
2. Put the NixieFX JSON in a project folder with a vfx-editor.prj, then run npx nixie-fx validate . and npx nixie-fx export ..
3. Load it with the NixieFX snippet above. Load the tsParticles options with the seeded setRandom and the manual tick() clock.
4. Step both 12 and 27 times at 1/60 s, capture the Pixi canvas and the tsParticles renderCanvas, and compare.

This post was drafted with AI assistance and reviewed and edited by me. All numbers and the image come from the demo described above.

So I ran a test that only changes one thing: where the fire stands. Same effect file, same seed, same step size, and a camera that keeps the same offset from the fire. If an ember effect doesn't depend on placement, every number measured relative to the fire should match at every position.

The scene record

These values are all you need to reproduce a frame:

const SCENE = {
  seed: 3141,
  dt: 1 / 60,
  steps: 180,                     // frame at t = 3.0 s
  viewport: [360, 360],
  cameraOffset: [0, 1.5, 5.2],    // added to the fire position
  cameraTargetOffset: [0, 1.2, 0],
  fov: 45,
};
const FIRES = { origin: [0, 0.15, 0], camp: [14, 0.15, -9], far: [120, 0.15, 60] };

Versions: nixie-fx 0.1.20, three r185, Chrome on a Mac, with Node used for the same measurement and identical numbers.

The embers are one looping emitter: world simulation space, an upward cone (14°, radius 0.18), 32 per second, 1.6 to 2.4 s lifetime, additive, yellow to deep orange with alpha fading to zero. I exported five variants of that emitter. The wind vector is the same in all of them, [1.1, 0, 0.35] in world units, so the embers should lean toward +X and a little toward +Z.

The "partial" entries all carry the same generic export warning: "validate authored subfields before shipping". That's the step this post is about.

What moved

Mean ember position relative to the fire at t = 3.0 s (x, z in world units):

The first three rows hold. Wind on its own, through either module, doesn't care where the fire is.

The drag and vortex rows don't. At (14, −9) the drag variant already leans the wrong way on X. At (120, 60) the embers are pulled about 11 units toward −X and 5.6 toward −Z, which points back at the world origin and away from the wind. From the gameplay camera, 9 of 68 live embers are still on screen. With vortex the embers spread to a 15-unit radius around the fire and 13 of 63 stay in view.

Why it happens

The motion is evaluated from each particle's age, so I read the externalForces step in the shipped 0.1.20 runtime. The wind part adds wind × ½t² to the position, which is a pure offset. The drag part then multiplies the particle's x and z by 1 − drag × age × 0.15, and the vortex part rotates x and z around x = z = 0.

Those are coordinates in the space the particles are simulated in. For a world-space emitter in a renderer added to the scene, that's the scene, so drag shrinks every ember's position toward the world origin and vortex swirls around it. At the origin, "toward the origin" happens to mean "toward the fire's axis", so a test scene there looks right.

Fix 1: mount the renderer on an anchor at the fire

ThreeVfxRenderer takes a parent option. Put the renderer in a group that sits at the fire, and spawn the effect at the group's origin:

const fireAnchor = new THREE.Group();
fireAnchor.position.set(120, 0.15, 60);
scene.add(fireAnchor);

const vfx = new ThreeVfxRenderer({ parent: fireAnchor, camera });
const embers = vfx.createEffect(effect, { position: [0, 0, 0], seed: 3141 });

With this setup, wind + drag gave 0.69, 0.23 at all three positions, the same as the origin row. Vortex gave 0.76, 0.27 everywhere. Panel C in the image is this setup at (120, 60).

The cost is one renderer per campfire. A level with eight fires needs eight anchors, and anything you query from the renderer is in anchor coordinates, so convert with fireAnchor.localToWorld() before comparing against the scene. The constructor options are listed in the NixieFX Three.js runtime guide.

Fix 2: simulate the embers in local space

Setting spawn.simulationSpace to "local" also made the result independent of placement: wind + drag gave 0.64, 0.19 at all three positions, and vortex 0.71, 0.31. That fits a campfire, which doesn't move.

These numbers aren't the same as the world-space version at the origin (0.69, 0.23), so check the look again after switching. I didn't rotate the emitter in this test. In local space, assume the authored wind follows the emitter's axes and check it if your fires are placed with a rotation.

Fix 3: leave drag and vortex off

If the embers only need to lean, externalForces.wind or forceOverLifetime on its own is enough, and both rows above held at every position. Shorten the lifetime if you want the embers to stop drifting sooner.

The repeatability check that makes this test worth anything

Comparing positions only means something if the same inputs give the same frame. I hashed every ember position after 180 steps: seed 3141 gave 64335163 twice, and seed 3142 gave 67c84f16. Each panel was one draw call.

That's also why the camera follows the fire at a fixed offset instead of a fixed point. Same seed, same step, same offset: any difference between two frames comes from the placement and nothing else.

Checklist for embers in a real level

• Write down the seed, step size, frame time, camera offset and fire positions next to the effect.
• Render the effect at the origin and at one real level position, and compare positions relative to the fire.
• If externalForces has non-zero drag or vortexStrength, either anchor the renderer at the fire or switch the emitter to local simulation space.
• After switching space, retune by eye; the numbers shift.
• Rerun the same-seed hash check after every nixie-fx upgrade.

Limits

• The export report didn't flag this. All four wind variants got the same "partial" warning. Nothing in it says drag or vortex depends on placement, so test it rather than relying on the status.
• Tested on Three.js only. The same effect files export for PixiJS too. I didn't run them there.
• One frame time. All numbers are at t = 3.0 s. I didn't check how the gap grows over a longer run.
• Static fires only. I didn't move the anchor or the fire while embers were in flight.
• No lights, bloom or textures. The embers are unlit additive billboards and the image is a raw render.

Whether you shape the cone and colours in a visual particle editor for three.js or in JSON by hand, the test scene should include a fire that isn't at (0, 0, 0). Otherwise drag and vortex look correct in testing and break in the level.

This post was drafted with AI assistance and reviewed and edited by me. All numbers and the image come from the demo described above.

This NixieFX tutorial uses one unlit, additive burst in PixiJS. The supplied source pins pixi.js to 8.22.0, nixie-fx to 0.1.20, and Vite to 6.4.4. Its controls simulate accepted and rejected crafting events. They do not implement a crafting server or update inventory quantities.

Disclosure: Prepared for NixieFX's marketing work with AI assistance. The measurements below come from the supplied local example, not a production game.

Give the spark a small, finite budget

The effect uses one point emitter above the iron-ingot slot. Continuous emission is zero, looping is off, and a single burst emits 18 particles. Lifetimes range from 0.28 to 0.45 seconds. Each particle starts with an upward velocity and a small horizontal spread, then shrinks and fades from pale yellow toward amber.

The critical source settings are:

emitter.loop = false;
emitter.duration = 0.05;
emitter.maxParticles = 18;
emitter.spawn.rate = 0;
emitter.spawn.rateValue = { mode: 'constant', value: 0 };
emitter.spawn.bursts = [
  { time: 0, count: 18, cycles: 1, interval: 0, probability: 1 }
];

The complete source kit includes the normalized authoring JSON, compiled export, runnable demo, and recorded checks. This excerpt shows the emission boundary; it is not a replacement for the complete effect schema. Keep both the numeric rate and its scalar envelope at zero. Setting only one invites confusing differences between the source and the compiled effect.

The stock circle billboard supplies the particle shape. This example needs no file textures, custom materials, or sub-effects. That removes external asset loading from the crafting event path.

Convert the slot anchor into the effect layer

The UI and effect layer are siblings under the stage. The effect layer does not participate in inventory layout. Resolve an anchor 14 pixels above the slot's top edge, convert it through global coordinates, and then convert it into the effect layer's coordinates:

const PPU = 80;
const renderer = new PixiVfxRenderer({
  parent: vfxLayer,
  projection: createPixiVfx2dProjection({
    pixelsPerUnit: PPU,
    yAxis: 'up'
  })
});

function anchor() {
  const p = vfxLayer.toLocal(
    slots[1].toGlobal(new Point(56, -14))
  );
  return [p.x / PPU, -p.y / PPU, 0];
}

The slot is 112 pixels wide, so 56 selects its horizontal center. Pixi's downward screen Y becomes an upward world Y in the projection, which explains the negative sign. Dividing by the same pixels-per-unit value used by the renderer keeps the two coordinate systems consistent.

The anchor is resolved when an accepted event arrives. Moving the panel before the next event therefore places the next burst correctly. Continuous panel movement during an already playing burst needs its own policy; this example does not demonstrate that behavior.

Trigger from the accepted event

Create one instance with autoStart disabled, then reset it only after an accepted event for the intended slot:

const fx = renderer.createEffect(definition, {
  autoStart: false,
  seed: 379
});
const seen = new Set();

function onCraftCompleted(event) {
  if (closed || event.status !== 'accepted' ||
      event.slotId !== 'iron' || seen.has(event.id)) {
    return false;
  }
  seen.add(event.id);
  if (seen.size > 32) seen.delete(seen.values().next().value);
  fx.reset({ position: anchor(), seed: 379 });
  return true;
}

The demo keeps only the last 32 IDs. That is a bounded local guard, not durable network idempotency. The game must own that guarantee. A new accepted event restarts the reused instance, so this design also deliberately avoids overlapping bursts from rapid crafts.

Ordinary playback advances the renderer once per frame:

app.ticker.add(ticker => {
  renderer.update(ticker.deltaMS / 1000);
});

Do not update the instance separately in that callback. The inspection controls stop the ticker and use a fixed 120 Hz clock, so they do not add a second update loop to normal playback.

Check the export and the rendered result

The runtime loads the compiled manifest and effects with loadVfxExportBundle, requiring the pixi2d backend and the crafting-spark effect ID. The game does not load the authoring JSON directly. The NixieFX PixiJS particle-effects guide covers that authoring-to-runtime path.

The source validated with zero errors and warnings. The export reported Pixi support as supported, with no blockers. In the Chrome-hosted example, the 0.10-second inspection showed 18 active particles. At 0.80 seconds it showed zero. Twenty sequential accepted events each peaked at 18 and drained to zero while retaining one effect instance. Repeating the same event was ignored; a rejected event did not trigger a burst.

The transformed-panel check placed the next burst at the moved slot anchor. Missing texture, material, and sub-emitter references were empty, as were unsupported-module and unsupported-feature diagnostics. These are lifecycle and visual checks, not a mobile-device performance benchmark.

Keep the rendering limits visible

No unsupported settings are enabled in this effect. Lit particle shading requires the Three 3D backend; Pixi uses unlit compositing. Pixi depthWrite has draw-order and ink semantics rather than GPU depth-buffer writing. This source disables depth writing and uses no material graph, so it does not establish parity for custom shaders or 3D lighting.

Closing the inventory stops the owning ticker and hides both layers. A new event resets the reused instance after reopening. Final page teardown destroys the renderer and Pixi application, and backgrounding the tab pauses the ticker. Real-editor visual review and mobile-device testing remain pending.

In a PixiJS scene there is no browser layout engine and no Cumulative Layout Shift score. If the item name jumps down the card when the icon arrives, nothing flags it. Your own layout code moved it.

I built the same reveal three times side by side to see which layout decisions actually move things. The setup:

• PixiJS 8.22.0 and nixie-fx 0.1.20 (the NixieFX runtime), Chrome on a Mac.
• Three effects, reveal-rare, reveal-epic and reveal-legendary. Each is a soft glow plus a ring of sparks pushed outward, authored as NixieFX effect JSON and exported with npx nixie-fx export .. The export report marks all three "supported" on the pixi2d backend.
• Three item icons with different sizes on purpose: 96×96, 112×128 and 140×112. Real item art rarely arrives at one size.
• Every measurement uses a fixed 1/60 s step and the same seed, so the numbers are repeatable.

The three columns:

Shift 1: the name moves when the icon arrives

Column A does what a lot of first versions do. The icon sprite starts with an empty texture, the item name sits 14 px under the icon, and when the texture loads, icon.height changes.

// Column A: layout follows the texture
icon.anchor.set(0.5, 0);
icon.position.set(CARD_W / 2, 22);
name.position.set(CARD_W / 2, icon.y + icon.height + 14);

Texture.EMPTY is 1×1, so before the load the name sits at the top of the card. After the load it drops by the icon's height:

The fix is old advice from web layout: reserve the box before the content arrives. Columns B and C give the icon a fixed 120×120 slot and fit whatever texture arrives into it, centred, without upscaling:

// Columns B and C: the slot decides the layout, not the texture
const SLOT = { x: 30, y: 22, size: 120 };
const t = icon.texture;
const s = t === Texture.EMPTY ? 0 : Math.min(1, SLOT.size / t.width, SLOT.size / t.height);
icon.anchor.set(0.5);
icon.scale.set(s);
icon.position.set(SLOT.x + SLOT.size / 2, SLOT.y + SLOT.size / 2);
name.position.set(CARD_W / 2, SLOT.y + SLOT.size + 14);

In B and C the name and the icon centre moved 0 px for all three items. The crown is scaled to 120×96; the compass stays at 96×96 because I'd rather leave a gap than blur a small icon.

The other half of this is not loading during the reveal at all. With a simulated 400 ms delay on the icon request (a setTimeout before Assets.load, not a real network test), the reveal waits 400 ms for the art. The interactive version of the demo loads all three icons with Promise.all before the buttons do anything, so the reveal never waits on the network. The fixed slot is what protects you when preloading misses something.

Shift 2: the card becomes 2,000,000 px wide

This one surprised me. Under each card there's a "Tap to collect" caption, placed from the card's measured bounds. That's a common habit: centre something under a container using its size.

const b = card.getLocalBounds();
caption.position.set(card.x + b.x + b.width / 2, card.y + b.y + b.height + 12);

Before the reveal, every card measures 183×213 px (the 180×210 frame plus its stroke). In columns A and B, the moment the effect is created, card.getBounds() returns this:

x: -999730, y: -999948, width: 2000000, height: 2000000

The caption moved 999,788 px, off the canvas. The bounds jumped on the frame the effect was created, before a single particle had been simulated, and returned to 183×213 on the frame my reap loop removed the finished instance with removeEffect. Column C, with the renderer on its own layer, measured 183×213 the entire time.

The cause is in the runtime, and it's reasonable once you see it. PixiVfxRenderer sets a boundsArea on its emitter containers, and the default is a rectangle from -1,000,000 to +1,000,000 on both axes. PixiJS uses a container's boundsArea instead of measuring its children. That saves Pixi from walking every particle each time something asks for bounds. But if the renderer is a child of your card, the card's bounds now include a 2,000,000 px square.

You'll only notice this if something measures the card: a layout pass, a hit-area calculation, a scroll container, a tooltip anchor. If nothing measures it, the particles render fine inside the card.

There are two fixes, and I measured both.

Option 1: keep the renderer out of the card (column C). Put particles on a layer above the UI and convert the slot centre to that layer's coordinates:

const vfxLayer = new Container();
app.stage.addChild(cardsLayer, vfxLayer);

const vfx = new PixiVfxRenderer({
  parent: vfxLayer,
  projection: createPixiVfx2dProjection({ originX: 0, originY: 0, pixelsPerUnit: 100, yAxis: "down" }),
});

function reveal(card, effect, seed) {
  const p = card.toGlobal({ x: SLOT.x + SLOT.size / 2, y: SLOT.y + SLOT.size / 2 });
  return vfx.createEffect(effect, { position: [p.x / 100, p.y / 100, 0], seed });
}

This assumes vfxLayer sits at the stage origin with no transform. If it's scaled or offset, use vfxLayer.toLocal(p) instead.

Option 2: keep it in the card, but give it a real boundsArea. The renderer accepts a boundsArea option:

const vfx = new PixiVfxRenderer({
  parent: card,
  projection,
  boundsArea: new Rectangle(0, 0, CARD_W, CARD_H),
});

With that, the caption moved 0 px in columns A and B as well. I prefer option 1 for UI: particles usually fly past the card edge, and a VFX layer keeps "what the UI is" separate from "what's drawn on top of it". Option 2 is the smaller change when an effect has to move with a card, for example one in a scrolling list. One thing I did not test: if you enable culling, a tight boundsArea could cull particles that drift outside it.

Alignment proof

Moving the particles to another layer raises a fair question: do they still start where the icon is? I checked it with the runtime's own debug output. getParticleDebugQuads() returns a screen quad for every live particle, and the glow emitter has exactly one particle spawned at the effect origin. For every frame in which that glow particle was alive, in every reveal, I compared its quad centre with the slot centre in stage pixels:

So the layer move costs nothing in alignment, as long as the position goes through toGlobal (or toLocal) instead of being copied from card-local numbers. The crosshairs in the screenshots are drawn from the same slot-centre calculation.

What's supported on the Pixi side

These reveal effects only use colour over life, size over life, velocity and drag, and the export report marks them "supported" on both pixi2d and three3d. If you build your own reveal, check the per-backend report the export writes into manifest.json. When I switched other modules on one at a time in nixie-fx 0.1.20, the export reported these as partial on pixi2d: trails, noise, collision, lights, sub-emitters, texture sheet animation, custom data, external forces, force over lifetime, size by speed and colour by speed. Lights and sub-emitters are blocked on three3d. Partial means "validate the subfields before shipping", not "won't render", but a reveal is a bad place to find that out.

If you'd rather tune the glow and spark ring by eye than by editing JSON, NixieFX has a visual particle editor for PixiJS that exports the same bundle format. The PixiJS particle effects guide walks through loading an exported bundle with loadVfxExportBundle and driving it from app.ticker.

Limits

• One machine, one browser. Chrome on a Mac, fixed time steps. The layout numbers are deterministic, but I didn't test other browsers or devices.
• The network delay was simulated. 400 ms is a setTimeout, not a measurement of any CDN.
• I didn't test resizing or DPR changes. A slot that's fixed in logical pixels can still move if your layout recomputes on resize.
• Culling with a tight boundsArea wasn't tested. See option 2 above.
• This isn't an accessibility pass. A reveal should also respect reduced-motion settings and announce the item as text. I left both out to keep the comparison to layout.

The short version: let a fixed slot decide where the icon goes, and don't let anything you measure contain the particle renderer.

This post was drafted with AI assistance and reviewed and edited by me. All numbers and screenshots come from the demo described above.