Hold the frame still
The stage pins and the page keeps moving underneath it. Every scroll position lands on a frame that was lit and rendered in advance, so the visitor is scrubbing a film rather than loading a website.
Smooth the value, not the scroll
Your scroll is never intercepted. A single eased number follows it, and everything on the page reads that one number. Trackpad, phone, keyboard and screen reader all keep behaving the way the visitor expects.
Rendered once, replayed forever
The camera move is baked offline. Lighting, reflections and depth of field cost nothing at runtime because they were resolved long before the visitor arrived — which is why it survives a mid-range phone.
Then let it go quiet
The pinned act ends and the page becomes ordinary. That restraint is what makes the spend read as expensive instead of noisy.
What this is
A working reference build, not a mockup
This page is a capability demonstration by Systemcraft. Everything above runs in your browser right now at production dimensions — no video file, no screen recording, nothing faked for the demo. It exists so a build like this can be judged by scrolling it instead of by looking at someone else’s portfolio.
The technique was reverse-engineered from an Awwwards-nominated site by measuring the live page, not by guessing at it. The headline finding: the hyper-real look is a pre-rendered image sequence, and the smoothness comes from easing a value rather than hijacking the scroll. Both are cheaper and more robust than what they appear to be.
What it takes to hold up
- The portrait sequence is rendered, not cropped — the camera re-frames the subject for vertical, because a 3:2 composition does not survive being cut to 9:16. Phones get their own film.
- Frame one is preloaded and painted as a poster; the remaining 110 stream in behind it, so the sequence never blocks first paint. The page is legible before the film is ready.
- Scrubbing during the preload falls back to the nearest frame that has arrived — a lower frame rate, never a blank stage.
- The animation loop suspends whenever the section leaves the viewport, so it costs nothing while the visitor reads the rest of the page.
- Under
prefers-reduced-motionthe sequence is never fetched at all. The poster stands in and the copy still reads — motion sensitivity is handled by not sending the motion. - Frames are served
immutable— 111 requests per visitor is only defensible when they are cached once and never requested again.
Honest about the subject
The object you just scrolled is a brake rotor — one revolved profile, no modelling by hand — rendered in Blender with Cycles: 111 frames a side, two hours and seventeen minutes on a single laptop GPU. It is a deliberate stand-in, not a placeholder: a real part, chosen because it is the kind of thing the businesses this was built for actually sell. A real engagement starts with your subject — the product, the room, the object worth holding still — and the render pipeline swaps in behind it without a line of front-end change.
What that second act was
The part the reference doesn’t do
Everything before this point reproduces a technique measured off a live, award-nominated site. This one goes past it: that site never takes anything apart. Disintegration is a different discipline — real-time geometry and GPU particles rather than pre-rendered film.
The object and its dust read the same noise field at the same coordinate, which is why the dust always appears in the hole it came from rather than drifting off some approximation of it. And nothing is simulated over time: every position, size and opacity is a function of your scroll position alone. That is why scrolling back up reassembles it exactly — the rebuild isn’t a second animation, it’s the same one read backwards.
- Built on WebGL and GLSL rather than WebGPU. The newer compute-shader route is better looking and not yet safe to promise a client whose device list you don’t control.
- Particle origins are sampled off the real mesh surface, so the rebuild lands back on the model — not on a sphere that happens to be nearby.
- Both acts share one scroll chassis. The loop suspends whenever the section leaves the viewport, and under
prefers-reduced-motionthe object is drawn once, whole, and never animated.
What that third act was
Real geometry, lit while you watch
The opening act is a film — beautiful, and incapable of responding to anything. This one is the other trade: actual meshes, lit at runtime, with the camera running along a track. It is what you reach for when a visitor needs to look around a product rather than watch a rehearsed shot of it.
The room is a Draco-compressed glTF, and the decoder that reads it is served from this origin rather than a public CDN — a third-party host in the critical path of your hero is someone else’s uptime and one more DNS round trip before anything appears.
- Vanilla three, not React-Three-Fiber. R3F is faster to write, but it puts a reconciler between the scroll value and the camera, and the whole chassis exists to keep React out of the per-frame path.
- The camera runs a curve, not a line between two points, so the move has the drift and easing of a dolly on a track. A second curve controls what it looks at — aiming at a fixed spot reads as a security camera.
- Lighting is a procedurally generated environment, so metal has something to reflect without downloading an HDR map.
- Neither 3D act loads for a visitor who never scrolls to it. Both are gated behind the viewport, decoder and all.