DEV Community: NixieFX

Make campfire wind reproducible before tuning the camera

Almast — Wed, 14 Oct 2026 12:02:03 +0000

Disclosure: AI created this tutorial, source and synthetic scene for a NixieFX marketing assignment. The numeric checks and browser captures described here ran locally with nixie-fx 0.1.17 and Three.js 0.185.1. The review record consists of AI source inspection and actual runtime checks; no human code-review signoff is claimed.

A campfire ember test becomes hard to compare when the camera, seed and elapsed time all change between captures. This example holds those inputs steady and changes the initial X velocity. The result is a modest stream of particles that rises and drifts to one side of a synthetic log marker.

The demo has Right and Left wind options, a replay button, a fixed-time inspection button and scene disposal. It uses a real exported NixieFX effect with a Three.js adapter. Wind here means an authored initial velocity bias. It does not mean a fluid simulation or a changing force field acting on every live particle.

The effect has a small, explicit budget

The emitter uses a 0.35 by 0.05 by 0.35 spawn box, emits at 24 particles per second, and gives particles a two-second lifetime. Its maximum capacity is 56. Each ember is a small unlit procedural billboard. Depth testing is enabled and depth writing is disabled so the transparent particles do not write an opaque depth surface.

The upward velocity ranges from 0.7 to 1.1 units per second. Z ranges from -0.16 to 0.16. For the Right variant, X ranges from 0.22 to 0.62. For Left, X ranges from -0.62 to -0.22. These are demonstration units. Their physical interpretation depends on the host scene's scale.

The original export validates before the host creates a derived preview definition. Keep the package versions and the exported source in the handoff. Replacing the effect file without replacing its manifest can invalidate the bundle's identity checks.

Load the bundle before constructing the instance

Fetch the manifest and its referenced effect files, then give those parsed values to loadVfxExportBundle. Pass requiredBackend: "three3d". The loader verifies the export structure and support information; fetching arbitrary JSON and hoping the renderer accepts it loses that check.

The complete source includes the loading path and the authored project. This excerpt focuses on the wind variant after a verified effect has been selected:

import { normalizeThreeVfxEffect } from "nixie-fx/three";

const definition = normalizeThreeVfxEffect(exportedEmbers);
const velocity = definition.emitters[0].initializeParticle.velocity;
velocity.min[0] = rightWind ? 0.22 : -0.62;
velocity.max[0] = rightWind ? 0.62 : -0.22;

const embers = vfx.createEffect(definition, {
  position: [0, 0.16, 0],
  seed: 42,
});
// Preview inspection only. Do not seek on every animation frame.
embers.seek(1);
embers.pause();

During normal animation, the host advances vfx.update(deltaSeconds) once per frame and renders its scene. The inspection action seeks to one second and pauses. It makes the comparison reproducible without capturing the stream at an arbitrary wall-clock moment.

Compare the output at the same simulation time

The local numeric check created both variants with seed 42 and sampled at one second. Each contained 23 live particles at that sample. The mean X position was approximately +0.207 for Right and -0.209 for Left. Those values describe this particular fixture and update schedule. They are not a performance measurement or a claim about an arbitrary game's wind model.

The camera stays at the same oblique angle for both captures. A fixed camera prevents a view change from making the wind reversal appear larger or smaller. A front view remains available for inspection, but it should be treated as a separate check.

Stop and release the effect with the scene

The replay action removes and destroys the previous instance before creating another. Scene disposal cancels the animation callback, disconnects the resize observer, destroys the VFX renderer and disposes host geometry and materials. The demo also releases its texture store, although this particular ember effect uses no texture file.

That ownership split matters when a scene contains imported assets. An effect instance does not automatically own every resource supplied by the host. Release the resources your host created when that scene ends, and avoid destroying shared assets still used elsewhere.

What this example establishes

The export has no validation errors and the active Three.js ember instance reports no unsupported features in the local check. The example does not exercise collision, authored lights, trails, complex material graphs or PixiJS visual equivalence. Turning those settings on would require another support and runtime check.

If you use a three js particle editor for the authored effect, the NixieFX Three.js runtime reference explains the adapter and instance controls. Keep the wind values, seed, sample time and camera position in the review record. That small amount of context lets another developer reproduce a visual disagreement before changing the effect.

Download the reproducible fixture source.

Put a Three.js landing ring at a world position

Almast — Tue, 13 Oct 2026 07:33:43 +0000

Disclosure: This article and demo were generated by an AI coding agent for a NixieFX marketing task. The scene is a synthetic runtime fixture. Review the technical details in your own scene before production use.

A teleport landing cue should stay attached to its world location as the camera moves. Its radius should also follow the scene's scale. A screen overlay can look convincing in one screenshot while failing both conditions.

This example uses an exported particle burst on the XZ plane, positioned at [1, 0.04, -0.5]. The host offers three cameras and three uniform scales so those assumptions can be checked directly. It implements the cue, not teleport movement or collision detection.

Caption: Actual local browser capture at scale one. The floor grid and center marker are host geometry.

Author a ring that matches the coordinate convention

The landing-ring effect targets three-world-3d. One burst emits forty particles, with a maximum capacity of forty-eight and a lifetime of 0.85 seconds. Continuous emission is zero. The spawn shape is circle, radius one, with radius thickness zero.

In the pinned runtime, circle emission lies in local XZ. The supplied definition leaves spawn rotation at zero; no quarter-turn is needed to put it on the floor. Initial vertical velocity is 0.08 units per second. The particles are small unlit cyan billboards with depth testing enabled and depth writing disabled.

The project uses NixieFX 0.1.17 and Three.js 0.185.1. Do not assume another version or backend interprets every setting identically. The export's support report is part of the integration input.

Load the compiled effect

The supplied src/bundle.js imports the compiled manifest and exported effects, builds an effectsByPath map, and calls the official loader. It requires the three3d backend and the requested effect ID before returning the definition.

const bundle = loadVfxExportBundle(
  { manifest, effectsByPath },
  { requiredBackend: 'three3d', requiredEffectIds: ['landing-ring'] }
);
const effect = bundle.effectsById.get('landing-ring');

The loader consumes compiled export envelopes. An authoring file and a compiled effect are different inputs. This asset uses the built-in procedural billboard, so it needs no texture provider.

Place and replay one instance

The host already has a scene, camera, and renderer. It creates one VFX renderer and replaces the previous instance before replay:

const vfx = new ThreeVfxRenderer({
  scene, camera, captureDebugTransforms: true
});
let instance;

function replay(scale) {
  if (instance) vfx.removeEffect(instance, true);
  instance = vfx.createEffect(effect, {
    position: [1, 0.04, -0.5],
    scale: [scale, scale, scale],
    seed: 42
  });
}

Advance vfx.update(deltaSeconds) once per host frame, then render the scene. The fixture caps individual steps at 0.05 seconds and skips simulation while the document is hidden. These are host choices, not a guarantee about simulation time during backgrounding.

The 0.04-unit offset is chosen for this floor and marker. A real landing surface may need a different offset, surface orientation, or slope handling. The example does not solve placement on arbitrary terrain.

Measure rendered scale in world space

The local check exposed a useful distinction: getParticleDebugTransforms() reports sample positions before the instance root's scale. Comparing those positions directly with a desired world radius gives the wrong measurement.

For the actual rendered centers, the fixture takes each debug matrix's translation and applies the instance root's world matrix:

const positions = instance.getParticleDebugTransforms().map(t =>
  new THREE.Vector3()
    .setFromMatrixPosition(new THREE.Matrix4().fromArray(t.matrix))
    .applyMatrix4(instance.root.matrixWorld)
    .toArray()
);

This runs after rendering has updated the world matrices. Debug capture is useful for this diagnostic and can be disabled in production. The check measures distance from the known center in XZ; it does not infer a radius from the apparent size of a billboard on screen.

Check camera, scale, and completion separately

The browser verification covered oblique, top, and low cameras at uniform scales 0.5, 1, and 2, at viewport widths of 1280 and 390 pixels. Each of the eighteen cases recorded forty active particles during the burst. The largest measured radius error was below 0.000001 world units.

After waiting for completion, the active count reached zero. The runtime reported no unsupported features, missing meshes, or missing materials. These observations establish the fixture's placement and lifecycle checks; they are not a GPU timing benchmark or a guarantee of legibility in a production scene.

Inspect the supplied camera screenshots too. The low view compresses the ring's projected footprint, and the top view exposes its distribution. Random positions around a circle do not produce evenly spaced segments, and camera-facing billboards do not form a solid ground decal.

Keep the cue's limits visible

There is no teleport controller, navmesh query, collision response, terrain projection, or light emitted onto the floor. The effect does not write depth, and it uses no bloom postprocessing. PixiJS does not provide the same GPU depth-buffer behavior as this Three.js host.

For a visual particle editor for three.js, the integration decision belongs in the real scene. The NixieFX Three.js runtime reference covers bundle loading and instance transforms used here.

The complete Day 9 source includes the authoring definition, compiled output, host code, and verification script. Open ?mode=ring, change cameras and scales, and replay. On teardown the host cancels animation, disconnects resizing, destroys VFX resources, and disposes its own geometry and materials.

Open the working demo and download the complete source.

Keep a PixiJS hover ember alive while the button has keyboard focus

Almast — Mon, 12 Oct 2026 06:44:26 +0000

Disclosure: This article and demo were generated by a coding agent for a NixieFX marketing task. The code was validated in a synthetic button demo; this is not a production-game capture.

A button can have a hover effect without making hover its only way to communicate. The important state is whether the user is interacting with it: a pointer may be over the button, or keyboard focus may still be inside it after the pointer leaves.

This NixieFX tutorial uses a real HTML button over a PixiJS canvas. The button supplies native keyboard activation and focus. PixiJS renders a decorative ember layer that cannot receive pointer input. The button's layout stays independent of particle bounds.

Start with a small, exported effect

The accompanying source pins nixie-fx to 0.1.17 and pixi.js to 8.19.0. Its hover-ember authoring effect uses a box emitter, 22 requested particles per second, a 0.65-second lifetime, and a hard capacity of 24. Initial velocity moves particles upward in screen coordinates. These are authored values, not a performance claim.

The demo uses an exported manifest and compiled effect JSON. It calls loadVfxExportBundle with requiredBackend: "pixi2d", checks the backend support report, then creates a PixiVfxRenderer with a separate parent container.

The estimated steady population is about 14 particles before discrete emission and fade behavior. The live counter is the observation to inspect. Capacity is an upper bound, not the number that should be visible every frame.

Combine hover and focus as independent inputs

Do not stop the effect on every pointerleave. A keyboard user might still have focus on the same button. Conversely, losing focus should not stop the effect if a pointer remains over it.

let hovered = false;
let focused = false;
let instance = null;
const motion = matchMedia('(prefers-reduced-motion: reduce)');

function sync() {
  const wanted = (hovered || focused) && !motion.matches;
  if (wanted) {
    if (!instance || !instance.isActive) {
      if (instance) vfx.removeEffect(instance, true);
      instance = vfx.createEffect(effect, { seed: 42 });
    }
  } else if (instance) {
    instance.stop();
    vfx.removeEffect(instance, true);
    instance = null;
  }
}

button.addEventListener('pointerenter', () => { hovered = true; sync(); });
button.addEventListener('pointerleave', () => { hovered = false; sync(); });
button.addEventListener('focus', () => { focused = true; sync(); });
button.addEventListener('blur', () => { focused = false; sync(); });
motion.addEventListener('change', sync);

This excerpt assumes the verified effect and renderer are already available. The complete source includes loading, position updates, disposal, and statistics. Its button click handler increments a demonstration counter; connect the existing game action in a real UI.

The focus ring remains visible whether motion is allowed or not. Particles are decoration, not the only indication that the button can be activated. On touch devices, the native button still works without requiring a hover state.

Resolve layout coordinates each frame

The native button is centered in a responsive stage. Its DOM rectangle must be converted into that stage's local CSS-pixel coordinates. The Pixi projection uses one pixel per unit and a downward Y axis.

const buttonRect = button.getBoundingClientRect();
const stageRect = stage.getBoundingClientRect();
instance?.setPosition([
    buttonRect.left - stageRect.left + buttonRect.width / 2,
    buttonRect.top - stageRect.top + buttonRect.height / 2,
    0
]);
vfx.update(Math.min(ticker.deltaMS / 1000, 0.05));

Call the renderer update once per frame. The example caps the step at 0.05 seconds and skips hidden documents. It therefore chooses stable visual continuation over catching up every elapsed wall-clock second.

Stop the decoration and remove its owners

In the pinned PixiJS adapter, stop() clears the effect immediately. This example removes the stopped instance from the renderer and creates a fresh one on re-entry. It does not claim the Three.js adapter's graceful-completion API is available here. During teardown, remove event listeners and the ticker callback, destroy the VFX renderer, and destroy the Pixi application and its canvas.

The reduced-motion setting prevents fresh emission. If it changes while particles are alive, the example clears them immediately. A static focus ring remains available.

What this example does not transfer to PixiJS

The recipe uses a supported 2D billboard effect without file textures, custom materials, trails, or scene lighting. It does not implement GPU depth occlusion or a 3D collision response. A successful export is not evidence that every editor option will render identically across backends.

The NixieFX PixiJS particle-effects guide is the assigned reference for the integration. Use the exported support report for the actual authored effect and keep the installed package version with the source.

Reproduce and inspect

Run the supplied demo in hover mode. Tab to Continue, activate it with Enter, move the pointer away while focus remains, then move focus away too. Check that particles clear without disabling the button's existing action. Repeat with reduced motion enabled and at a narrow viewport.

Open the working demo and download the complete source.

Keep a PixiJS item reveal out of the layout calculation

Almast — Fri, 09 Oct 2026 08:52:04 +0000

AI disclosure: This tutorial and its sample code were prepared with AI assistance. It is a local implementation recipe, not a device-performance benchmark.

A rarity reveal should draw attention to an item without moving the item card. The common trap is to let the particle container participate in the bounds used to size or center the interface. The effect expands, the measured bounds change, and the card appears to jump.

The sample uses a fixed card, a preloaded crystal icon, and a separate effect layer. The item and its rarity label remain in the layout container. Particles are siblings of that container rather than children whose bounds determine its position.

Actual local fixture capture (1424 × 1343 image). This synthetic scene shows the integration and counters, not a device-performance benchmark.

Load before enabling the reveal

The accompanying source includes an original SVG item icon and the compiled rarity-reveal effect. The particle effect uses procedural circles, so its export has no file textures. That distinction matters: an empty effect asset list does not mean the UI image can be loaded after the first click.

Keep the replay button disabled until the export loader accepts the bundle and Assets.load resolves the item image. Failed fetches should leave a visible error and a disabled trigger. In a game using textured particles, preload every referenced particle texture into the provider as well.

For readers working with a pixi js particle editor, the NixieFX PixiJS integration guide supplies the export and renderer context. This example focuses on the host layout boundary rather than reproducing the guide's reward fountain.

Reserve the layout and add an independent layer

Here is the core arrangement from the supplied runnable source. app is an initialized PixiJS application and effect is the validated exported effect.

const content = new Container();
content.position.set(450, 210);
app.stage.addChild(content);

const card = new Graphics()
  .roundRect(-150, -110, 300, 220, 20)
  .fill(0x243146);
content.addChild(card);

const texture = await Assets.load("./item.svg");
const icon = new Sprite(texture);
icon.anchor.set(0.5);
icon.position.set(0, -25);
content.addChild(icon);

const effectLayer = new Container();
app.stage.addChild(effectLayer);
const vfx = new PixiVfxRenderer({
  parent: effectLayer,
  projection: createPixiVfx2dProjection({
    originX: 0, originY: 0, pixelsPerUnit: 1, yAxis: "down"
  })
});

function reveal() {
  const p = content.toGlobal({ x: 0, y: -25 });
  return vfx.createEffect(effect, {
    position: [p.x, p.y, 0], seed: 42
  });
}

The full source handles button state, bundle loading, diagnostics, and teardown. Import createPixiVfx2dProjection from nixie-fx/pixi alongside the renderer. The demo explicitly selects pixels and a downward Y axis to match Pixi UI coordinates. The adapter's default projection points Y upward, which would place a positive UI Y coordinate above the canvas. If the host transforms the effect layer, also convert the point into its local space before spawning.

Give repeated triggers one policy

The demo replaces an existing reveal before creating the next one. This avoids stacking bursts when a player taps repeatedly. A different game might deliberately overlap reveals, but then it needs an explicit capacity budget and cleanup policy.

Use the Pixi instance's documented lifecycle rather than assuming that it has the Three.js adapter's controls. The supplied host advances the renderer once per ticker callback, removes inactive instances, and removes the callback before destroying the renderer. Pause in this example gates the update call; it is a host control.

Check the card and the effect separately

The diagnostics compare the card's width and height and the content position against their baseline. In the local browser check, three trigger actions left the tracked maximum bounds delta at zero. An active reveal showed 18 particles and no missing texture, material, or sub-emitter references. After completion, the effect count returned to zero.

That is evidence about this fixed-size fixture. It does not establish correctness for a responsive inventory, transformed parents, or a scrolled panel. Test those cases with the host's actual coordinate conversion and layout rules.

The capture above shows an active frame with the item, rarity text, and diagnostics visible. The source's zero-delta counter proves only the properties it measures. A visual comparison still needs to check the label baseline, card alignment, and whether particles obscure the item.

Limits to keep visible

The export validation has no errors, warnings, or blockers for this recipe. There are no mesh emitters, custom materials, sub-effects, or particle file textures to resolve. Adding any of those features changes the integration obligations.

This Pixi UI example does not demonstrate GPU depth-buffer behavior, 3D lighting, or automatic responsive positioning. It also does not claim that every authored editor setting has equivalent behavior in every backend. Inspect support reports for the actual export and preserve any reported limitation.

Try the runnable item-reveal fixture and download its editable source. The source includes assets/src/pixi.js, the authoring effect, compiled bundle, and original item image.