Scroll-Scrubbed GLB Walk Cycle — Free GSAP ScrollTrigger + Three.js Skeletal Animation

Most "scroll-controls-a-3D-model" demos rotate a static mesh. This one goes a step further: it loads a real glTF model with an embedded, artist-authored skeletal walk-cycle animation, and scrubs that actual animation clip — bones and all — directly from scroll position, frame by frame, forward and backward, while a visitor can still freely orbit the camera by dragging at any moment.

A real AnimationClip, not a fake one

The loaded Fox sample asset ships three baked animation clips (Survey, Walk, Run) as part of the .glb file itself. The snippet picks whichever clip's name matches /walk/i, falling back to the first available clip if the asset's naming ever changes, and builds a THREE.AnimationMixer around it with mixer.clipAction(clip).play(). The action is deliberately left unpaused: Three.js's internal pose evaluation skips a paused action even when it's driven by setTime(), not just its own per-frame advance — and since the render loop below never calls mixer.update(delta), there's no automatic playback to guard against pausing in the first place.

`mixer.setTime()` is the whole trick

A normal Three.js animation loop calls mixer.update(delta) every frame, advancing playback at real-world speed. This snippet never does that. Instead, ScrollTrigger's onUpdate calls mixer.setTime(progress * clipDuration) — setting the mixer to an exact point inside the clip's own duration, computed straight from scroll progress. Scroll down and the fox walks forward, one bone-pose at a time; scroll back up and the exact same walk cycle plays in reverse, because setTime doesn't care about direction or elapsed real time, only the value you give it.

Object-space animation, camera-space orbiting — no coordination needed

Scroll only ever touches the mixer's internal clip time. OrbitControls only ever touches the camera's position. Neither system reads or writes anything the other owns, so — exactly like the turntable rotation version of this idea — there's no flag, no pause-on-drag handler, no handoff logic required at all. Drag the canvas mid-scroll and the walk cycle keeps scrubbing exactly as scroll dictates, from whatever new angle you chose.

A named, honest fallback if the model fails

If GLTFLoader can't fetch the .glb (offline, CDN outage, blocked request), the real error is logged to the console and a simple placeholder cone stands in, so the scene never silently renders empty. The HUD progress bar and frame-percentage label still work regardless, since they read directly off scroll progress rather than off the model.

Zoom is opt-in, not a hijacked scroll wheel

OrbitControls' built-in wheel-zoom is deliberately turned off (controls.enableZoom = false) — left on, it calls preventDefault() on every wheel event over the canvas, silently swallowing the page scroll this whole demo depends on. Zoom is reimplemented as two explicit, opt-in gestures instead: a vertical slider next to the canvas, and Ctrl/Cmd + scroll wheel (the same convention embedded Google Maps and most map widgets use). Both call the same setZoomDistance() helper, which clamps to controls.minDistance/maxDistance and keeps the slider in sync no matter which input triggered the change.

Customizing it

Swap in any .glb with a baked AnimationClip — the /walk/i clip-name matcher and the mixer.setTime scrubbing logic work unchanged for any skeletal or morph-target animation. Pair it with scroll GLB camera flythrough for the checkpoint-touring variant of this same GLB-plus-scroll family, or scroll-scrubbed GLB turntable for the simplest version.