Three.js Interactive Mesh Distortion — Raycasted WebGL Cursor Ripple

The Three.js Interactive Mesh Distortion snippet renders a sphere whose surface visibly bulges outward wherever the visitor's cursor hovers over it, using THREE.Raycaster to find the exact 3D point under the pointer and a per-vertex spring-like easing system to make the bulge rise and settle smoothly — all with core Three.js loaded from a CDN.

Raycasting turns a 2D cursor position into a 3D surface point

A mouse position is just two numbers, X and Y, on a flat screen — but the deformation needs a real point *on the surface of the 3D mesh*. Every frame the cursor is hovering, the snippet converts the pointer's screen coordinates into normalized device coordinates and fires a THREE.Raycaster from the camera through that point; raycaster.intersectObject(mesh) returns the exact world-space point where that ray first hits the sphere's surface. This is the standard technique for any "click or hover on a 3D object" interaction — the same math that powers 3D object picking in games and editors.

World space versus local space matters

The raycast hit point comes back in *world* coordinates, but the geometry's own vertex positions are stored in the mesh's *local* coordinate space (before any rotation or position offset is applied). The snippet converts the hit point with mesh.worldToLocal() before comparing it against vertex positions — skip this step and, the moment the sphere starts rotating, the calculated distances would silently drift out of alignment with where the cursor visually appears to be touching the mesh.

A displacement buffer, not direct position writes

Rather than immediately snapping nearby vertices outward and back, every vertex owns its own entry in a separate displacement array — a single float representing how far that vertex is currently pushed outward from its original position. Each frame, vertices within the hit radius have their displacement value raised (never immediately set, only raised if the new falloff value is *higher* than what's already there); every vertex's displacement then decays by a fixed ease factor every frame regardless of whether it's currently being hit. This produces a smooth rise as the cursor arrives and a gradual, spring-like settle afterward, instead of a jarring snap-and-release.

Falloff by distance, squared for a softer edge

A vertex's push strength is computed as (1 - distance/radius) squared — not a linear falloff. Squaring the falloff means vertices near the very center of the cursor's influence area get pushed hard, while vertices near the edge of that radius taper off much more gently than a straight linear ramp would, producing a rounder, more natural-looking bulge rather than a cone with a hard-edged base.

Displacing along the vertex's own normal, not toward the camera

Each displaced vertex moves outward along its *own* direction from the sphere's center — effectively its surface normal on a sphere — rather than toward the camera or the cursor. This is what makes the deformation read as the surface itself bulging outward in 3D, correctly foreshortened and shaded from every angle, rather than a flat decal-like distortion that only looks right from one viewing direction.

Recomputing normals every frame, again

Just as in the morphing blob snippet, geometry.computeVertexNormals() has to run every single frame the vertex positions actually change — otherwise the MeshStandardMaterial's lighting calculation uses stale normals and the bulge looks flat instead of physically shaded.

Where this technique is used

Cursor-following mesh deformation is the core mechanic behind liquid-metal hover effects, interactive fabric or jelly simulations, and "poke the blob" novelty interactions. Compare its interactive, cursor-driven displacement against the purely time-driven wobble of the morphing blob, or pair it with a custom cursor snippet for a fully cursor-themed page.