The shell on the homepage is solved in your browser

The structure at the top of the homepage isn't an animation someone keyframed. When the page loads, a Web Worker builds a shell mesh, hands it to tinyfem, the C++ finite element library behind Elementarium compiled to WebAssembly, and asks it for the first eight natural modes. What you see are the eigenvectors it returns.

Building the model

Each model is a parametric surface sampled on a grid. Every grid cell becomes a mitc4shell element, and the supports are ordinary Dirichlet boundary conditions:

const domain = new fem.Domain()
domain.add_material({ id: 'M', type: 'linear_isotropic_elastic', E: 30e9, nu: 0.2, rho: 2500 })
domain.add_section({ id: 'S', type: 'plane', thickness: 0.09 })
domain.add_nodes_flat(ids, coords)
domain.add_elements(elements)
domain.add_bcs(bcs)

const problem = new fem.ModalAnalysisProblem(domain)
const { frequencies } = problem.solve(8)
const shape = problem.mode_shape_bulk(0, ids, [fem.DofId.Ux, fem.DofId.Uy, fem.DofId.Uz])

The barrel vault is supported on end diaphragms (rigid in their own plane, $u_y = u_z = 0$), the way the Scordelis–Lo roof is. One extra pinned node stops it sliding along its axis.

Drawing the result

Mode shapes are normalised so the largest nodal translation is 1, then uploaded as vertex attributes. The vertex shader adds $\mathbf{u}\,\sin(\omega t)$ to the rest position, and the fragment shader colours $|\mathbf{u}|$ with the same jet colour map Edubeam uses, in discrete bands like a post-processor's contour mode.

Real frequencies span an order of magnitude, so the animation speed follows $\log_2(f / f_1)$. Higher modes still oscillate visibly faster, and none of them turns into a blur.

Why bother

Because it's the shortest honest answer to "what do you do?" Open the page and the solver runs on your own machine.