PHYS//LAB Documentation

Every panel, every slider, what it does and why. If you only read one section, read Controls.

1. Quick start 2. Mouse and keyboard 3. Transport bar 4. SIM tab 5. FRACTAL tab 6. QUANTUM tab 7. SHOT tab 8. STYLE tab 9. The physics model 10. Verified accuracy 11. Known limitations 12. Exporting 13. If it stutters 14. Common questions

1. Quick start

The whole tool is one HTML file with no dependencies. Nothing to install, nothing to sign up for, and it works offline once loaded.

2. Mouse and keyboard

InputDoes
Left-dragUses the current POINTER TOOL (grab, poke, attract, and so on)
Middle-dragOrbits the camera. Horizontal spins, vertical tilts
Right-dragPans the view sideways without rotating - a second, more discoverable way in than Shift-drag alone, not a duplicate of Middle-drag's orbit the way it used to be
Shift-dragAlso pans, same as Right-drag - whichever's more natural for the mouse in hand
WheelZoom
One-finger drag (touch)Orbits the camera
Two-finger pinch (touch)Zoom
SpacePause and resume
RReset the current scenario
Ctrl+ZUndo the last scene-changing action, up to 24 steps back
Delete / BackspaceRemove the current selection (GRAB tool's box-select)
EscapeClear the current selection
17Pick a pointer tool
T / V / BToggle trails / velocity vectors / the box
HHide the whole panel for a clean view
PSave a PNG

None of these fire while a genuine text field has focus, so typing into one can't also trigger a shortcut by accident - but every slider in this app is an <input type="range">, and that guard used to block ALL of them too, not just real text entry. Finishing a drag on literally any slider anywhere left it focused, which silently killed every shortcut above - Space included - until you clicked something else first. Range sliders don't consume printable keys the way a text field does, so they're exempted now; a genuine text box (the rename field on SHOT's timeline, say) still correctly blocks shortcuts while typing in it

Camera range: horizontal rotation is unlimited, you can keep turning in one direction forever. Vertical tilt runs from 83 degrees above the scene to 83 degrees below it, so you can look down on a galaxy or up at it from underneath. It stops just short of vertical on purpose, because at the exact pole the view would flip over.

3. Transport bar

Sits above the tabs and stays visible whatever tab you are in, because pausing is the one thing you always want within reach.

ControlDoes
PAUSEFreezes the simulation. The camera still works, so you can inspect a frozen moment from any angle
RESETRebuilds the current scenario from scratch and pauses on that starting state, so a change to COUNT (or anything else) is something you get to actually see rather than something that already happened by the time you looked. Picking a scenario for the first time still runs immediately - only RESET holds the freeze-frame, since it's specifically the "I changed something, show me" action
UNDOSteps back through scene-changing actions - spawns, deletes, presets, fractal builds - up to 24 deep. It never touches your palette or display settings, only the scene, so undoing a spawn will not also undo the colour you picked afterwards. Dims when there is nothing left to undo
TIME SCALESpeed of simulated time. This changes the physics timestep, not the frame rate. 0 freezes, 1 is the tuned default every scenario's own pacing was actually built around, 5 is genuine undecelerated real time. Every scenario starts at 1 (this used to read as "0.2", the real number every scenario's real speed was tuned against even then - only the label changed, not the actual pace). The slider itself is deliberately non-linear, not just relabelled: 1 sits at its exact physical midpoint rather than crammed near one edge, the left half of the track covers 0 through 1 (stop through normal) and the right half covers 1 through 5 (speeding up) - so the slow half, the one actually in use most of the time, gets noticeably finer control per pixel of drag than the fast half does, instead of both sharing the same resolution. Click the number to type an exact value directly, same as every other readout here - it reads and writes the real TIME SCALE number (e.g. typing 2 means 2.0x), not the slider's own internal position. Turn it up any time - this is a starting point, not a ceiling

Quick-access bar

A narrow strip of icon buttons on the opposite edge of the viewport, there for the same reason as the transport bar: some controls are needed no matter which tab is open, so they live outside the tabs entirely rather than waiting to be switched to. It duplicates the seven pointer tools plus RECORD and CLEAN MODE - nothing here is unique to it, it is just the same controls kept one click away at all times.

4. SIM tab

Every number a slider shows - here and on every other tab - is also a text field: click it to type an exact value instead of dragging for it. It still can't go past whatever that slider's current min/max is (which for a few controls, like FRACTAL's ITERATION DEPTH, changes depending on what's selected).

Scenario

Always visible in their own bar above the tabs rather than tucked inside one - it's the first choice that matters, so it never has to be dug for. Each one switches on the forces it needs, so picking a scenario also reconfigures everything below. Zoom and pan reset to their defaults on every switch too, rather than carrying over from whatever the last scenario had - without that, GAS or CLOTH's fixed-size world could inherit a zoom level meant for GALAXY zoomed into one arm, landing anywhere from a speck in the corner to badly cropped instead of actually filling the screen. CELLS is the one named exception: its own world is far smaller than the roughly-600-unit extent that shared default assumes, so it gets refit to its own radius instead (see CELLS below) rather than rendering every cell just a handful of pixels across.

Switching away from one of the fourteen ordinary scenarios (the first two groups below) and back resumes it exactly as you left it - bodies, velocities, springs, energy, everything - rather than rebuilding from scratch, so hopping over to check something else and coming back doesn't cost you a run in progress. Only RESET rebuilds fresh; it's the one control that actually means "start over." Each scenario keeps one such snapshot, taken the moment you leave it, not a longer history - visiting all fourteen costs about as much memory as fourteen extra UNDO steps, since it's the exact same body-array shape, and that cost doesn't grow the longer a session runs, only the first time each scenario is visited.

The bar is visually split into three groups, because they really are three different things under the hood, not just differently-labelled presets of the same thing:

ScenarioWhat it is
ORBITA star with satellites on real, mostly-flat orbits - a genuine frost line splits them by size, not a random draw: small rocky bodies inside it, much bigger gas giants beyond it, the same reason our own solar system runs small-then-big outward (rocky material can't hold onto ice or gas close to the star's heat; further out, condensed ices let a core grow massive enough to actually capture gas before the star's radiation clears the disk). Inclination follows the same real split - about 85% of bodies settle within a few degrees of the disk plane, the rest land on a genuinely steep path instead, the same reason our own system has both a flat plane of planets and a handful of wildly-inclined outliers (Pluto, most comets) sharing it. Coloured by mass, so the size split reads as a colour split too
GALAXYA rotating disc that traces a real logarithmic spiral (angle = base angle + a fixed winding rate × ln(radius)) - the actual curve grand-design spiral galaxies follow, not a decorative swirl, the natural shape a density wave winds into when orbital speed stays roughly constant across a wide range of radii. Two arms, offset by 180°, the classic case (Andromeda's own two are the textbook example). Every body's angle is pulled toward its nearest arm rather than pinned to it exactly - tightly near the core where a density wave stays sharply defined, loosely further out where real arms fray into the general disk - and its size follows the same logic real arms are bright for in the first place: gas compressed by the wave forms young, massive star clusters right on the arm's own centreline, so bodies get measurably bigger the closer they land to one, fading back to background size in the gaps between. The centre is a genuine supermassive black hole, not a labelled one - its mass and radius actually cross the same Schwarzschild-radius threshold SINGULARITY's collapse produces, so the same event-horizon render and slow accretion-disk pull already built for that scenario apply here automatically, no separate mechanic needed. In the outer disk, a fraction of "stars" are actually small real systems - a star with 1-3 planets on a genuine local orbit around it, riding along with the star's own path around the core the same nested way a real moon-around-planet-around-star system moves - close enough together to read as one point at the whole-galaxy view, resolving into their own system on zoom. Confined to the outer disk on purpose: the black hole's tidal pull would genuinely strip a system that close to the centre, in this simulation as in reality, and most (not all - genuine n-body encounters with passing stars occasionally work one loose, the same way they would for real) hold together over a normal viewing session. The disk is no longer the whole galaxy: a real central bulge - a dense, roughly spherical, older population, not a flat sheet - surrounds the black hole, orbiting in every direction rather than one shared plane the way the disk does. Further out, seven genuine globular clusters sit in a spherical halo well outside the disk (not confined near its plane either) - each a real, gravitationally bound sub-system of a dozen-plus stars in their own local orbits around a shared, heavier anchor, the same nested-orbit mechanism the disk's own mini-systems use, just built at a larger scale. Both populations use velocity properly corrected for the same softened gravity law every body here actually feels, not the plain inverse-square shortcut that's only accurate at the disk's own, much larger, radii - close to the core or to a cluster's own centre, skipping that correction was measurably wrong enough in earlier testing to fling bodies out of orbit within seconds. Star count went up substantially again (over 1300 bodies at the default, more than double what it was) after "way more intricate" turned out not to be intricate enough - re-profiled properly rather than guessed, since the underlying gravity is genuinely quadratic in body count: this sits with real headroom under the 60fps frame budget, where pushing further measurably didn't. Ordinary disk and bulge stars also carry a real, individual mass spread now, not one shared value - every star used to be exactly identical, which turned out to be the actual reason the whole disk read as visually flat: the colour palette normalises against whatever mass range is actually present in the scene, and with a supermassive black hole sharing that scene, thousands of identical ordinary stars had no spread of their own to register against it, so they all rendered as the same colour and brightness. Real stars have a genuine mass spread for the same underlying reason bigger stars run hotter and bluer while smaller ones run cooler and redder - giving ordinary stars one here is what actually produces a galaxy's colour variety, not a coat of paint on top of it
GASPerfectly elastic spheres rattling around a sealed box
CLOTHA sheet pinned at the corners, with bend resistance and air drag. Drop a STAR or BLACK HOLE onto it (pick the TYPE in POPULATION, then PLACE or +BALANCE) and the sheet actually warps around it - a real rubber-sheet gravity-well demo, not a scripted dent. The mesh itself has no general gravity between its own nodes (measured: that alone would pull neighbouring nodes together roughly as hard as the sheet's own weight does, collapsing it regardless of anything dropped on it) - only a body clearly heavier than an ordinary node (hundreds to thousands of times, exactly what TYPE: STAR/BLACK HOLE already produce) pulls nearby nodes toward itself, genuine softened Newtonian gravity, the same law every other gravity in this simulator uses. COLLIDE is on for this scenario now too (it used to be off) - without it the dropped body just sails through the sheet's plane at full speed and never interacts with it again; with it, the body's own weight settles into the depression its gravity is pulling into and actually rests there, same as the real demo. Checked that turning collision on doesn't change ordinary cloth-alone play at all: node spacing is more than 5x further apart than two nodes would need to be to actually collide, and normal swinging/settling never brings any two within a collision of each other anyway - it only starts doing anything once something is actually dropped on the sheet. Drop an ordinary RIGID body (no TYPE needed) and it genuinely bounces off the fabric and settles - this preset now sets its own bounciness and friction explicitly rather than leaving them at whatever an earlier scenario happened to set, which used to make a dropped body's bounce depend entirely on unrelated prior navigation (anywhere from barely bouncing at all to never settling)
IONSAlternating charges attracting and repelling. SHOW BOX starts off here (WALLS stays BOUNCE underneath, so bodies are still contained) - with FIELD TRACERS on, the wireframe plus every body's glow competed with the radiating/converging streak pattern around each charge, which is the actual point of turning tracers on for this one
CELLSLoosely modelled on Primordial-Particle-System-style artificial life - and now genuinely running its actual mechanism, not just named after it: each cell counts how many other cells sit within a short sensing radius, splits them left and right of its own current heading, and turns toward whichever side has fewer, the real Primordial Particle System turning rule (Schumann/Burtscher) that makes plain self-propelled particles with no attraction force at all self-organise into swarms and clusters. Cells also fuse when they touch and split once they grow past a size limit. Population count is not fixed here - it runs itself, growing and shrinking on its own rather than holding steady like every other scenario. Every cell carries its own inherited traits rather than sharing global constants: a wander speed, a split threshold, and FOODSENSE (below), each blended from both parents (mass-weighted) and given a small random mutation on every merge or split, so lineages drift apart over time instead of behaving identically. Each cell also has energy, which drains slowly while it's alive unless it's actually near food, in which case it gains instead; a cell that runs dry starves and is removed, dimming visibly toward black as it depletes, while a successful merge grants a real energy bonus and a split costs a real chunk of it - actually merging, or actually foraging, is worth something, not just idle drift. Two different population floors keep this from running away in either direction: starvation stops pruning at a hard floor of 3, while merging (a separate mechanism - neglect isn't fusion) is allowed to continue one step further below that, so survivors can't get stuck forever just short of the mass they'd need to split. Cells that are close but haven't actually touched yet grow a faint connecting membrane between them, brightening and thickening the nearer they get - fusion reads as an approach, not an instant switch. A cell added by hand while CELLS is already running (+1 RANDOM, + COUNT, +1 IN BALANCE, or a pointer tool) joins the energy system rather than coming in immortal, and Ctrl+Z restores every cell's energy, wander speed, split threshold and FOODSENSE along with its physics, not just its position and velocity. Seven fixed food nodes sit scattered through the play area, rendered as a small pulsing glow in the same white-core-fading-to-the-palette's-hot-colour language ORGANIC bodies already use. FOODSENSE (0 to 1, starting spread across the whole range so there's something for selection to actually act on) sets how strongly a cell steers toward the nearest one - blended with its own wander, not overriding it - and a cell within reach of food gains energy instead of draining it. Because FOODSENSE is heritable, mutates on every split or merge, and now has a real, measured payoff (energy, which gates both starvation and the merge bonus), a population left running should trend toward better foraging on average over enough generations rather than just drifting its traits randomly the way merge/split mutation alone would - genuine, if simple, natural selection, not a decorative number. Spawn spread and the halo containment radius used to be 320/560 - loose enough that each cell's own wander jitter and starting velocity easily outran the old cohesion force, so the population measurably drifted out into a thin shell pressed against the halo (measured: every cell's distance from centre converging to ~561-566 within 15 simulated seconds) instead of actually clustering, which is also why merges were rare (~3% of pairs overlapping at any moment) - not a rendering problem at all, whatever the merge/blur tuning. Both numbers are now 2.3x tighter, which gives cells enough real proximity to actually sense each other under the turning rule's short radius in the first place, and CELLS' own camera zoom is refit to match (see the note under "Scenario" above) so cells close enough to fuse also render large enough - roughly doubled on screen - for ORGANIC style's shading to actually read. Cohesion itself used to be plain gravity (every cell attracting every other, G:140) rather than the turning rule described above - simple, but gravity pulls the whole population toward one shared centre of mass regardless of where food actually is, and measured directly with a union-find over which cells sit close enough to render as fused, real runs collapsed into a single 30-40+ cell mass within under a minute, on every random seed tested, however healthy the population looked at first ("cells w ogóle się mashują w jeden i jest najgorzej jak było"). Swapped for the real Primordial Particle System turning rule instead, plus a genuine short-range separation force pushing overlapping cells apart - CELLS runs with COLLIDE off (the organic overlap is part of the look), so nothing else stopped several cells occupying the exact same point once anything, food-seeking included, pulled them toward it. Measured across 5 random seeds over a full 180 simulated seconds, the largest fused blob at any point stayed at 1-3 cells (briefly 4-5, only at the initial spawn instant), against gravity's 15-41 over the same runs. ORGANIC's merge path also draws three smaller offset blobs instead of one dominant circle now, so even a single cell that hasn't touched another yet gets a mildly lumpy, amoeba-like outline post-blur instead of a mathematically perfect disc (measured: silhouette radius's coefficient of variation roughly 2.5x higher than a plain circle at the same settings). That outline's own edge used to read as properly out of focus rather than organic-but-crisp - the metaball blur-then-threshold pass (see GLOW/ORGANIC MERGE, STYLE tab) had a wide alpha transition band that measured out to a genuinely soft ~12-13px edge at default settings; a first pass narrowed that band without touching the blur radius itself, which helped but didn't finish the job - the real remaining cause turned out to be the blur radius (MERGE SOFTNESS) itself, at 8px large enough relative to a cell's own on-screen size that its alpha field never actually plateaued except right at dead centre. The gooey composite's fake shine (brightening toward white based on that same continuous, still-blurred alpha, meant to read as a glossy highlight near a fused seam) was picking that up and smearing a smooth brightness gradient across nearly the entire visible disc instead of just its rim - measured directly on one isolated, non-touching cell: a dome shape peaking at the centre with no flat interior anywhere, at the old default. MERGE SOFTNESS is now 2 by default (still adjustable, 1-20) - the same isolated cell now shows a genuine flat brightness plateau across most of its interior with the falloff confined to the outer few pixels, and two cells still bridge into one shape at any gap up to roughly their own radius apart, so the actual fusing behaviour didn't shrink even though the haze did. Eating used to only refill energy, which meant the sole path to actually growing toward a split - and so the sole path to net population growth - ran through merging with another cell first; a cell that foraged well its whole life but never crossed paths with another one never reproduced at all, and measured over a real two-minute run, starvation alone (a pure population loss with nothing on the eating side to offset it) was enough to trend the whole colony toward extinction. A cell at food now also grows, slowly, toward its own inherited split threshold - foraging has a reproductive payoff of its own, not just a survival one. The rate needed real measuring, not guessing: anything from 0.05 up ran the population to the population cap and pinned it there within a minute or two; 0.02 was the value that held a genuine, unpinned oscillation (roughly 10-40 cells) across every random seed tried
SINGULARITYA few massive stars with real scattered orbits, so they actually cross paths and collide, plus far more numerous debris (360-440 depending on COUNT, up from the old 80-240 - its debris renders pricier per body than STAR FORMATION's dust, since its radius sits past the point ORGANIC style starts drawing two extra gradient blobs per body, so this is the actual profiled ceiling, not an arbitrary bump) given genuine circular velocity around the cluster instead - a proto-disk built to survive the stars' collapse rather than fall straight into it. Fusing on contact conserves momentum and mass exactly on every merge, and (MERGE FLASH, FORCES tab, off by default) can flash a real, expanding, fading burst right at the contact point the instant it happens - sized by how much mass was actually consumed, so a debris grain and a genuine star don't read as the same size event. A first version was one soft glow, which read as cheap with nothing else happening; the version after that added debris thrown outward as sparks but drew the core itself as a handful of smooth, overlapping gradient blobs, which under real testing read as "paint-ish" rather than an actual burst. Rebuilt around the same visual language STAR FORMATION's own ignited stars already use rather than inventing a new one: a small, dim core plus 8-20 genuinely small points (not blobs) scattered around it, each flickering on its own independent beat - the identical two-frequency twinkle() function an ignited star's own glow already runs on, reused rather than duplicated, so a merge reads as a real, alive spark rather than a smooth pulse breathing in and out. Debris still gets thrown outward as short comet-trail sparks, now thinner and with a shorter trail than the first version, each carrying its own flicker too. Every count and every alpha value scales with how much mass was actually consumed - more, brighter, longer-lived detail for a genuine star-mass collision, barely a flicker for an ordinary debris grain settling into the disk - with the per-particle brightness deliberately backing off as particle count climbs, so a big, detailed event doesn't simply overshoot into a wash of light. Both the flash and its sparks run on the same simulated clock every other animated effect here does, so TIME SCALE genuinely paces them too, not just a fixed real-time flicker regardless of how fast or slow the rest of the scene is running - lasting a real 5 seconds at the default pace, long enough to actually read the individual points rather than one quick pop. Spark travel distance scales with the mass actually consumed far more steeply than it first did (an everyday debris grain barely sparks in place; a genuine star-mass collision throws real debris a real distance), rather than a flat minimum speed drowning out the difference A remnant only starts rendering as a black hole once it is actually compact enough to be one: its own Schwarzschild radius (Rs = 2GM/c², using this scene's G and a simulation-scale stand-in for c) has caught up to its real geometric radius - a genuine physical crossover, not a cosmetic cutoff, since Rs grows linearly with mass while a constant-density body's true radius only grows with the cube root of it. The compactness check only counts in ORBIT, GALAXY, SINGULARITY and STAR FORMATION - the scenarios this is actually about; a body meeting the same threshold anywhere else (CLOTH, CELLS, GAS, and so on) stays an ordinary, if unusually dense, body. Once a real one exists, nearby matter forms an accretion disk around it - but only within a limited reach (8x the black hole's own radius, floored at 80 units): a fast damping settles orbits onto the world XY plane inside that zone (out-of-plane velocity dies off quickly), a much slower drag bleeds their orbital energy so they spiral inward over many revolutions rather than one, and anything that actually touches the black hole is consumed outright - mass and momentum conserved exactly, same as any other merge, growing the hole further. Two different timescales for the settling and the spiral, and a hard boundary for the actual swallowing - the same reason real disks flatten and drain rather than falling in from every direction at once. Matter orbiting further out than that reach doesn't feel any of this - it just orbits the black hole's gravity like it would orbit any other mass, forever, unless something eventually nudges it inside the zone. There's no disk drawn as such: what you're looking at is real debris, genuinely herded into that flattened, spiralling shape by the physics above, so a scene with little loose matter nearby (an isolated +BLACK HOLE with nothing around it) won't show much of one. It doesn't just render as a plain tilted ring either - real accretion-disk images don't look like that, because the far side, geometrically hidden behind the hole from any angle, gets bent by lensing into a warped loop above and below the silhouette instead of simply vanishing there ("on na symulacjach tak sie zawija, nie jest po prostu dyskiem"). Any disk body genuinely behind the hole from the camera and close enough on screen to actually be occluded gets its drawn position pushed radially outward from the silhouette, proportional to how deep hidden it would otherwise be - dead-centre behind the hole pushes hardest, the edge of the affected zone pushes essentially none, a smooth taper rather than a hard cutoff. This bends where a body is drawn only, never its real position or which body paints in front of which - the underlying orbit and the paint order both stay exactly what the real physics says - SINGULARITY and STAR FORMATION both start with plenty of debris specifically so there's something for it to act on. FUSE ON CONTACT (FORCES, SIM tab) is the toggle for the underlying merge rule itself: off, bodies in SINGULARITY or STAR FORMATION still orbit and cluster under real gravity, just never actually consolidate into one growing remnant - closer to an early build of this, before merging existed. It doesn't touch the accretion disk above, which is a black hole consuming matter, not bodies consuming each other, and runs regardless. What isn't simulated: no time dilation, no true general-relativistic lensing - the underlying gravity is still the same plain inverse-square force as every other body here, only the render and this settling/inspiral/consumption behaviour change once an object crosses that line. Light bending itself does have a visualisation now (see PHOTON RAYS, under STYLE), using the well-known Newtonian approximation rather than the real thing. TRAILS starts off here (was on by default). Also the scenario that originally justified TIME SCALE's own default: measured across a dozen random seeds, a real black hole reliably formed, but usually within 1-3 real seconds at the old full-speed default, too fast to actually watch the stars cross paths and collide or the accretion disk take shape. Turning gravity down instead to buy more real time turned out to be the wrong lever - reliability, not just speed, falls off a real cliff below roughly G:1600, so some seeds would stop forming a black hole at all. Slowing the clock keeps the identical physics and the same guaranteed outcome, just paced to where it reads as an event instead of a jump cut - the reasoning that eventually made a deliberately unhurried pace (labelled 1 on TIME SCALE's own rescaled range - see TIME SCALE, transport bar) the default every scenario here starts at now, not a special case just for this one
STAR FORMATIONA turbulent, rotating cloud of gas - not a few pre-formed stars - collapsing under its own gravity, the same merge-on-contact rule SINGULARITY uses. 800 clumps by default (doubled from the original 400 once profiling showed real headroom - 800 costs ~13ms/frame, the cliff doesn't start until around 1000), with radii drawn from a power-law distribution (the same shape real molecular clouds actually fragment along - Salpeter's stellar mass function is the famous version) rather than a narrow random range: most clumps are small, with a long tail of increasingly rare, much bigger ones - about a 1300x spread in mass between the smallest and largest, versus a flat ~5x before. The cloud starts with real sub-Keplerian rotation (each clump's tangential speed is 80% of the circular velocity its distance and the cloud's enclosed mass would need for a stable orbit), which is what keeps it from just free-falling straight to the centre in a couple of seconds - real angular momentum slowing the collapse, the same reason actual star-forming clouds take a long time and often flatten before anything ignites. Every clump quietly carries a real mass threshold: cross it and the clump ignites, which here means its colour genuinely tracks its mass along the same ladder the real main sequence follows - a dim red dwarf just past ignition, orange, sun-like yellow-white, white, then blue giant for anything massive enough. Below that threshold a clump is just cold, dark gas - nothing is glowing yet because nothing has ignited yet. Every clump in this scenario reads its colour off that same ladder regardless of whether it has actually ignited (dark, cold-gas colours for the clumps that haven't), but only a clump that has genuinely crossed the threshold renders as a real light source - the gradient-sphere-plus-flicker described under +STAR - so the collapse visibly stays dark gas right up until something actually lights up, rather than the whole cloud looking lit from the start. Gravity here is deliberately weaker than SINGULARITY's - both to give the collapse actual heft instead of finishing in a couple of seconds, and because a body's own Schwarzschild radius grows with G while its physical radius doesn't: at SINGULARITY-strength gravity, the default cloud's full collapse landed just past its own compactness line every single time, so "star formation" always quietly finished as a black hole regardless of what the ignition colours had been doing - the weaker pull here means the default cloud collapses into a genuine, stable star cluster instead (the wider mass spread pushes total cloud mass up, so the radius range was tuned down alongside it specifically to land back at roughly the same safe margin below that black-hole line - checked empirically across 30-plus random seeds, all ending as ignited star clusters, none as a black hole; re-checked again across 28 more after doubling the default clump count to 800, since twice the clumps at the same power-law range means roughly twice the total mass too - the safety margin is thinner than before but still real, worst case observed 73% of the way to the compactness line, not past it). Being a cosmic scenario, it can still cross that same Schwarzschild line SINGULARITY uses if it keeps accreting past that - feed it enough more mass (more clumps, or +BLACK HOLE dropped in by hand, which works exactly as it does anywhere else in that list, consuming the surrounding gas outright with mass and momentum conserved exactly) and it does eventually collapse into an actual black hole, but that's now a deliberate escalation rather than the guaranteed ending

Population

RADIUS is not cosmetic. It sets the drawn size and the collision size, and for a RIGID body it sets mass too, growing as the cube of the radius - double the radius and the body is eight times heavier. Its range is 1-70 in steps of 0.5: the old floor of 3 sat above the smallest clumps STAR FORMATION generates on its own (that scenario's power-law distribution goes down to radius 1.1), so this slider couldn't manually reproduce the small end of what the scenario already shows you - it can now.

DENSITY separates weight from size for a RIGID body. Mass is 4/3 · π · r³ · density, so at the same radius you can build a small lead marble or a big balloon. It dims whenever TYPE (below) is anything other than RIGID, since STAR and BLACK HOLE compute their mass a completely different way and DENSITY genuinely stops doing anything at that point - the same "dim what isn't acting" rule every gated slider here follows. The NEXT BODY line shows the exact radius and mass of whatever the buttons below will create next, labelled with the type whenever it isn't RIGID.

ControlDoes
TYPE: RIGIDAn ordinary body. Mass follows RADIUS/DENSITY like anything else in a plain physics scenario
TYPE: STARAlready past ignition - lit, coloured by mass along the same main-sequence ladder STAR FORMATION uses, only in ORBIT, GALAXY, SINGULARITY and STAR FORMATION (elsewhere it's just an ordinary body with a large mass). Mass is deliberately capped at half of whatever this exact RADIUS's own Schwarzschild line would allow, so it stays a real, stable star and won't collapse into a black hole under its own weight - drop one near a BLACK HOLE and watch the black hole actually consume it, mass/momentum/charge conserved exactly, the same accretion physics described under SINGULARITY
TYPE: BLACK HOLEMass is computed from RADIUS and G so its own Schwarzschild radius already meets or exceeds that RADIUS - a real black hole (see SINGULARITY) the instant it exists, in the same four scenarios STAR lights up in. Elsewhere it's just a very dense, ordinary body
Picking STAR or BLACK HOLEAlso switches FUSE ON CONTACT on if it was off - both types rely on the plain-contact merge rule that toggle gates (see SINGULARITY) to ever actually consume anything, so leaving it off silently made a freshly-placed one inert
Picking any TYPEAlso switches the active pointer tool to PLACE, unless PLACE or +BALANCE is already active - picking a type is step one of "pick a type, then click the viewport", so whatever tool would otherwise ignore that click (GRAB, POKE, and the rest) steps aside automatically instead of leaving the click looking like it did nothing
+1 IN BALANCEAdds one body of the selected TYPE that joins the system without disturbing it, at a location the tool picks. What that means depends on the active forces, see below
+1 RANDOMAdds one body of the selected TYPE at a random place with a random velocity
SPAWN PATTERNHow + COUNT and REPLACE lay their bodies out. GRID is an even grid across whatever the camera currently frames; RANDOM CLOUD scatters across that same framed area with no structure; SPHERE SHELL spreads them over a shell (not filled solid) around wherever the camera is currently centred; FLAT DISK flattens them into the world XY plane around that same centre, like a galaxy disc rather than a ball. All four stay sized to the current camera position and zoom, so switching pattern never dumps bodies off-screen
+ COUNTAdds COUNT more bodies of the selected TYPE in the pattern above - not scattered through the whole world regardless of pattern, so nothing lands off-screen or piles unevenly
REPLACEClears the scene and spawns COUNT fresh bodies in that same pattern
+FEED BLACK HOLEScatters real debris (twice COUNT, 40-200) at once into genuine circular orbit around the heaviest black hole currently in the scene, on the same unsoftened orbital-speed formula SINGULARITY's own debris already spawns with, sized from the same power-law spread (mostly small, a genuine rare few larger) STAR FORMATION's own clumps use rather than one flat size. It settles into an actual, visible accretion disk the same way any other nearby matter does - herded onto the plane and spiralled inward by the exact same rule described under SINGULARITY, not a separate decorative ring, and it's consumed for real the same as anything else that strays close enough, no immunity and nothing guaranteed - whatever a batch does, including whether any of it happens to be large enough to ignite, is left entirely to the same real physics and the same real chance every other body here is subject to. Only does anything where a black hole can exist at all (ORBIT, GALAXY, SINGULARITY, STAR FORMATION) and one is actually present; a click anywhere else, or before one has formed, is a safe no-op
STREAM FEEDThe same real debris +FEED BLACK HOLE drops in one batch, dropped one body at a time instead for as long as this stays on - a black hole that already consumed most of its own surroundings gets an ongoing supply rather than a single feeding that eventually runs out ("dysk sie nie skonczy... maja stale zrodlo"). Paced on simulated time (TIME SCALE governs the rate along with everything else here now, not a separate fixed real-time clock of its own) and capped at 500 total bodies as a plain performance ceiling, not a physics one - well clear of where any scenario here starts missing frames. Measured, not guessed: at one body every 0.5 simulated seconds the disk stabilises thin, 11-14 bodies; at one every 0.1s it settles into a genuinely rich, still stable 50-60-body disk (checked over 300 real seconds and multiple seeds - it reaches a real equilibrium, never climbs toward the cap and never empties out). Same as the button beside it: every dropped body is genuinely consumed by accreteDust like anything else, nothing protected, nothing guaranteed - the disk stays populated because it keeps being fed, not because anything here is exempt from being eaten. Gated the same way +FEED BLACK HOLE is
CLEAREmpties the world

To start a scenario at a body count other than the default, set COUNT and hit RESET - it rebuilds and pauses on the new starting state automatically (see RESET, above), so there's a real chance to look at it, or change COUNT again, before pressing PAUSE to let it run.

TYPE, RADIUS and DENSITY govern every creation path in the app now, not just these buttons - the +BALANCE and PLACE pointer tools (see Pointer tool, below) read the exact same TYPE, so picking STAR here and then clicking PLACE drops a star, not a plain body. This used to be split across two different UI paradigms: instant buttons up here only ever made a plain body, while STAR and BLACK HOLE were each their own separate pointer tool further down with no equivalent instant/random/bulk buttons of their own - so reaching for a star meant hunting for a completely different control scheme rather than just picking a type. One shared TYPE choice plus the same set of creation actions for all three fixes that, and it also means +1 RANDOM and + COUNT can now bulk-add stars or black holes, which the old split-tool version genuinely couldn't do at all.

+1 IN BALANCE reads the situation and picks the right kind of equilibrium. The +BALANCE pointer tool (see Pointer tool, below) does exactly the same thing but at whatever point you click, instead of a spot the tool searches for:

In a crowded gravitational system the new orbit starts circular but will stretch over time. That is not a glitch, it is the other bodies pulling on it. In a clean two-body test the orbit holds to within half a percent of a perfect circle; with two dozen satellites around, it wanders to roughly 29 percent eccentricity.

Forces

ForceDoes
MUTUAL GRAVEvery body attracts every other, inverse square, with softening so close passes cannot explode. Strength is G
DOWN GRAVA uniform pull along −Z, like ordinary weight. Strength is g
ELECTROSTATCoulomb force between charged bodies. Like charges push apart, opposites pull together. Strength is k. Only IONS starts with charged bodies, so switching this on anywhere else would otherwise do nothing at all - it instead gives every still-neutral body a random +1 or -1 charge the moment it's switched on (a body that already has one, from IONS or a previous toggle, is left as-is). Any body added by hand afterwards (+1 RANDOM, + COUNT, +1 IN BALANCE, or the PLACE/+BALANCE pointer tools) instead joins a running alternation, since those arrive one at a time rather than as a single batch - a persistent flip-flop guarantees an even split no matter how many you add, where independent coin flips could streak. Charge is conserved on every merge, the same as mass and momentum - CELLS fusing a positive and a negative cell cancels to neutral, it doesn't just keep one side's charge and drop the other's
COLLISIONSBodies bounce off each other instead of passing through
SPRINGSEnables the links that hold soft structures together
AIR DRAGResistance proportional to speed. Produces a terminal velocity of exactly g / drag
FUSE ON CONTACTSINGULARITY and STAR FORMATION only - dims everywhere else, since it does nothing there. On (the default), touching bodies fuse into one, mass and momentum conserved exactly, which is how a swarm collapses into a single growing remnant. Off, they still orbit and cluster under real gravity, just never actually consolidate - closer to an early build of this, before merging existed

Each force's own slider (G, g, k, AIR DRAG, and RESTITUTION/FRICTION/SPRING STIFFNESS/SPRING DAMPING under MATERIAL) dims whenever its force is switched off, since it isn't affecting anything at that point - a quick visual answer to "what does this slider actually belong to."

Material

SliderDoes
RESTITUTIONBounciness. 1 is perfectly elastic and loses no energy, 0 means bodies stop dead on contact. Successive bounce heights fall by the square of this number
FRICTIONGrip at contact. This is what turns sliding into rolling. At zero, spheres slide forever and never spin
SPRING STIFFNESSHow hard springs resist stretching. Normalised by mass, so the same value means the same stiffness whatever the bodies weigh
SPRING DAMPINGHow fast oscillations die away. Low values wobble for a long time, high values settle immediately

Boundary

ModeDoes
BOXA sealed container. Bodies bounce off the six walls and can roll on the floor
WRAPLeave one side, appear on the other. No floor
HALOOpen space with a soft shell at HALO RADIUS. Orbits inside are untouched, anything trying to escape is pulled back - genuinely gently now: the pull-back force is capped, so a body placed far outside the shell (an easy click while zoomed way out) gets reeled in smoothly instead of the single-frame launch it used to produce, however far out it started. This is the default for space scenes. ORBIT and GALAXY used to inherit whatever HALO RADIUS a previously-visited scenario left behind rather than setting their own (the same class of leak CELLS' TIME SCALE had) - both now set their own explicitly
VOIDGenuinely open space. What leaves is gone forever

Camera

ISO, DIMETRIC, TOP and FRONT jump to fixed angles. ZOOM and PERSPECTIVE are self explanatory, except that PERSPECTIVE at 0 is a true parallel projection with no vanishing point, which is the classic isometric look. ZOOM's own ceiling used to cap out at 3x everywhere - slider, mouse wheel, pinch, every auto-frame - which sounds generous until you measure what it actually means for anything small: an ordinary GALAXY star, even perfectly centred by panning, topped out at roughly 9-10px on screen no matter how far you zoomed, since panning changes what's centred, not how big anything can get once zoom itself is maxed ("powinienem moc przybliżyć do kazdej czasteczki"). Raised to 12x - that same star now reaches roughly 38px, a real amount of room to actually look at one body up close, not the whole scene's own default framing. AUTO-ORBIT spins the camera slowly on its own. AUTO-FRAME adjusts zoom so the whole system stays in shot, which is useful while a structure is growing.

Pointer tool

ToolDoes
GRABDrags a body on an elastic tether. Let go and it keeps the velocity you gave it. Dragging empty ground instead box-selects everything inside the rectangle; Ctrl-click toggles one body in or out of the selection, Ctrl-drag adds a rectangle to it. Dragging any selected body moves the whole group together, keeping their relative positions
POKEA shockwave that pushes everything nearby outward. Mass independent, so it feels the same on a grain and on a planet
ATTRACT / REPELHold to pull everything toward, or push everything away from, the cursor
PLACEDrops whichever body TYPE is selected in POPULATION (RIGID/STAR/BLACK HOLE, see above) at exactly the point you click - the position is never adjusted. With mutual gravity on, it also leaves with a real circular-orbit velocity around the system's current centre of mass, rather than sitting at rest: a stationary body dropped into a scenario where everything else is already moving and colliding (SINGULARITY's stars, say) never really joins in, it just sits there until something else eventually reaches it. Everywhere else (springs, floor collisions, no forces at all) it drops at rest exactly as before - only the gravity case changes. Keep holding after the click and drag before releasing to launch it like a slingshot instead: the release adds a velocity kick OPPOSITE the direction you dragged, scaled by how far you pulled (up to a firm cap, so an extreme drag across a very wide window still tops out at a strong launch rather than an unbounded one), on top of whatever the click itself already gave it - drag right, it fires left, the same way pulling back a real slingshot band works. A plain click - press and release without moving - still leaves the body exactly as above, untouched; only an actual drag does anything. The aim line itself (from the body to wherever you're pulling) grows thicker and switches to the palette's hot colour as the pull nears that cap, the same "size shows strength" language ATTRACT/REPEL's own radius already uses for TOOL POWER - no number readout, just proximity to the ceiling
+BALANCEDrops the selected TYPE in equilibrium instead of exactly where you click: a circular orbit if gravity is on, grafted onto the nearest node if springs are on, resting on the floor otherwise - same rule as the +1 IN BALANCE button, aimed by hand. Unlike PLACE, the point you clicked is a suggestion, not a guarantee - it gets nudged onto the actual orbital plane (or floor, or nearest node) so the equilibrium is exact, not approximate
DELETEClears the whole selection if one exists (so does the Delete/Backspace key), otherwise removes the body under the cursor. Escape clears a selection without deleting it

The orbital speed PLACE and +BALANCE hand out is the real, instantaneous gravitational pull at the exact point the body is about to occupy - the same force law (with the same softening) the physics step itself applies every frame - rather than a "mass enclosed within this radius" shortcut. That shortcut is only exact for a genuinely spherical arrangement; a handful of stars scattered around a ring (SINGULARITY) or any other lopsided cluster isn't, so the real-pull version noticeably tightens the orbit in exactly those cases. It doesn't make orbits immortal, though: once more than two comparable masses are actually pulling on each other, real orbital mechanics is genuinely chaotic over long enough timescales - the same reason real solar systems aren't perfectly stable forever either - so a "balanced" body can still drift, precess, or eventually collide with something as the whole system evolves. That's the system doing real physics, not the placement math being wrong.

PLACE is the default tool, so clicking the canvas drops a body immediately without having to find a tool first. The cursor itself always shows which tool is active - an open hand for GRAB, a copy-cursor for anything that drops a body (PLACE, +BALANCE), a no-entry cursor for DELETE - rather than a line of text explaining what clicking will do. An ignited star (a genuine ignition, not just a body coloured off the same ladder - see STAR FORMATION) always renders as a real gradient sphere - a hot white core burning through to its true mass-colour, fading toward the rim, with a gentle two-wave flicker so a cluster of them don't pulse in unison - regardless of BODY STYLE or whether GLOW is switched on, the one visual cue that actually reads as "this is now emitting light," which a colour change alone doesn't sell on its own. The extra soft halo around it is still gated by GLOW like any other body's: an additive halo redraws every frame, and forcing one on unconditionally turned out to fight TRAILS' own persistence at STAR FORMATION's default settings, slowly washing the frame out over a long sustained run - TRAILS has since been rebuilt on a different mechanism entirely (see STYLE tab) that doesn't accumulate this way any more, but GLOW staying opt-in for the halo was already the right call regardless.

TOOL POWER scales GRAB/POKE/ATTRACT/REPEL, not PLACE and +BALANCE. SIZE FOR PLACE / +BALANCE and WEIGHT sit right here too, mirroring RADIUS and DENSITY in the SIM tab's POPULATION section - moving either copy updates both, so sizing a body and placing it do not require scrolling back and forth. WEIGHT dims under the same rule DENSITY does above, whenever TYPE isn't RIGID.

+BLACK HOLE and +STAR used to be their own separate pointer tools here, each dropping a fixed kind of body at a fixed mass with no other way to place one. They're gone as tools - not as capabilities, PLACE and +BALANCE now drop whichever TYPE is selected in POPULATION, which also means TYPE and placement are independent choices instead of nine tools covering every combination by hand. Keyboard shortcuts 1-7 now cover GRAB through DELETE; 8 and 9 are unbound rather than reused for something unrelated.

Solver

SUBSTEPS / FRAME is how many physics steps run per drawn frame. More substeps means a stiffer, more accurate solve, at a cost in physics time but not in rendering. Raise it if stiff springs jitter; lower it if the simulation is the bottleneck.

Scale of the world

An alternative to picking a scenario. One slider walks seven rungs from a flat plate of molecules seen from above, through cells, sand, everyday objects, planets and stars, out to a galaxy. The world itself changes shape as you climb: at the bottom the simulation volume is squeezed to a thin slab so it is effectively two dimensional and the camera looks straight down, and as you rise the slab opens into a full cube and the camera eases into isometric. Brownian agitation fades out, gravity fades in. Each rung rebuilds the scene.

5. FRACTAL tab

Twelve generators. Ten of the twelve lay bodies out on a structure - the geometry becomes the starting state, and the physics engine then does whatever the active forces say. MANDELBROT and JULIA are the odd two out: genuinely flat, infinitely-detailed 2D objects that a handful of particles could only ever crudely silhouette, never actually resolve - so both get a completely different engine underneath instead of the shared physics/particle one. Picking any of the ten resets BODY STYLE to DISC and turns TRAILS off, rather than leaving whichever the previous scenario happened to set - most of these generators pack points densely enough that WIRE's per-point equator/meridian rings (each one meant for a single body read in isolation, not hundreds tiled across a shared surface) bury the actual geometry under visual noise instead of showing it, and these generators pack too many points for individual per-body trails to read as anything but clutter

ControlDoes
GeneratorsSierpinski tetrahedron, Menger sponge, branching tree, aggregate cluster, phyllotaxis sphere, torus knot, Fibonacci shell, double helix, Barnsley fern, Mandelbulb, Mandelbrot, Julia
FERNBarnsley fern - the chaos game over four affine maps, the classic proof that a few simple rules can draw something that looks organic
MANDELBULBA power-8 escape-time fractal, the 3D generalization of the Mandelbrot set. Points are rejection-sampled to trace its surface rather than fill its volume
ITERATION DEPTHRecursion depth. How steeply body count climbs with it is wildly different per generator - SIERPINSKI is 4depth points, MENGER is 20level cubes, most of the rest (PHYLLOTAXIS, SHELL, KNOT, SPIRAL, FERN, MANDELBULB, aggregate cluster) grow linearly - so the slider's actual max changes to match whichever generator is active (measured against a frame budget per generator) instead of one number capped for the worst case. Click the number itself to type an exact value - every numeric readout in the panel works this way, not just this one - it still can't go past whatever the slider's current max is
BRANCHES PER NODETree only. One branch gives a line, two gives 63 nodes at depth 3, three gives 364, four gives 1365
SPREADOverall size of the structure

MANDELBROT and JULIA

These two swap the whole canvas for a second one running a WebGL fragment shader instead of the particle system - the same escape-time test (z = z² + c, kept if it never passes a bailout radius) computed live for every pixel, every frame, the way every real Mandelbrot zoom video actually does it, rather than a scatter of particles standing in for its silhouette. No bodies exist while either is open - RESET, POPULATION, and every physics-tab control genuinely do nothing here, since there's nothing for them to act on.

ControlDoes
Scroll wheelZooms toward the cursor - whatever point is under it stays under it as the view scales
Click and dragPans - the cursor turns into an open hand to show it, a closed one while actually dragging. A plain click that never moves leaves the automatic drift running; only a real drag hands control to you, the same as scrolling does
MANDELBROT auto-driftZooms continuously into a known, detail-rich mini-Mandelbrot ("seahorse valley"), the same kind of coordinate every real endless-zoom video picks, until it reaches the depth single-precision floats start to break down
JULIA auto-driftThe c constant continuously traces a small loop instead, morphing the whole shape - the "beautifully rotating" look Julia sets are known for
DRIFT SPEEDMultiplies how fast the automatic zoom (or Julia's loop) runs - 0 freezes it in place without switching AUTO DRIFT off, higher speeds it up. TIME SCALE (transport bar, always visible) still applies underneath this, same as it affects everything else here
AUTO DRIFTToggles the automatic zoom/rotation on or off directly, rather than only ever turning off the moment you touch scroll or drag. RESET turns it back on
RESET VIEWLocal to this panel, next to AUTO DRIFT - recentres, zooms back to 1x and hands control back to AUTO, without reaching for the transport bar's scenario-wide RESET three tabs away
PAUSE / SpaceDoubles as this view's play/pause, since there's no physics here to pause instead - stops or resumes the same auto-drift AUTO DRIFT does, and the two stay in sync with each other. A click or drag still stops it too (that's the point of taking the wheel), and PAUSE/Space brings it right back regardless of which one stopped it
RESETSnaps back to the starting view and hands control back to the automatic drift - same effect as RESET VIEW here, but also available from the always-visible transport bar
Single-precision floats in the shader start visibly pixelating somewhere around 105-106 zoom. Genuinely deep zoom - the kind those endless-zoom videos reach - needs emulated double precision inside the shader itself, which this does not do yet; the auto-drift stops well before that point rather than dissolving into noise. The shader actually renders onto a second, invisible canvas and gets composited onto the ordinary visible one every frame, so ● RECORD captures it exactly like anything else here - no separate export path needed. The SHOT tab's frame-exact render is the one exception: it keyframes the 3D camera over time, and there's no 3D camera here to keyframe, so it isn't wired up for this view. Falls back to the old particle version automatically if WebGL isn't available on a device at all.

With any of these open, the SIM tab, most of STYLE (everything except HIDE UI, MUSIC REACTIVE and the EXPORT row - GLOW, TRAILS, BODY STYLE and the rest all act on bodies that don't exist here), all of SHOT, and SET's DESIGN MODE / SEED sections all dim - population, forces, the 3D camera and seeded randomness genuinely don't reach a shader with no bodies and no 3D camera to speak of. RENDER SCALE, AUTO QUALITY and RESET ALL stay active, since render scale genuinely still sets this view's resolution and RESET ALL is the one control that should never go dark.

ADD TO STRUCTURE lets you grow the shape by hand instead of only by formula: +1 ONTO STRUCTURE calls the same equilibrium logic as +1 IN BALANCE in the SIM tab, so with SPRING LINKS on it grafts a new node onto the nearest existing one at rest length; +1 RANDOM drops one in freely near the structure. Both read RADIUS and DENSITY from the SIM tab.

ControlDoes
FREEZE GEOMETRYPins every body so the structure holds still and you can orbit it as a static object
SPRING LINKSWires the structure together so it holds shape and can be poked
GROW OVER / ANIMATE GROWTHBuilds the structure outward over the given number of seconds, one generation at a time
CAMERA FOLLOWSKeeps the growing structure framed as it expands
REPLAY GROWTHStarts the growth animation again

SET IT MOVING gives a static structure something to do, and unfreezes it automatically: SPIN rotates it as a rigid body, BURST blows it apart from the centre, DROP lets it fall into a box, SWIRL hands it to a flow field, COLLAPSE lets its own gravity pull it in, BREATHE makes it pulse on its springs.

COLLAPSE's own gravity checks every body against every other one - real physics, but genuinely O(n²), with no spatial approximation to soften that at high counts. Measured directly across all ten particle-based generators at each one's own maximum DEPTH: cost fits time ≈ 3.7×10-6×n² ms almost exactly - MENGER's 8000-cube maximum runs this at roughly 247ms a frame, FERN's 8150 points at roughly 250ms, even SIERPINSKI's 4096 at roughly 66ms, every one of them but TREE blowing well past a 16.7ms frame budget. BURST and DROP's collision detection is cheaper but not free either, and can add up past the same range. Rather than shrinking DEPTH's own ceiling for everyone (which would also weaken every dense, frozen, unmoving structure these generators can otherwise build in full), COLLAPSE/ BURST/DROP specifically go unavailable - dimmed, and a genuine no-op if clicked - once the current structure is denser than 1400 bodies, a real measured line with actual margin rather than a guess (verified directly at 1420 real bodies: collision 8.2ms, gravity 9.4ms, full BURST/ DROP well under that once other frame costs are added). DEPTH itself, and every other motion (SPIN, SWIRL, BREATHE - none of which check body against body), stay completely unaffected at any size. The same gate protects QUANTUM's own SET IT MOVING section too, since it shares this exact mechanism - a SAMPLES-heavy orbital or wave packet runs into the identical cost.

The ● RECORD button right below that starts a quick capture and replays the growth from zero, so the whole build is captured without switching to the SHOT tab first. It is the same recorder as RECORD in the STYLE tab - starting it from either place restarts the growth if one is running, so pressing record always captures the whole thing rather than whatever is left of it.

FLOW FIELD steers every body along a strange attractor: Lorenz, Rössler, Aizawa, Thomas, Halvorsen, a curl-noise swirl, or a simple vortex. FLOW SPEED sets the pace and FLOW GRIP sets how tightly bodies track the field. Turn TRAILS on, or you will only see dots. RESEED CLOUD INTO FLOW fills the scene with fresh particles placed on the attractor itself.

6. QUANTUM tab

Nothing here solves a wave equation. Every body is one sample drawn from an exact analytic probability distribution, so what you see is the real mathematics drawn as points. It is an honest picture, not a quantum solver.

Every one of these (the orbitals, WAVE PACKET, FIRE PARTICLES, ONE SLIT) frames its own camera on launch rather than inheriting whatever zoom and pan were left over from whatever was open before - without that, an orbital or packet spanning a few hundred units could land anywhere from off-screen to a barely-visible speck depending on what you happened to be looking at a moment earlier, which read as "different every time" without actually being random.

ControlDoes
1s / 2s / 2p / 3s / 3p / 3d / 4f / 5gSamples the exact hydrogen probability density for that orbital. Nodes come out genuinely empty because the mathematics says so. 1s, 2p, 3d, 4f and 5g are each the highest-angular-momentum orbital their shell allows; 2s, 3s and 3p are included alongside for the contrast of their radial nodes. Every sample also gets a spin, an honest 50/50 coin flip independent of where it landed - the non-relativistic hydrogen Hamiltonian doesn't couple spin to position - shown as a small ↑ or ↓ above the body, and a phase: the actual sign of psi at that point, not just its squared density, colourable via COLOR BY > PHASE (STYLE tab). |psi|² alone can't show that two lobes carry opposite sign - phase can, and that sign is the real reason orbitals combine into bonds the way they do. It also starts already spinning (the same kick SPIN under SET IT MOVING applies by hand, see below) - a stationary state genuinely has no dynamics of its own, |psi|² for an energy eigenstate really is constant in time, so leaving it completely still made TIME SCALE and PAUSE look broken instead of simply not applicable to a cloud with nothing to animate. Body SIZE now varies with the actual local density at the point sampled too, not one fixed size for every point - rejection sampling already made denser regions more crowded with points, honestly, but every point reading as visually identical left a lobe's bright core and its sparse fringe looking the same, just packed differently; sizing by density (the same mapping SUPERPOSITION below already used) is what actually makes a multi-lobed shape like 2p or 3d read as more than a uniform dot cloud that only differs in overall outline
SAMPLESHow many points to draw. More points, sharper shape. Dragging it now rebuilds whatever's currently on screen with the new count live, the same as every other scene-shaping slider here - it used to only update the number for whenever you next pressed a build button, which read as the slider doing nothing at all
SPREADOverall size on screen. The same control as SPREAD on the FRACTAL tab (one shared value, this is a second copy) - added here because every scene on this tab uses it to size itself and there was previously no way to reach it without leaving QUANTUM entirely. Live-rebuilds the current scene the same as SAMPLES above
1s + 2pz (SUPERPOSITION)A single orbital above is a genuine stationary state - constant in time, not a limitation (see the note on the orbital buttons). Mixing two different-energy orbitals together stops being stationary: their relative phase evolves at a rate set by the real energy gap between them, and since both are real-valued that phase shows up directly as an actual, physical oscillation in |Psi|² - probability genuinely sloshing from the symmetric 1s cloud toward the off-centre 2p lobe and back, exactly the mechanism behind a real oscillating dipole moment (what spontaneous emission actually is), not a decorative pulse. |Psi(t)|² = |c1ψ1|² + |c2ψ2|² + 2c1c2ψ1ψ2cos(ΔEt/ℏ), computed exactly (a 50/50 mix, c1=c2) - each point gets a size/brightness that rises and falls with its own local value of that expression every frame, rather than genuinely resampling positions each frame (far too expensive to do live). Two approximations, both honest: each orbital's own density is only peak-matched against the other, not properly integral-normalised, so the 50/50 split is close but not research-exact; and the oscillation rate is a deliberately artistic choice, not hydrogen's real one - the true 1s-2p gap corresponds to a petahertz frequency that would look completely frozen at any frame rate, so it's paced instead for a rate actually worth watching (~5.7s per cycle), the same reasoning TIME SCALE gets stretched elsewhere in this app. The cloud itself also spins about Z, the same rigid-rotation kick a plain orbital gets on landing (see the orbital-button note above) - 1s and 2pz are both azimuthally symmetric (density depends only on r and cosθ, never φ), so spinning the mix about Z changes nothing about the physics, an exact symmetry, not a stand-in for real motion. Unlike a plain orbital's own spin - which sets a velocity once and lets it drift (measured directly: a 2p sample point's own radius grew from 62.6 to 93.1, roughly +49%, over a real 5-second watch at the default TIME SCALE) - this rotation is recomputed fresh from each point's original position every single frame, so the shape can't spiral outward or distort no matter how long it runs
LOCALISEPosition spread of the wave packet. The momentum spread is then whatever the uncertainty relation demands. Dragging it now rebuilds the current packet live if one is up, same as SAMPLES - it used to silently do nothing until WAVE PACKET was pressed again
WAVE PACKETBuilds a Gaussian packet with the product of the two spreads pinned at ℏ/2
MEASURELocalises the packet further, which forces the momentum spread up and blows the cloud apart. Only actually does this when a wave packet is genuinely up - it used to check only "is there anything in the scene at all", which anything on this tab satisfies, so clicking MEASURE while looking at an orbital (say) silently discarded it and built an unrelated wave packet instead, with nothing about the click itself explaining why the screen suddenly changed to something else entirely
SLIT SEPARATIONDistance between the two slits, which sets the fringe spacing. Dragging it now rebuilds the current slit experiment live if one is up, same as SAMPLES/LOCALISE above
FIRE PARTICLESLanding points sampled from the true two-slit intensity. With trails on the fringes assemble one dot at a time - genuinely: every particle used to fire and cross the whole apparatus in perfect lockstep (identical velocity, no stagger), landing as one synchronised sheet within a single frame rather than a stream, the opposite of what "assemble one dot at a time" already claimed. Each one's own launch is now spread across a real window instead, so they fire in a genuine, continuous stream and the interference pattern visibly builds up dot by dot rather than appearing all at once. Each particle freezes the instant it reaches the detector plane instead of flying on past it, so the pattern actually stays once it's built rather than the whole cloud eventually drifting off-screen - and the camera frames the slit-to-detector span itself on launch, rather than wherever it happened to be pointed for whatever was open before
ONE SLITThe same with a single slit, so the fringes vanish and leave one blob

SAMPLES, SPREAD, LOCALISE and SLIT SEPARATION all rebuild whichever of this tab's scenes is currently on screen the moment you move them, reusing whatever it was already showing (which orbital, which slit count) rather than resetting to a default - the same "the slider IS the control" behaviour every other force/render slider in this app already has.

7. SHOT tab

This is where a simulation becomes an animation.

ControlDoes
TimelineClick or drag to scrub. Diamonds are keyframes
PLAY / LOOPRuns the camera move, optionally repeating
DURATIONLength of the shot. Existing keyframes scale with it
+ KEY HERERecords the entire camera state at the playhead: angle, zoom, centre, pan, perspective
DEL / CLEARRemoves the nearest keyframe, or all of them
SMOOTH / LINEAR / EASE IN / EASE OUTHow motion is timed between keys. Movement follows a spline, so a three-key move does not kink in the middle

CAMERA MOVES write a whole shot in one click. ORBIT 360, SPIRAL and PENDULUM are built to end exactly where they began, so the exported video can be cut end to end with no visible seam. PUSH IN, CRANE UP, VERTIGO (a dolly zoom, tightening while the perspective opens), FLYBY and REVEAL are one-way shots.

● RECORD MY CAMERA MOVE writes a shot from your own hands instead of a preset: press it, then orbit and zoom with the mouse as usual. The camera is sampled roughly every 120 ms while you move it, and stopping the recording drops those samples onto the timeline as keyframes, ready to play back or render like any other shot.

RENDER + SAVE advances physics by exactly one frame's worth of time per frame and pushes frames manually, so the content is frame exact however slowly your machine draws. Pick 24, 30 or 60 FPS. That manual frame push is Chromium-only; in a browser that does not support it (Firefox, Safari), the same button falls back to a real-time capture at the chosen frame rate and says so in the status line - still exports, just no longer frame-exact, so a slow machine plays back slow rather than staying smooth.

Exports MP4 (H.264) wherever the browser can actually produce it, and falls back to WebM otherwise, same isTypeSupported-and-fall-back pattern the app already uses for picking a codec. This isn't a preference call - WebM plays back fine in a browser, but plenty of real upload targets reject it outright as an unsupported format even though nothing about the file itself is broken; Facebook in particular does this. MP4/H.264 is the one container every major platform actually accepts, and Chromium browsers can produce it directly, so this is what ● RECORD, RENDER + SAVE, and its real-time fallback now all prefer. Firefox still can't produce MP4 as of this writing and falls through to WebM as before. Every WebM saved here still gets its duration patched in after the fact (MP4 output doesn't need this): Chrome's own WebM recorder writes an unknown/infinite duration into the file while it is still streaming, since it cannot know the final length up front; browsers and casual players re-scan and ignore that, but many video editors and importers read it literally and refuse a file that claims to be zero seconds long. The real duration is written back into the header the moment recording stops, so a WebM export opens correctly everywhere, not just in a browser.

The rest of this tab is app-level settings that never fit neatly under SIM (not simulation content) or STYLE (not a look) - a separate SET tab existed for these alone until it was folded in here, since RESET ALL and SEED both already bear directly on reproducing a shot, the actual thread connecting everything above.

ControlDoes
CLEAN MODEOne press turns off GLOW and TRAILS, the two effects that build up over a run - what you want when judging the raw composition or exact body positions without accumulated haze in the way. A second press restores exactly what you had
RENDER SCALEInternal resolution multiplier. The first thing to lower if the tool stutters
AUTO QUALITYBacks off resolution, then glow, then substeps if the frame rate drops below 38
SEEDThe random seed. The same seed and the same shot render identically every time
RANDOM SEED / RESET ALLNew seed and rebuild, or back to factory settings

8. STYLE tab

ControlDoes
TRAILSEach body keeps a short history of its own recent world positions and redraws it as one thin, flat-alpha stroke every frame - the same one-stroke()-per-object technique FIELD TRACERS and PHOTON RAYS use, and modelled directly on how PHOTON RAYS looks. Used to be a whole-canvas fade instead (every body's own full, current shape - glow halo, organic lobes, whatever BODY STYLE draws - literally repainted in place and left to fade), which read as a flat, constant-width smear the width of the body itself, not a tail; it also smeared stationary points across the screen if the camera moved, since the fade lived in screen space, not world space. TRAIL PERSISTENCE still means the same thing intuitively (short-lived vs long light-painting streaks) - it now sets how many recent positions are kept rather than a per-frame decay rate
VECTORSDraws a velocity arrow on each body
SHADOWSEllipses on the floor. The main depth cue in an isometric view - but there has to be a floor. It needs WALLS set to BOUNCE (GAS and CLOTH both use it by default), so the button dims in the open-space scenarios (ORBIT, GALAXY) rather than switching on and visibly doing nothing - a reactive text hint used to explain that after the fact instead, the one place this toggle wasn't following the same "state, not text" rule everything else here does. Independent of SHOW BOX - turning the wireframe off to declutter the view doesn't turn the floor itself off, just what draws it
SHOW BOXThe wireframe walls, nothing more - purely how it looks, not where bodies can actually go. WALLS (FORCES tab) is the real boundary; hiding this doesn't loosen it
GLOWAdditive halo around bodies
WIRE SPHERESEquator and meridian rings that make a circle read as a sphere
FIELD TRACERSA wind/current map for whatever forces are actually switched on instead of air: 1500 massless unit test points get pushed around by the real gravity/charge field and streak where it takes them, each one coloured by how fast it's actually moving right now along the same blue → teal → yellow → orange → red ladder every real wind-speed map uses - so the field's calm patches and its fast ones read differently at a glance, not just where it's pointing, with a small bright dot marking each tracer's current position along its streak. Gravity treats a tracer like any other mass (acceleration doesn't depend on the falling body's own mass); charge assumes a nominal +1 test charge, since that force law genuinely depends on what's doing the feeling. Softened more heavily than real bodies are, since a tracer has no collision radius stopping it from passing arbitrarily close to a source - without that, and a speed cap, tracers would slingshot chaotically near any strong source instead of flowing smoothly past it. No reciprocal force on real bodies; a pure visualisation. 1500 rather than the original 220 - each tracer's whole trail draws as one stroke() call instead of one per segment, which is what actually let the density go up nearly 7x before hitting the same frame-budget ceiling the old count was already close to. Density backs off automatically on a slow machine (see "If it stutters")
PHOTON RAYSRays of actual light, bent by actual gravity - the honest Newtonian light-bending approximation: a photon feels the same gravitational field a tracer does, but only its direction changes every step; its speed is snapped straight back to this scene's own light-speed constant (SIM_C, the same one the Schwarzschild check uses) every single step, since nothing here models real relativity. This under-counts true general-relativistic bending by roughly 2x - a well-known simplification textbooks use for exactly this reason, not an attempt to pass as the real thing. Rays stream in as a parallel beam from one direction in world space (like light from a single distant source, so the bending looks the same regardless of which way you're looking) - LIGHT AZIMUTH and LIGHT ELEVATION aim that direction, defaulting to the same angle this always used before they existed as sliders. Existing rays keep flying the old way until they're absorbed or leave the scene; only newly spawned ones pick up a change, so retargeting eases in over a few seconds rather than snapping the whole beam at once. Any lit star (see STAR FORMATION) adds its own rays radiating outward regardless of these sliders - that part was never a single beam to begin with. 400 rays rather than the original 70 - same one-stroke()-call-per-ray batching FIELD TRACERS got, profiled safe against STAR FORMATION's own 800-body default (the per-ray absorption check is the real cost driver here, not drawing, since it scans every body per ray every step). What makes a black hole's bending look so much more dramatic than an ordinary star's isn't a different formula - it's that a black hole's own surface has shrunk well inside the distance light would need to bend hard, so a ray can actually get that close before hitting anything, where a star's surface (however massive) simply blocks incoming light first. A genuine black hole also captures anything crossing its photon sphere - 1.5x its Schwarzschild radius, the same real result - not just what touches it outright; an ordinary body only blocks a ray that hits its actual surface, nothing more dramatic than that
LABELSPrints each body's mass next to it
PalettesP1 green, P3 amber, ice, magenta, Dreamwave and mono. Recolours bodies and the on-canvas overlays (selection lines, anchor points) - the panel around it keeps its own fixed colours regardless of which one is active
COLOR BYSpeed, depth, mass, charge, or phase (an orbital's actual wavefunction sign - see QUANTUM tab)
BODY STYLEOrganic (a soft breathing blob that also gets a small constant Brownian jitter - real thermal-motion physics, the same mechanic MOLECULAR uses on the scale ladder, not just a pulsing animation), ghost (translucent, no opaque core), mist (soft and foggy, piles up denser where bodies cluster), bubble (thin film, bright rim, a specular highlight - reads as hollow rather than solid), wire sphere, filled disc, ring, or cross
TRAIL PERSISTENCEHow slowly trails fade. High values leave long light-painting streaks
GLOW AMOUNTHalo size and brightness
HIDE UIHides the panel for a clean frame. H brings it back

ORGANIC replaces the flat disc with a soft radial gradient that pulses gently on a phase assigned to each body when it is created, so a swarm never breathes in unison. It is the default for the flow-field attractors and every quantum builder, since those are dense point clouds where a flat dot reads the least like something alive. GHOST is the same idea with no opaque core, staying translucent throughout. MIST is bigger and foggier still, and additive, so it piles up into denser cloud wherever bodies cluster instead of just stacking flat discs.

Organic merge

Only affects the ORGANIC, GHOST and MIST styles. With it on, bodies close enough together visually fuse into one continuous blob instead of overlapping as separate shapes - the way water droplets merge. It works by drawing every body as a solid circle on a hidden layer, blurring that layer, and then remapping the blurred result's transparency by hand: anywhere the blur has piled up enough (two bodies close enough that their haze overlaps) gets pushed back to fully solid, anywhere it has not fades to fully invisible. CSS's contrast() filter looks like the obvious tool for that second step, and was the first thing tried, but testing showed it does not touch transparency at all in this browser - measured identical before and after. MERGE SOFTNESS is the blur radius: turn it up and bodies fuse from further apart, at the cost of a wider soft edge on every body. Bodies are also drawn deliberately oversized on the hidden layer before blurring (scaled to the blur amount, so the two settings stay matched), and the remap doesn't just cut a silhouette - overlap depth doubles as fake shading, brighter where bodies actually fuse and darker at the rim, so a merged mass reads as one lit surface rather than flat cutouts that happen to touch. Went through two defaults in opposite directions before landing on the current one, each measured rather than guessed: 1 (the slider's own minimum) never reached far enough to bridge the actual gaps between nearby bodies at CELLS' own scale, so MERGE wasn't doing anything most of the time and cells looked like plain separate circles (measured: only 6% of the area around a cluster actually lit, versus 26% at 10); 8 fixed that but overshot the other way and was exactly the "out of focus rather than merely soft-edged" failure this paragraph used to only warn about - confirmed directly on an isolated, non-touching cell (a smooth brightness dome across the entire body, no flat interior anywhere) once it actually got reported. Default is 2 now: bridging between genuinely close bodies still works (measured up to roughly a body's own radius of separation), but a lone or lightly-touching one reads as a solid shape with a soft rim again, not a haze throughout. ORGANIC specifically also feeds the blur three smaller offset blobs per body instead of one dominant circle, so even a lone body that isn't touching anything else comes out mildly lumpy rather than a perfect disc once thresholded - GHOST and MIST still merge as plain single circles each. The transparency remap reads every pixel back from the graphics card by hand, which is real work - cost rises with how many pixels are on screen, so RENDER SCALE in SET is the first thing to lower if it stutters.

Music reactive

Loads a local audio file and lets it drive whatever scene is running. Nothing here is real beat detection - it is a single AnalyserNode split into three bands, each wired to something different.

ControlDoes
CHOOSE AUDIO FILELoads a track from your device. It stays local - nothing is uploaded anywhere
PLAY / PAUSEStarts or stops playback. Reactivity only does anything while a track is actually playing
REACT TO MUSICThe master switch. Off by default, so loading a track never changes anything until you flip this
SENSITIVITYScales both effects below. Uses a square-root curve on purpose, so the top of the range stays usable instead of turning into noise
MeterThree bars - bass, mid, treble - showing what the analyser is reading right now, whether or not REACT TO MUSIC is on

The bass band is compared against its own slow-moving average; when it spikes past it, a one-off outward kick fires on every body - unlike POKE, which only reaches bodies within its own radius around the click and fades out toward its edge, a kick here is global and uniform, the same push on everything regardless of distance. Retuned down from an original strength of roughly 8x a typical ORBIT body's own orbital speed (which at this feature's fastest allowed pace, about 5 kicks/second, meant the whole scene repeatedly flew out past its container and back on nearly every beat) to about 2x that speed instead - still a real, felt kick, not a fight against the scenario's own physics every time the bass hits. The treble band drives a continuous per-body jitter, using the identical formula as the Brownian agitation at the molecular end of the scale slider, just fed by a different input. The mid band only brightens the glow - cosmetic, it does not touch the physics.

Both audio effects are unbounded stochastic forcing, like the Brownian term they share code with - sustained treble at maximum SENSITIVITY will keep adding energy in a scene with no dissipation (RESTITUTION 1, no drag, no friction). Real music does not actually sustain a hard maximum for long, so this is a corner case, not normal use; lower SENSITIVITY or pick a scenario with some friction or drag if it matters to you.

This reactivity runs in the ordinary render loop, so the live view and the quick ● RECORD capture get it for free. The frame-exact RENDER + SAVE export in the SHOT tab does not use it - that path deliberately decouples simulated time from wall-clock time, and there is no way to keep an audio file in lockstep with that.

SNAP PNG saves a still. ● RECORD captures in real time, which is fine for a quick capture but inherits any stutter and is the only path that hears the music; the SHOT tab renderer is the one to use for finished, frame-exact work.

9. The physics model

Bodies are solid spheres with mass, radius, position, velocity and rotation. Motion is advanced with velocity Verlet integration, which conserves energy far better than the naive approach and is why orbits here do not spiral apart.

Forces are summed each substep: mutual gravity, uniform gravity, Coulomb, springs and drag, plus a soft containment shell in HALO mode. Contacts are resolved separately with impulses, using the velocity at the contact point rather than at the centre, so tangential friction spins the surfaces the way meshing gears turn each other. A moment of inertia of 2/5 m r² is used for a solid sphere.

Broad-phase collision detection bins bodies into a grid sized to the largest radius, and only walks half the neighbourhood, so each pair is visited exactly once with no duplicate bookkeeping.

10. Verified accuracy

Every one of these was measured in the running tool against the exact analytic answer, not assumed.

LawMeasuredExact
Kepler III, T²/a³ at three radiiidentical to 4 digitsconstant
Vis-viva along an ellipse0.0000% error0
Circular orbit radius drift0.029%0
Free fall velocity after 2 s1039.891040
Terminal velocity under drag260.000260
Spring period0.2096 s0.2094 s
Coulomb, distance doubledratio 4.0004
Successive bounce heights0.360, 0.360, 0.360e² = 0.36
Elastic impact, unequal masses83.16 / 223.1683.15 / 223.16
Sliding sphere settling into a roll142.865/7 × 200 = 142.857
Linear momentum, internal forces onlyexactconserved
Energy, gravitational two-body over 10 s0.000% driftconserved
Hydrogen ⟨r⟩, 3d orbital10.5510.5
Δx·Δp across a 20× squeezeconstantℏ/2

Once a sphere reaches rolling without slipping, the contact point has no relative velocity, static friction does no work, and it rolls at a constant speed. Measured loss over seven hundred units of travel: zero percent.

11. Known limitations

Stated plainly, because a tool that hides its approximations is harder to trust.

12. Exporting

Three ways out, in increasing order of quality:

For a seamless loop: pick ORBIT 360, SPIRAL or PENDULUM, keep TIME SCALE steady, and render. The last frame matches the first.

13. If it stutters

Cost grows with pixels far more than with body count. In order:

For reference, after optimisation: 4K at render scale 2 runs about 30 FPS, the default scale runs about 68 FPS, and a 900-body attractor runs about 90 FPS.

14. Common questions

Is PHYS//LAB free, and do I need an account?

It is free and there is no account, no sign-up and no install. The whole tool is one HTML file with no dependencies, and it keeps working offline once it has loaded.

What does PHYS//LAB actually simulate?

Newtonian gravity between every pair of bodies, softened at very short range; collisions between spheres with friction and restitution; cloth as a pinned mesh with bend resistance and air drag; fractal structures; and hydrogen orbitals drawn by sampling the real probability density. Time is stepped with velocity Verlet rather than naive Euler, which is what keeps long orbital runs from drifting apart.

How accurate is PHYS//LAB?

Every law was measured in the running tool against the exact analytic answer, not assumed; the whole table is in section 10. Vis-viva along an ellipse comes out at 0.0000% error, Kepler's third law is identical to four digits at three different radii, a gravitational two-body run drifts 0.000% in energy over ten seconds, and a sliding sphere settling into a roll lands on 142.86 against the exact five sevenths of 200, which is 142.857.

What are the known limitations of PHYS//LAB?

Three, stated plainly in section 11. Angular momentum drifts one to two percent in scenes with many simultaneous contacts, which is the price of the positional correction that stops resting bodies sinking into each other; linear momentum and energy stay exact. Gravity is softened at very short range, so an extremely close pass is gentler than a true inverse square. And it is spheres only: no boxes, no arbitrary shapes, no joints beyond springs.

How many bodies can PHYS//LAB handle?

Ordinary simulation and every motion that does not test body against body (DEPTH, SPIN, SWIRL, BREATHE) are unaffected at any size. The three moves that need full collision between every pair, COLLAPSE, BURST and DROP, switch themselves off above 1400 bodies. That line was measured rather than guessed: verified at 1420 real bodies, collision costs 8.2 ms and gravity 9.4 ms, against a 16.7 ms frame budget.

Can I export images or video from PHYS//LAB?

Three ways, in increasing order of quality: SNAP PNG for a single full-resolution still, RECORD for a real-time capture of the canvas, and RENDER + SAVE in the SHOT tab, which works frame by frame at a fixed timestep along the camera timeline. Use the last one for anything you intend to keep.

Open PHYS//LAB →