[particles] — for attractor

Key	Values	Notes
family	de_jong, clifford, thomas, lorenz, fern, tree, dragon, sierpinski, spiral	Which figure the compute step iterates. Optional — absent means de_jong. The last five are IFS figures, not strange attractors — see below.
density	0.0005 .. 1.0	How much of the tier’s particle budget to draw. Optional — absent means 1.0, the whole budget. At or below 0.08 it is a count that does not move with the window; at or above 0.16 it is a fraction of a budget that does — see below.
morph_to	any IFS figure name	The figure the bindable morph param travels towards. Optional — absent pins the figure and makes morph inert. A load error on the four map families, which have no table to interpolate.

system = "attractor"

[particles]
family = "lorenz"
density = 0.02

density and fade are one look, not two settings. density decides how many points you are drawing with; fade decides how long each one stays on screen. What you see is the product:

	low fade (short trail)	high fade (long trail)
high density	a crisp stipple — the attractor’s measure, every point an independent sample	fog — so many overlapping trails that the figure fills in solid
low density	a sparse scatter of dots, usually too thin to read	curves — few enough trajectories that you can follow each one, which is the classic plotted attractor

The bottom-right cell is the one density was added for. At density = 1.0 the scene draws the whole budget, and raising fade just makes a denser cloud — you cannot get a trace out of it, because that many simultaneous trails overlap into a solid. Drop to 0.02 or below and the same fade reads as banded spiral curves instead.

A low density is a count; a high one is a fraction of a budget that moves with the window. Since ADR-0140 the attractor’s sample budget is a density against the render target, not a flat tier constant: it is the tier’s own count at 640x360 and below, and rises with the pixel count above that, capped lower in a window than under shot --render. That is the right law for a cloud — the deposit spreads over the render target, and a flat count is what made a 1080p render read as an upscale — and the wrong one for a trace, whose look is how many trajectories there are. So since ADR-0195 the two are separated by where you set the key:

• At or below 0.08 the fraction is taken of the tier’s anchor — its count at 640x360. You get anchor * density trajectories at every window size, live or rendered.
• At or above 0.16 the fraction is taken of the moving budget, exactly as before, so the drawn count rises with the target.
• Between the two the effective budget blends from one to the other, so it scales partly with the window. Nothing shipped is authored there, and it is a steep band — the count rises several-fold across it while density only doubles. Pick a side unless you mean it.

Author to the look, not to a count, and two consequences worth holding: a cloud tuned in a small window keeps its look at 1080p rather than thinning out, and a trace keeps its look because the count itself does not move. docs/capturing.md carries the per-size budget table.

Two things worth knowing before you reach for it:

• Total light does not change when you move it — but the picture does. The engine divides each particle’s deposit by how many are drawn, so the sum is invariant: a sparser cloud is not a dimmer one. That is what makes density a structural choice rather than an exposure control. It is not a free re-aim, though, and the first two presets to go sparse both had to pay for it: the same light landing on a fraction of the pixels is far brighter per texel, so a sparse preset needs a cut on the order of trail frames / density to stay off the tonemap shoulder. Spend that cut on brightness. It is a plain multiplier on the same already-count-normalized deposit, so it composes with density instead of fighting it, and being scene-local it blends as pixels across a dissolve. size and fade also buy level and change the picture while they do it — a wider nib and a longer trail are looks, not stops — so reach for them when you want what they do, not when you only want less light. (attractor_lorenzknot ships brightness = 0.18 at density = 0.02, and the since-retired attractor_lorenz shipped 0.03 at 0.002 — the worked examples of that cut. An older copy of either may carry the same number on exposure instead; the swap is level-neutral and the value transfers unchanged.)
• The tier caps the top, it does not set the value. density is a fraction of whatever the current quality tier allows — 50 000 at the standard tier and 150 000 at the rich one at the 640x360 anchor, and more than that at a larger target (see the note above). So density = 0.02 is 1 000 points on one and 3 000 on the other, at every window size, because that is a trace and a trace resolves against the anchor. Above the cloud boundary you are choosing a proportion instead, and the absolute count follows the target.

It is structural: set once when the preset loads, and not bindable to audio. An eased particle count would re-decide the picture every frame.

The two flow families draw strokes, not dots. thomas and lorenz integrate a trajectory, so each particle’s position this frame is one step along a path from where it was last frame — and the engine draws that whole step as a short segment with rounded ends. de_jong and clifford are maps: each iteration throws the point somewhere else entirely on the figure, so a line between successive positions would be a bright chord across the picture rather than a piece of it. Those two keep drawing dots, and nothing you can set changes either choice — it is a property of the attractor, not a preference.

What that means when you are tuning:

• On lorenz and thomas, low density is finally worth reaching for. The segments join end to end with no gap, so a sparse cloud reads as continuous curves instead of a dotted line. This is the combination the table above calls “curves”, and before the segment existed you could not actually get there — a sparse cloud just looked sparse.
• They are brighter than they used to be, and you may need to pull them back. A segment covers more of the frame than a dot, so the same preset now lays down more light: measured on a plain figure, mean frame luminance went up 2.0x on thomas and 3.1x on lorenz. This is deliberately not compensated in the engine — a faster-moving particle drawing a longer, brighter streak is arguably the correct rendering of speed. If it is too hot for your look, the lever is brightness — one multiplier on the deposit, which is exactly what “the same figure, less light” asks for. size and fade will also pull it back, at the cost of a finer nib and a shorter trace; exposure will too, and should be your last resort rather than your first, because it moves the whole frame.

The family sets the map and the meaning of the four bindable coefficients a/b/c/d, each of which defaults to that family’s canonical value (De Jong 1.641 1.902 0.316 1.525; Clifford -1.4 1.6 1.0 0.7; Thomas uses a alone at 0.19; Lorenz sigma/rho/beta = 10 28 2.667, d unused). Bind them to bands for a morphing cloud, but move them slowly and by a little — these are chaotic maps, and a large jump reads as a hard cut rather than a morph. On the five IFS figures they mean nothing at all — that family’s shape is an affine table, and morph/curl/vigor/lean/bias are what reach it.