Portable particle VFX in Three.js: the boundary we settled on

While building NixieFX, we kept running into the same portability problem: the visual effect was not really an asset. It was a collection of renderer-specific emitters, curves, textures, and callbacks embedded in application code. Moving a web game from Three.js to PixiJS—or even reorganizing the Three.js scene—meant rebuilding effects that should have survived the change.

The boundary that has worked best for us is simple: author the effect visually, export it as data, and keep playback behind a small runtime adapter. The editable project and the shipped game bundle are intentionally separate. The exported bundle contains a manifest, one JSON document per effect, and the referenced textures. That makes an effect versionable, reviewable, and usable by build tools without coupling the editor to the game.

For Three.js, the integration loop stays small:

1. Load and validate the exported manifest.

2. Preload the textures through the game's existing asset pipeline.

3. Create the Three.js VFX renderer with the current scene and camera.

4. Spawn effects at game events.

5. Advance the VFX renderer once per frame using the same delta time as the game simulation.

Keeping texture loading outside the renderer turned out to be important. The game remains responsible for caching, URLs, CDNs, and cleanup; the VFX runtime only asks for already-loaded textures while rendering. The same separation also makes it easier to swap the rendering backend later.

Mobile performance shaped the workflow too. Particle count by itself is a poor budget: transparent overdraw is usually the first limit on phones. A few large overlapping sprites can cost more than thousands of small particles. We therefore profile on mid-range devices, cap emitter counts, keep lifetimes short, reuse objects, and avoid allocations in the frame loop. The renderer's pixel ratio should also be capped before optimizing individual effects.

We wrote up the complete mobile-first Three.js example, including scene setup, pointer input, bundle loading, texture preloading, spawning, and cleanup:

https://nixiefx.com/threejs-game-tutorial/

The browser editor is available here:

https://nixiefx.com/editor/

The runtime and source are on GitHub:

https://github.com/azakhary/nixie-fx

I would be interested to hear how other teams keep effects portable across Three.js, PixiJS, and custom WebGL renderers—especially when the same assets must work in both hand-written and AI-assisted codebases.