Experimenting with stylized particle VFX in Three.js using NixieFX

Showcase
,
1

I’ve been working on NixieFX and testing it with Three.js projects, so I wanted to share some of what it can do.
The main idea is to make particle effects easier to build and tune without having to manually tweak a big set of values in code every time.
You can use it to build things like smoke, sparks, fire, trails, impacts, bursts, magic effects, and other real-time VFX. Each effect can be adjusted through things like emission rate, particle lifetime, velocity, size, rotation, color, opacity, and how those values change over the lifetime of a particle.
You can also combine multiple emitters and layers to make more complex effects. For example, an impact effect could have a fast burst of sparks, a slower smoke layer, and a few larger particles fading out on top.
I’ve mainly been focused on keeping the workflow fast enough that you can try an effect, change a few values, and immediately see how it behaves before using it inside a Three.js scene.

Still improving it and testing different kinds of effects, so I’d be interested to hear how people here normally handle particle VFX in Three.js and what features you usually need.

2

Stylized VFX in Three.js is a huge topic with a lot of interesting history in the ecosystem.

If you’re looking at architectural inspiration or how others have tackled visual tooling and runtime serialization:

  • Effekseer: Great benchmark for node/curve-driven particle pipelines with a dedicated standalone editor.

  • three-nebula: A modern JSON-driven particle system with visual designer tooling built around Three.js.

  • ShaderParticleEngine (SPE): One of the early bridges in the Three.js ecosystem (heavily inspired by Stemkoski’s early particle demos) that transitioned CPU-bound loops into packed GLSL attribute updates.

Modern web particle runtimes gain huge performance wins by keeping emitter curves/timelines deterministic, leveraging compact buffer representations, and pushing updates/instancing directly to the GPU (especially with WebGPU compute shaders entering the picture).

I replied to one of your other showcase posts I believe, and had some questions about providing more samples. A successful engine lives or dies by its demos—the more polished, complete, and visually stunning presets you create, the more traction you’ll get.

90% of consumers just want to drop something in, load a preset, and go. Most developers aren’t dedicated VFX designers; they want an easy path to get splashy juice into their game or app. Take a look at Effekseer’s library of samples (and community presets) to see how far that carries adoption—you’ll probably recognize a bunch of them from various indie games!

*(Refined with Gemini for clarity)*

2 Likes
4

Thanks, this is really useful feedback. Effekseer in particular is a good reference for the kind of workflow I’m interested in, and I’ll take a closer look at how these projects handle serialization, curves, and runtime data. I also agree strongly on the presets/demos point. The editor/runtime can be solid, but if someone has to become a VFX artist before they can get something good-looking on screen, the barrier is still too high. I’m working on expanding the preset/sample library so people can start with a polished effect, drop it into Three.js, and then tweak it instead of building everything from scratch.

On the runtime side, keeping the data compact and making effects deterministic is definitely something I’m thinking about as well. GPU-driven simulation/instancing and WebGPU are interesting directions as nixiefx grows, especially for larger particle counts.

Thanks for the references. This gives me a few good things to study and some clear priorities for the next round of demos.

1 Like