Keep a PixiJS item reveal out of the layout calculation

#pixijs #javascript #gamedev #webdev

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.

DEV Community