Three.js Particle Systems: 100,000 Particles at 60fps

Why BufferGeometry, not Geometry

Three.js's legacy Geometry class stored data as JavaScript objects and arrays — convenient but slow, since every frame spent time reading positions, running JS garbage collection on thousands of Vector3 objects, and re-uploading everything to the GPU. BufferGeometry stores data as typed arrays — Float32Array, Uint16Array — contiguous memory blocks handed directly to the GPU as buffer objects. The advantages: zero GC pressure (no JS allocations in the hot path), a GPU-friendly layout (position data interleaved as [x0,y0,z0, x1,y1,z1, …], exactly what WebGL expects), and partial updates — set needsUpdate = true only on the attributes that changed. The legacy Geometry class was removed entirely in Three.js r125 (2021).

Allocating positions once, mutating forever

Allocate the typed array once, before the loop — three floats per particle for (x, y, z). Never create a new array inside the animation loop:

const COUNT = 100_000;
const positions = new Float32Array(COUNT * 3);   // ONE allocation, reused every frame

for (let i = 0; i < COUNT; i++) {
  const r = 50 * Math.cbrt(Math.random());       // uniform sphere volume density
  const theta = Math.random() * Math.PI * 2;
  const phi = Math.acos(2 * Math.random() - 1);
  positions[i*3]   = r * Math.sin(phi) * Math.cos(theta);
  positions[i*3+1] = r * Math.sin(phi) * Math.sin(theta);
  positions[i*3+2] = r * Math.cos(phi);
}

const geometry = new THREE.BufferGeometry();
geometry.setAttribute('position', new THREE.BufferAttribute(positions, 3));

A common mistake is generating a random point in [−r, +r]³ and rejecting points outside the sphere. That works, but r * Math.cbrt(Math.random()) guarantees uniform volume density rather than surface concentration at the poles. THREE.Points then renders each vertex as a screen-space sprite — the fastest primitive for particles, with no triangles and no indices — and AdditiveBlending makes overlapping particles brighten each other for a classic star or nebula glow.

The animation loop: zero allocations

The golden rule: never allocate inside the animation loop. Declare all temporary variables before requestAnimationFrame begins, then mutate them in place each frame — reading and writing the Float32Array directly, then flipping posAttr.needsUpdate = true once per frame so Three.js knows the buffer changed. The loop modifies roughly 1.2 MB of Float32Array data per frame entirely in JavaScript; for CPU-intensive simulations like SPH fluid or gravity N-body, that logic moves into a GLSL vertex shader instead, letting the GPU update all positions in parallel and eliminating the typed-array copy entirely.

Performance reference

For particle counts above ~500k, or simulations that need per-particle physics like collisions, move all simulation logic into a GLSL compute shader (WebGPU) or a vertex shader with transform feedback (WebGL 2) — the CPU then only issues a single draw call and reads nothing back from the GPU.

Frequently asked questions

Try it live

Everything above runs in your browser — open Particle System and tune emitter rate, lifetime, gravity and colour ramps to build fire, smoke and explosion effects the way game VFX artists do. Nothing is installed, nothing is uploaded.