Physics Animation (Blender)

Three Animation Types, One Scene

For significant events (maximum MMI ≥ 5.0), Intensity Lab automatically generates physics-based MP4 animations. All three types share the identical Blender scene — object properties, physics constants, camera, rendering — and differ only in which displacement record drives it: View all animations →

• Simulated — the nearest significantly-affected city, driven by an empirical synthetic (or a BBP physics-based seismogram when available — see Physics-Based Simulation (BBP)).
• Observed — the nearest seismic station with MMI ≥ 5.0, driven by a real recorded waveform (see Observed Seismic Station Data).
• Ground motion decay — three virtual sites at increasing distance from the epicenter, showing how shaking intensity falls off with distance.

Four different producers — the empirical synthetic, BBP, real observed waveforms, and the decay interpolation — all hand off the same displacement-array shape (t, disp_x/y/z, pga_g, pgv_ms, pgd_m, duration) to the Blender scene — the scene itself has no idea which one produced its input.

Empirical Synthetic Ground Motion

When a physics-based BBP seismogram is not available, each simulated animation begins with a synthetic accelerogram generated from the site's ShakeMap-interpolated Peak Ground Acceleration (PGA). The signal is constructed at 100 Hz using a Saragoni-Hart time-modulating envelope applied to filtered white noise:

• Envelope shape: e(t) = t² · exp(−5t/duration) — builds up then decays naturally
• Kanai-Tajimi filter (ω_g = 15.7 rad/s, ζ = 0.6) applied via IIR to reproduce soil frequency content typical of firm California sites
• Filtered signal scaled so peak absolute acceleration matches the target PGA in m/s²
• Two independent horizontal components: X-axis at 100% PGA, Y-axis at 70% PGA with a different random seed
• Double-integrated to displacement (acceleration → velocity → displacement) using trapezoidal integration with linear detrending to prevent drift

The displacement time series drives the scene: the floor and table are passive kinematic rigid bodies that receive location keyframes directly from the computed displacements at each animation frame. A one-second gravity settle precedes the shaking; a one-second smooth return follows.

Ground Motion Decay Animations

The decay animation illustrates one of the most important principles in seismology: shaking intensity decreases with distance from the earthquake source. A single 4-panel video is produced showing the wave propagation map alongside table-shaking scenes at three distances simultaneously.

Layout (1280×720, 24 fps):

Site selection: Three virtual sites are placed at 5, 50, and 100 km from the epicenter along a bearing toward the nearest reference city more than 60 km away.

Ground motion at virtual sites: When driven by BBP (see Physics-Based Simulation (BBP)), all three sites come from one simulated rupture. Otherwise, PGA is bilinearly interpolated directly from the USGS ShakeMap grid at each site's exact coordinates — the same interpolation method used to estimate shaking at gazetteer cities — falling back to the nearest stored city estimate within 75 km, then to GMPE-predicted PGA. Reading PGA straight off the ShakeMap grid typically shows a 5–10× range in PGA between the near and far sites for a moderate-to-large event, rather than the compressed range GMPE point-source predictions produce for deep or large earthquakes — a physically realistic difference the decay animation exists to show.

Frame synchronization: The map's wavefronts are timed to a peak-shaking velocity measured from the same three ground-motion records that drive the panels (a least-squares fit through the origin, hypocentral distance vs. peak-arrival time), so the map and the panels cannot disagree — they are the same data. Fronts expand from the fault trace (a stadium shape), not from the epicenter as a point, using the same fault length and strike the rupture used.

Object Properties & Physics

Object dynamics are simulated using Blender's rigid body physics engine (20 substeps/frame, 20 solver iterations). Active objects respond freely to the moving floor and table:

Object geometry is stored as OBJ mesh files baked into the worker Docker image at build time. All meshes are re-centered and scaled to real-world dimensions before physics is applied. Regulation bowling pin dimensions (381 mm tall, 127 mm COM height) and USBC mass (1.587 kg) are used. The wine glass uses a Fresnel glass material with IOR = 1.52.

Rendering & Encoding

Scenes are rendered with Blender's EEVEE rasterizer at 854×480, 24 fps, with 8 temporal anti-aliasing samples, screen-space reflections, and ambient occlusion. PNG frames are encoded to H.264 MP4 (CRF 20) via ffmpeg. A text overlay (city name, distance from epicenter, local event time, and an IntensityLab.com copyright watermark) is stamped onto frames via Pillow before encoding.

Rendering runs on on-demand GPU cloud instances. When animations are queued, the system launches an AWS EC2 instance carrying an NVIDIA T4 GPU (g4dn.xlarge), renders the queued scenes, and terminates the instance as soon as the queue empties — a hard lifetime cap terminates it regardless, so an instance cannot be left running by a failure.

The performance difference is roughly two orders of magnitude. A single animation renders in about 6–10 minutes on the T4. The same scene rendered in software on the application server — which has no GPU, and so falls back to Mesa llvmpipe CPU rasterization — takes on the order of 10–14 hours. Observed-waveform animations are the extreme case: because they combine a split-view layout with a measured displacement time series, they never completed within the CPU render timeout at all. GPU rendering is therefore not merely an optimization for that animation type, it is what makes it possible.

GPU capacity is not always available at a given moment, so the system requests a spot instance in each availability zone in turn and falls back to a full-price on-demand instance if spot capacity is exhausted everywhere. Simulated and ground-motion-decay animations retain a CPU rendering path as a last resort, accepting the multi-hour render time; observed animations do not, since CPU rendering cannot complete them, and are instead left queued for a later attempt.