The implementation uses React Three Fiber and Three.js. Investigating the zoom brought together three problems: preserving small input, choosing the right distance to scale, and loading sharper imagery without interrupting movement. Here are the decisions in the current code, including what they don't establish about performance on real devices.

The first detail is that wheel events aren't interchangeable. The browser supplies a deltaMode alongside deltaY: pixels, lines, or pages. A trackpad can also produce fractional pixel deltas. Treating every event like one mouse-wheel notch throws away information about the gesture.

The normalizer keeps those fractions, converts the units into a common scale, and caps unusually large individual events:

const mode = event.deltaMode;
const pixels = event.deltaY * (mode === 1 ? 16 : mode === 2 ? 300 : 1);
if (!Number.isFinite(pixels)) return 0;
return Math.max(-120, Math.min(120, pixels)) * (event.ctrlKey ? 0.01 : 0.0027);

These are tuning values from this application, not universal browser conversion constants. Ctrl-wheel gets a different gain because desktop trackpad pinches can arrive through that path. I would tune both paths again for a different scene or camera.

The second detail is what “zoom distance” means. Earth has radius one in this scene. A camera distance of 1.2 therefore means a height of 0.2 above the surface. Scaling the full distance from the center gives a very different result from scaling that height, especially close to Earth.

The current target calculation scales height exponentially, then adds the radius back:

export function zoomTargetDistance(current: number, pending: number | null, logDelta: number) {
  if (!Number.isFinite(logDelta) || logDelta === 0) return pending ?? current;
  const base = pending !== null && (pending - current) * logDelta > 0 ? pending : current;
  return Math.max(MIN_GLOBE_DISTANCE, Math.min(MAX_GLOBE_DISTANCE,
    1 + (base - 1) * Math.exp(logDelta)));
}

The base choice matters as much as the exponential. While input continues in the same direction, it accumulates against the pending target. When the user reverses, the next target starts from the actual camera position. Otherwise, reversing can feel like pushing against an invisible queue of unfinished movement.

Easing needs to preserve the final little movement, too. The camera advances using an exponential factor based on elapsed seconds, with the frame interval capped after a long interruption. Once it is sufficiently close, the function returns the target itself. It must not simply abandon the remaining difference: repeatedly discarding tiny movements can make a sequence of valid trackpad inputs appear ineffective.

The twelve zoom tests cover fractional deltas, unit normalization, direction changes, bounds, and completing subpixel targets. They also compare simulated gestures at 60 and 120 updates per second. Those tests pass; they test the mathematics, not whether every MacBook/browser combination feels good. Physical device feedback remains necessary.

There is also an event ownership problem. Our wheel listener captures events within the globe's interaction area before OrbitControls can apply another zoom. It leaves inputs, sliders, and genuinely scrollable panels to their normal behavior. It is not attached to the whole document. A chart sidebar should still scroll when that is what the user is interacting with.

Sharper imagery introduces a separate cost. The globe keeps its base imagery while optional regional detail loads. The detail hook waits for a stable region, then requests day and night atlases. Obsolete requests are aborted; decoded images are disposed when no longer needed. Each atlas is 4096 by 2048 pixels.

Texture decoding is only part of the work. Uploading textures to the GPU can interrupt a frame, so the hook spreads the day and night uploads across separate frames when interaction has stopped. It then blends in the detail. This reduces how much work is scheduled together, but an individual upload can still stall. Unsupported devices or failed requests retain the base imagery. The camera does not wait for detail to finish.

There are deliberate limits: zoom is for countries and regions, not streets. Day imagery uses NASA GIBS Blue Marble; night lights come from historical imagery. Neither is a live satellite feed, and zooming cannot reveal information absent from the source.

Finally, I separated exploration from reading. The homepage leads with statistics, country pages use charts and tables, and the globe has its own route and dynamically imported component. Someone looking up a number shouldn't have to navigate a 3D scene first. Published observations retain their source periods; moving estimates need an explanation rather than an implication that every statistic is measured continuously.

Try the globe. Feedback on close-range zoom, direction changes, and scrolling over panels would be especially useful; please include your browser and input device.