It was one bug. If you build meshes with THREE.ExtrudeGeometry, you might have it too.

The setup

I'm building a logo animator that runs in the browser. It takes an uploaded SVG, gives every path its own mesh so elements can animate independently, then extrudes each one:

function extrudeShape(shape, depthLocal, bevelLocal, smooth) {
  let geo = new THREE.ExtrudeGeometry(shape, {
    depth: depthLocal,
    curveSegments: 4 + smooth * 3,
    bevelEnabled: bevelLocal > 0.001,
    bevelThickness: bevelLocal * 0.7,
    bevelSize: bevelLocal * 0.55,
    bevelSegments: Math.max(1, Math.min(6, smooth))
  });
  geo = toCreasedNormals(geo);
  flattenCaps(geo);
  geo.translate(0, 0, -depthLocal / 2);
  return geo;
}

Each shape becomes a mesh, each mesh goes into a group, and the group gets scaled to a fixed design size. It renders beautifully. That's the problem.

What I missed

ExtrudeGeometry bakes the path's coordinates into the vertex data.

A path sitting at x = 800 in your SVG does not give you a mesh at x = 800. You get a mesh at the origin whose vertices are all clustered around x = 800. The position you care about lives in the geometry, not in mesh.position.

So every mesh in my group reported the same position, usually (0, 0, 0), and everything still looked correct on screen.

Three things broke because of it. None of them announced itself.

Rotation pivots about the wrong point. mesh.rotation spins around the mesh's origin. With the coordinates baked in, that origin is the SVG origin, which can sit hundreds of units away from the shape. Setting rotation.z doesn't spin the shape. It swings the shape around the corner of the artboard on a long invisible arm. I had no per-element flip or tumble at all, because every attempt threw pieces out of frame and I'd assumed I was getting the maths wrong.

Anything derived from position comes out identical. I had this:

const dir = ch.position.clone();          // outward direction from centre
ch.userData.dir = dir.normalize();

If every position is the same, every direction is the same. My explode effect had a fallback for that case, which fans the pieces around a circle by index, and it had been taking that path the whole time. The result read as a spread rather than a burst. I spent an embarrassing amount of time adjusting easing curves for something that was never a timing problem.

Spatial sorting collapses to document order. Sorting shapes left to right means sorting by position.x, which here is a list of identical numbers. Any reasonable comparator breaks ties by index:

kids.map((_, i) => i).sort((a, b) => val(a) - val(b) || a - b);

When val returns the same number for everything, the first term is always zero and the tie-break is all that's left. You get SVG document order, which an exporter can write in any sequence it likes. The comparator is fine. It's being fed a constant.

How I actually found it

I dumped the computed metadata for a test logo with 16 paths.

All 16 shared one position. Worse, three ranks I compute from different spatial axes (ox for left to right, oy for bottom to top, oc for centre outward) came back exactly equal to si / (n - 1), where si is the array index.

That's the giveaway. Three measurements taken along different axes have no business agreeing with each other, let alone matching an array index to the decimal. When independent measures line up perfectly, they aren't measuring anything.

The fix

Move each geometry to its own centroid, then push the mesh position out by the same amount:

logoGroup.children.forEach(ch => {
  if (!ch.geometry?.attributes?.position) return;
  ch.geometry.computeBoundingBox();
  const bb = ch.geometry.boundingBox;
  const gx = (bb.min.x + bb.max.x) / 2;
  const gy = (bb.min.y + bb.max.y) / 2;
  ch.geometry.translate(-gx, -gy, 0);
  ch.position.x += gx;
  ch.position.y += gy;
});

The two moves cancel, so the render comes out pixel for pixel identical. Nothing about the image changes. What changes is that position now tells you where the shape is, rotation pivots about the shape's own centre, and directions derived from position are real.

One thing to watch. After re-centring, every shape's bounding box is centred on zero, so it's no use for asking where a shape sits. Grab the centroid into userData while you still have it.

Two other things that bit me

Source units are not design units. My home values are in source SVG units, so a 1036 unit artboard and a 200 unit one are on completely different scales. An offset of 12 is a fifth of the logo on one and 1.4% on the other, which is invisible. So positional amplitudes get written against a ratio:

const u = maxDim / LOGO_WORLD;   // source units per design unit
// then: 18 * u  moves the same visible distance on any artboard

One older preset still uses a bare 12. It's noticeably weaker than the others on large artboards. I've left it there as a reminder.

Don't shuffle with Math.random(). A randomised reveal needs a value that stays put for the life of the object. Math.random() re-rolls every frame, so the animation boils and pieces flicker between orderings instead of revealing. A cheap hash of the index does the job and stays stable:

const hash = (i) => {
  const x = Math.sin(i * 127.1 + 311.7) * 43758.5453;
  return x - Math.floor(x);
};

The general point

Geometry space and object space are different things, and ExtrudeGeometry, TextGeometry and SVGLoader all hand you meshes where the interesting position sits in the wrong one. There's no visual glitch to catch it by, which is why it survives so long. The render looks right while every feature derived from position stops meaning anything.

If a set of independent spatial measures ever agree exactly, go and check that they're measuring anything at all.

I build logoanimation.online, a free browser-based logo animator. This one came out of the 3D side, which extrudes real geometry rather than generating anything. Happy to answer Three.js questions in the comments.