Scroll GLB Camera Flythrough — Free GSAP ScrollTrigger + Three.js glTF Tour

A single scroll-scrubbed rotation is one thing; touring a model past several distinct, named viewpoints — front, a close-up detail, the side, the back — is a genuinely different problem, because now the *camera's position itself* is what scroll drives, and a visitor dragging to look around wants to control that exact same property. This snippet builds both halves properly: a four-checkpoint camera path interpolated live from scroll progress, and a real, working handoff to manual OrbitControls dragging that doesn't fight the scroll path or snap awkwardly on release.

Checkpoints, not one continuous curve

CHECKPOINTS is a plain array of four { name, pos, look } objects — a camera position and look-at target for Front, Visor, Side, and Back. applyFlythrough(progress) maps the 0-1 scroll progress onto segments = 3 legs of the journey, works out which pair of adjacent checkpoints the current progress falls between, and linearly interpolates both the camera position and its look-at target between them with a small lerpVec3 helper. The result is one continuous camera move built from four fixed shots — you never have to hand-author every in-between frame.

Why dragging and the scroll path genuinely need a handoff

Unlike a demo where scroll spins the *model* and dragging orbits the *camera* (two different transforms that never conflict), here scroll is setting camera.position directly, and OrbitControls also sets camera.position when a visitor drags. Without coordination, both would fight for the same frame. The fix is a small isInteracting flag: controls' own 'start' and 'end' events flip it, and the ScrollTrigger's onUpdate simply returns early — skipping its own camera write — whenever isInteracting is true. A visitor's drag always wins immediately.

A deliberate delay before resuming, not an instant snap

The 'end' handler doesn't clear isInteracting immediately — it starts a 900ms setTimeout first. Release the drag and the scroll path doesn't yank the camera back to its "correct" scroll position the instant your mouse lifts; there's a brief pause that reads as intentional, then control returns to the scroll path smoothly on the next scroll-driven update.

A real, detailed glTF model, not a placeholder

THREE.GLTFLoader fetches Khronos' own "Damaged Helmet" sample asset — a genuinely PBR-textured .glb with visible surface detail (a visor, straps, battle damage) — specifically because a four-checkpoint tour is only worth taking if there's something to actually look at from each angle. If the model fails to load, a named error is logged and a placeholder icosahedron takes its place, so the scene is never silently empty.

Zoom as a multiplier, not an absolute distance

OrbitControls' built-in wheel-zoom is deliberately turned off (controls.enableZoom = false) so a plain scroll always advances the page instead of being hijacked. Zoom is reimplemented as a relative zoomFactor — a slider and Ctrl/Cmd + scroll both nudge it — applied as a radial scale on the checkpoint's own position-to-target offset inside applyFlythrough(), so "zoomed in 30%" means the same thing at every checkpoint despite their very different authored distances. While a visitor is mid-drag, setZoomFactor() instead rescales the camera's *current* offset directly, since the position at that moment came from free orbiting, not from a checkpoint.

Customizing it

Add more checkpoints for a longer tour, change CHECKPOINTS' pos/look values to frame different details, or shorten the 900ms resume delay for a snappier handoff. Pair it with scroll-scrubbed GLB turntable for the simpler object-rotation version of this same idea, or three product viewer for a non-scroll-driven OrbitControls baseline.