Three.js Scroll Crystal Bloom — GSAP Gem Cluster Reveal

The Three.js Scroll Crystal Bloom snippet grows a cluster of gem-like shards out of a single seed crystal as the visitor scrolls — one small IcosahedronGeometry sits at the core, and roughly twenty elongated shards scale up around it in a staggered sequence, each catching light differently as MeshPhysicalMaterial refracts and reflects across its facets. The whole bloom is driven by one scrubbed number from GSAP's ScrollTrigger, exactly like the scrub pattern used in the scroll tunnel snippet, just applied to per-object scale instead of camera position.

Stretched icosahedra as crystal spikes

Rather than modeling custom gem geometry, each shard starts as a plain THREE.IcosahedronGeometry and gets non-uniformly scaled — squeezed on X and Z, stretched on Y — via geometry.scale(0.55, 1.6, 0.55) before it's ever added to the scene. A low-detail icosahedron already has flat triangular faces that catch light like facets; stretching it along one axis turns that same base shape into something that reads as a crystal spike rather than a round gem, with zero extra vertices to manage. The same trick underlies the faceted look in the crystal cluster snippet, though there it's static rather than scroll-driven.

Staggering the reveal so shards bloom in sequence

The naive approach — scaling every shard from the same scroll value — makes the whole cluster pop into existence at once, which looks like a glitch rather than a bloom. Instead each shard stores its own revealAt offset spread evenly across roughly the first 82% of the scrubbed range, plus a revealSpan window over which it grows. Every frame, the shard's local progress is computed as (t - revealAt) / revealSpan, clamped to 0–1, and run through an easeOutBack curve before being applied to mesh.scale. Because each shard reads the *same* global t but maps it through its *own* offset window, scrolling down triggers a cascading bloom and scrolling back up collapses the shards in the exact reverse order — no separate timeline or per-shard tween objects are needed.

Why easeOutBack instead of linear scale

A linearly scaled shard grows at a constant rate and looks mechanical. easeOutBack briefly overshoots past 1.0 before settling, which reads as the shard "popping" into place with a little spring — much closer to how a real crystal facet catching the light suddenly feels present. The overshoot only needs a few lines of cubic math (no easing library required) since the function is evaluated by hand every frame.

Positioning shards on a sphere with quaternions

Each shard's position comes from a random point on a sphere via spherical coordinates (theta, phi), and its orientation is set with mesh.quaternion.setFromUnitVectors(Vector3(0,1,0), dir) so the shard's stretched long axis points radially outward from the cluster's core along the same direction as its position. This is what makes the cluster look like crystals *growing outward* from a shared center rather than a scattered pile of random shapes — the direction used to place the shard is reused to orient it.

Feature-detecting MeshPhysicalMaterial's transmission

Not every three.js build exposes transmission, clearcoat, and thickness on MeshPhysicalMaterial — those properties were added in a later revision. The snippet checks 'transmission' in new THREE.MeshPhysicalMaterial() at runtime and, if present, configures a genuinely glass-like refractive material; otherwise it falls back to a MeshStandardMaterial with low roughness and high metalness that still looks glossy under the point lights, so the demo degrades gracefully rather than throwing on an older CDN pin.

Two colored point lights instead of one

A single light source on faceted geometry tends to leave half the cluster in flat shadow, hiding the very facets the material is meant to show off. A violet keyLight and a cyan rimLight are placed on opposite sides of the cluster, and the key light's position is animated in a slow circle tied to the same scrubbed t, so as the bloom progresses the highlight sweeps across newly revealed shards rather than sitting static. A HemisphereLight underneath provides just enough ambient fill that unlit facets read as dark gem rather than pure black. For a different lighting mood in the same gallery, compare this dual point-light rig to the single directional setup used in the scroll wave terrain snippet.

A live shard counter tied to the same progress value

The HUD's shard count is not a separate state machine — it increments the same loop that drives scale, counting any shard whose clamped local progress exceeds a small threshold. Deriving the HUD from the identical per-frame calculation as the visuals guarantees the number on screen always matches what's rendered, even mid-scroll-scrub.