SpinViewer doesn't simulate a 3D object at all. It's an ordered array of photos and a <img src={frames[index]} /> — "rotating" the object is nothing but changing index. Every mechanism in the component exists to make that one src swap feel physical.

On mount, every frame preloads with a plain new Image() before the viewer marks itself ready — that's what makes the first drag instant instead of a flash of broken/loading images:

Once ready, the whole visible surface is one <img> whose src swaps — never a tween, never an opacity cross-fade between two frames. That's why the scene above steps discretely instead of easing: a real frame swap has no in-between state to animate through.

onPointerDown snapshots the pointer's clientX and the current index. onPointerMove does the only math in the whole gesture — how many sensitivity-px ticks the pointer has crossed since then, rounded to a whole step:

With the default sensitivity={6}, a 60px drag steps through 10 frames — drag slower and nothing moves until you cross the next 6px tick, which is exactly why a slow, deliberate drag feels more "mechanical" than a fast flick: the fast flick blurs past ticks the eye never resolves.

autoRotate runs its own tiny requestAnimationFrame loop, independent of the drag math — it accumulates (dt / 1000) * autoRotateSpeed frames per tick and steps index whenever that accumulator crosses 1:

acc += ((t - last) / 1000) * autoRotateSpeed * dir;
if (Math.abs(acc) >= 1) {
  const inc = Math.trunc(acc);
  acc -= inc;
  setIndex((i) => mod(i + inc, count));
}

The loop bails out the moment dragging, reduced, or !ready is true — grabbing the viewer or preferring reduced motion stops it outright, it never fights the user's drag.

One array, one index, one preload pass — drag above, or watch it idle.