Generative Algorithmic

# Typography System

## Display Typeface

| Property | Specification |
|----------|--------------|
| **Register** | Technical sans-serif or monospace — secondary to the visuals |
| **Examples** | Space Grotesk, IBM Plex Mono, JetBrains Mono, Archivo, Roboto Mono |
| **Weight** | 400-500 (regular — utilitarian, not elegant) |
| **Tracking** | 0.01em-0.03em (slightly open, legible at small sizes) |
| **Size** | `clamp(1.25rem, 2.5vw, 2.5rem)` — moderate, never monumental |
| **Transform** | Sentence case; UPPERCASE only for console labels |

**Why technical type:** The visuals are computed — the type should read as instrumentation, not editorial voice. Monospace and technical sans (Space Grotesk, IBM Plex Mono) share the code's DNA: geometric, uniform, mechanical. The type is secondary to the canvas; it annotates the artwork without competing with it.

---

## Body Typeface

| Property | Specification |
|----------|--------------|
| **Register** | Same family as display — the type system is one instrument |
| **Examples** | Space Grotesk Regular, IBM Plex Mono 400, JetBrains Mono 400 |
| **Weight** | 400 (regular — no elegance, no weight games) |
| **Tracking** | 0.01em-0.02em (standard) |
| **Size** | `clamp(0.875rem, 1vw, 1rem)` — 14-16px |
| **Line Height** | 1.5-1.6 (compact, code-like) |

**Why monospaced rhythm:** Body text in monospace inherits the grid of the code that generated the page. Fixed-width glyphs create a visible algorithmic rhythm — every line aligns to the same column grid, like source code rendered as prose.

---

## Micro / Label Type

| Property | Specification |
|----------|--------------|
| **Register** | Monospace, regular weight, tight tracking |
| **Examples** | IBM Plex Mono 400, JetBrains Mono 400 |
| **Weight** | 400 |
| **Tracking** | 0.05em-0.1em (moderate — machine annotation, not luxury spacing) |
| **Size** | 10-11px |
| **Transform** | UPPERCASE |

**Usage:** Seed values, coordinates, iteration counts, FPS readouts, parameter labels. These are the console layer — "SEED 1742", "FPS 60", "PARTICLES 4096", "NOISE 0.62". They should read like terminal output: fixed-width, dimmed, factual.

---

## Type Scale

```
Display:  clamp(1.25rem, 2.5vw, 2.5rem)  — moderate, technical
Body:     clamp(0.875rem, 1vw, 1rem)     — 14-16px, regular weight
Micro:    10-11px                        — console annotations, UPPERCASE
```

The scale is compact — 10px to 40px. Typography never dominates; the page hierarchy is carried by the visuals, not the type. The type scale exists to be readable and precise, like a readout under a visualization.

---

## Font Pairing Logic

**Single instrument approach:** One technical family — monospace (IBM Plex Mono / JetBrains Mono) for interface and labels, optionally paired with one geometric sans (Space Grotesk / Archivo) for display only. The pairing is minimal: sans for the headline, mono for everything computational. Two voices max — the canvas is the third, loudest voice.

**Never:** Serif typefaces (editorial elegance contradicts the computational register), script or decorative fonts (personality competes with the algorithm), oversized display type (the artwork is the hero — type must stay annotation-sized).

# Color Architecture

## Ground

The ground is the canvas itself — the visual field generated by code. There is no static background color; the base is computed per-frame:

```css
--color-ground-dark: #0A0C10;     /* Near-black with cool undertone — empty canvas */
--color-ground-light: #F2F1EE;    /* Off-white — bright canvas, low-saturation base */
```

**Why tinted neutrals:** Pure #000000 or #FFFFFF reads as static, designed color. Tinted near-black (#0A0C10) and off-white (#F2F1EE) act as neutral seed states — the empty field the algorithm paints into. The ground should feel like a blank buffer before the shader runs, not a deliberate backdrop.

---

## Algorithmically Derived Palette

```css
--gen-mono-1: #0A0C10;        /* Deep neutral — particle trails sink here */
--gen-mono-2: #3A4046;        /* Mid graphite — field density midtones */
--gen-mono-3: #8B939C;        /* Cool gray — noise floor, inactive state */
--gen-mono-4: #D8DCE0;        /* Pale gray — fine mesh, low-amplitude noise */
--gen-mono-5: #F2F1EE;        /* Off-white — brightest value, sparse accents */
```

**Usage:** The base palette is a monochrome value ramp. Colors are not chosen — they are **sampled** from this ramp by noise fields, particle lifetimes, and distance functions. The palette is a probability distribution, not a swatch book.

---

## Saturated Signal Accents

```css
--accent-cyan: #22D3EE;       /* Cyan — data signal, active particles */
--accent-green: #34D399;      /* Green — growth (L-systems), positive values */
--accent-amber: #FBBF24;      /* Amber — heat, density, energy peaks */
--accent-magenta: #E879F9;    /* Magenta — rare emergent event, seed highlight */
```

**Usage:** Saturated accents are **earned, not applied**. They appear where the algorithm decides — a particle crossing a threshold, a noise field exceeding an amplitude, a voronoi cell winning a competition. Saturation is proportional to signal strength: `color = lerp(mono, accent, signal)`.

**Rule:** Saturation must be rare and data-driven. If the accent color covers more than ~10% of the viewport, the signal is fake. Accents exist to make the algorithm legible — the viewer should read *where the computation is loud*.

---

## Gradient / Noise-Field Color

```css
--noise-field-gradient: linear-gradient(
  135deg,
  rgba(34, 211, 238, 0.25),
  rgba(139, 147, 156, 0.15),
  rgba(232, 121, 249, 0.25)
);
```

**Usage:** Gradients are treated as **fields** — continuous functions over space, not decorative fills. A gradient driven by a Perlin noise seed shifts with time and scroll position. The gradient is a visualization of the field itself; it must move, breathe, and re-seed.

---

## Text

```css
--color-text-on-dark: rgba(242, 241, 238, 0.9);  /* Near-white, near-opaque — code console */
--color-text-on-light: rgba(10, 12, 16, 0.9);    /* Near-black, near-opaque */
--color-text-muted: rgba(242, 241, 238, 0.45);  /* Muted — parameter labels, seed values */
```

**Why near-opaque text:** Unlike dreamlike styles, Generative Algorithmic text is a **console layer** — coordinates, seeds, parameters. Text is readable annotation over the generated field, closer to an IDE than a poster. Muted text (45%) is reserved for machine metadata: `SEED 42`, `FPS 60`, `ITERATIONS 1000`.

---

## Color Don'ts

| Don't | Do Instead |
|-------|------------|
| Hand-picked brand palettes | Algorithmically sampled values from a neutral ramp |
| Constant accent colors | Signal-proportional saturation — accents only where data is loud |
| Static gradient backgrounds | Time-evolving noise-field gradients, re-seeded |
| Pure #000000 or #FFFFFF | Tinted neutrals #0A0C10 / #F2F1EE as seed states |
| Fully saturated scenes | Monochrome base, saturation below ~10% of viewport |
| Color that encodes nothing | Every color change must map to a computed value |

# Motion Principles

## Philosophy

Motion in Generative Algorithmic is **computed, continuous, and alive**. Nothing animates on a timeline; everything is driven by a running system — particles, noise fields, emergent behavior. The page is never idle and never static: if the render loop stops, the page is dead. Motion is not an effect applied to content — it IS the content. Continuous procedural animation, particle systems, noise-driven movement, real-time rendering — the motion axis is the highest-scoring axis in this style (6/6).

---

## Continuous Particle Flow

```js
// Conceptual — particle systems run on the render loop
function updateParticle(p, time, noise) {
  const angle = noise(p.x * 0.001, p.y * 0.001, time * 0.05) * TWO_PI;
  p.x += Math.cos(angle) * p.speed;
  p.y += Math.sin(angle) * p.speed;
  p.alpha = Math.max(0, 1 - p.age / p.lifetime);
}
```

| Element | Behavior | Lifespan |
|---------|----------|----------|
| Particles | Flow along noise field vectors — drift, swirl, converge | 3-8s, then respawn |
| Trails | Fade with age, leave residue | 1-2s fade |
| Count | 500-4000 particles, adaptive to device | — |
| Speed | 0.2-1.5 px/frame, field-scaled | — |

**The flow should never repeat.** A noise field re-sampled each frame guarantees unique trajectories — no two particles follow the same path. The motion feels alive because it is genuinely unscripted.

---

## Noise-Driven Field Distortion

```css
@keyframes field-drift {
  0%, 100% { transform: translate3d(0, 0, 0) scale(1); }
  50% { transform: translate3d(0.5%, 0.5%, 0) scale(1.005); }
}
```

| Element | Animation | Duration | Easing |
|---------|-----------|----------|--------|
| Background field | Noise offset drift + scale breathing | 12-20s | `ease-in-out`, infinite |
| Voronoi cells | Cell boundary displacement via noise | 8-15s | `ease-in-out`, infinite |
| Procedural geometry | Vertex displacement, sin/noise waves | 6-10s | `ease-in-out`, infinite |

**The field should feel like it's computing.** Every frame re-samples the noise at a slightly different offset — the texture of the page slowly distorts, stretches, relaxes. Like heat shimmer over a grid, the movement is continuous and never completes.

---

## Emergent Behavior

| Effect | Specification |
|--------|--------------|
| Particle convergence | Particles occasionally cluster into recognizable forms, then dissolve |
| Attractor / repeller fields | Cursor acts as a force — particles scatter or collect around it |
| Lifecycle events | Rare emergent moments: bursts, synchronized pulses, cascade flips |
| State resets | Algorithm re-seeds every N seconds or on interaction |

**The page should surprise itself.** Emergent behavior is what separates algorithmic motion from animated CSS: the system occasionally produces something nobody scripted — a spiral, a wave, a flock. These moments are rare (seconds apart), unpredictable, and are the entire point of code-as-art.

---

## Canvas / WebGL Render Loop

| Parameter | Specification |
|-----------|--------------|
| Renderer | Canvas 2D or WebGL — full-viewport, viewport IS the canvas |
| Frame rate | 60fps target, capped; never CSS-transitioned background |
| Redraw | Continuous — no idle state |
| Interaction | Cursor position feeds the noise field (attract/repel) |
| Scroll | Scroll position re-seeds or re-samples the field |

**The page never sleeps.** A CSS-animated page has a finite animation; a procedural canvas is a live system. If the tab is visible, it renders. Real-time rendering is a hard requirement — degrade to a still frame only on `prefers-reduced-motion`.

---

## Interaction States

| Element | Hover / Focus State | Active State |
|---------|--------------------|--------------|
| Cursor | Acts as force field — particles react within radius | Drag = attract, release = scatter |
| UI controls | Parameter readouts update live (seed, count, speed) | Re-seed the field on click |
| Links | Mono text brightness 0.7 → 1.0 (150ms) | — |
| Buttons | "Generate" / "Re-seed" trigger new seed, visual burst | Immediate — the system responds |

**Interactions are computational.** Hovering a control shouldn't just style it — it should affect the field (a repeller force, a live readout). Every click is a system event: re-seed, toggle layer, adjust parameter.

---

## Reduced Motion

When `prefers-reduced-motion: reduce`:
- Particle systems: static frame (render once, no loop)
- Field distortion: disabled
- Emergent events: disabled
- Scroll-driven re-seeding: disabled

```css
@media (prefers-reduced-motion: reduce) {
  canvas, .field-layer {
    animation: none !important;
    transition: none !important;
  }
}
```

Render a single composed frame at the current seed instead of looping. The static frame must be a *good* still — the algorithm still produces the artwork, it just doesn't run it.

---

## What NOT to Animate

| Never | Why |
|-------|-----|
| CSS-only decorative animation | The style's core is canvas/WebGL — CSS-only design is banned vocabulary |
| Scripted, repeating loops | Scripted loops are timelines; this style computes, not choreographs |
| Staggered scroll reveals | DOM choreography contradicts "viewport IS the canvas" |
| Bounce / spring physics | Physical comedy is not procedural beauty |
| Auto-playing media | The page itself is the media — it never stops |
| Static imagery with CSS hovers | Static imagery is banned — motion must be generative |

# Layout Grammar

## Grid System

**No traditional DOM grid.** The viewport IS the canvas — a WebGL/Canvas surface that owns the frame. Content is an overlay, not a layout. Internally:

- Canvas layer: fixed inset-0, full viewport — `position: fixed; inset: 0`
- HUD overlay: absolutely positioned console layer, `pointer-events: none` on non-interactive elements
- Text containers: narrow (max-width 480px), edge-anchored, never centered
- Content zones: corners and edges only — the center belongs to the computation
- Density: low (axis 3) — the field breathes; UI must not crowd the generated surface

---

## Hero Section

| Property | Specification |
|----------|--------------|
| Height | Full viewport — `min-h-[100dvh]` |
| Background | Live Canvas/WebGL render — particle system or noise field, running continuously |
| Text position | Edge-anchored — bottom-left console block, top-right metadata |
| Headline size | `clamp(1.25rem, 2.5vw, 2.5rem)` — moderate, technical, never monumental |
| Text opacity | 90% — console layer, readable annotation over the field |

```
┌─────────────────────────────────────────┐
│  SEED 1742 · FPS 60 · PARTICLES 4096    │
│                                         │
│  [Live particle system]                 │
│  [Noise field — flows continuously]     │
│  [Every visit renders differently]      │
│                                         │
│  GENERATIVE FIELD                       │
│  Code-as-art. Computed, not designed.   │
│  [ENTER]                                │
└─────────────────────────────────────────┘
```

**The canvas is the hero.** The computation fills the viewport and runs before, during, and after the text exists. Text is a console overlay — seeds, parameters, coordinates. If the render is removed, there is no page.

---

## Section Spacing

```css
--section-padding-y: clamp(3rem, 8vh, 6rem);
--content-max-width: 480px;
--edge-margin: clamp(1.5rem, 4vw, 4rem);
--hud-gap: clamp(0.75rem, 1.5vw, 1.5rem);
```

**Spacing is the negative space of the algorithm.** Sections are separated by transitions in the field (noise re-seed, density shift), not by backgrounds or borders. The pacing is continuous — the render never stops between sections.

---

## Layout Patterns

### Pattern 1: Full-Viewport Canvas + Console Overlay
```
┌─────────────────────────────────────────┐
│  [Live canvas render — entire viewport] │
│                                         │
│      HUD: seed, params, labels          │
│      (corners and edges only)           │
│                                         │
│  ┌──────────────────────┐               │
│  │ SEED 1742  FPS 60    │  ← console    │
│  └──────────────────────┘     block     │
└─────────────────────────────────────────┘
```

### Pattern 2: Canvas + Split Content Strip
```
┌─────────────────────────────────────────┐
│  [Canvas render continues behind]       │
│                                         │
├──────────────────┬──────────────────────┤
│  Label           │                      │
│  Headline        │  [Secondary render:  │
│  Body text       │   voronoi / flow     │
│                  │   field detail]      │
│  SEED 8921       │                      │
└──────────────────┴──────────────────────┘
```

### Pattern 3: Iterative Sequence (Parameter Evolution)
```
┌─────────────────────────────────────────┐
│  [Field state A — seed 001]            │
│  (evolves as you scroll — same seed,    │
│   new parameters)                       │
├─────────────────────────────────────────┤
│  [Field state B — re-seeded]           │
│  (structure morphs, logic persists)     │
├─────────────────────────────────────────┤
│  [Field state C — rule change]         │
│  (same system, different rules)         │
└─────────────────────────────────────────┘
```

---

## Responsive Behavior

| Breakpoint | Layout Change |
|------------|--------------|
| **Desktop (1200px+)** | Full-viewport canvas, HUD in all four corners, console blocks edge-anchored |
| **Tablet (768px)** | Canvas full-viewport, HUD consolidated to top and bottom edges, reduced particle count |
| **Mobile (375px)** | Canvas full-viewport, HUD collapses to bottom sheet, particles capped (~25% density), continuous animation preserved |

**On mobile:** The canvas still dominates — it is the entire page. The HUD becomes a single bottom-anchored console block; corner metadata drops to seed + FPS only. Performance is prioritized: particle counts scale down before anything else.

---

## Layout Don'ts

| Don't | Do Instead |
|-------|------------|
| Centered content blocks | Edge-anchored, asymmetric console placement |
| Card grids | A continuous canvas field with floating HUD elements |
| Boxed/bordered containers | HUD elements that float directly over the render |
| Solid color section backgrounds | Field transitions — noise re-seeds and density shifts |
| Dense text areas | Minimal console text — the computation carries the weight |
| Static hero images | A live render running on every visit |
| Standard navigation | Minimal HUD nav, mono labels, always on canvas |

# Texture & Surface

## Primary Texture: Procedural Patterns

The texture IS the computation. Every surface is generated from code — there are no image assets, no stock photography, no baked textures:

| Pattern | Description | Generator |
|---------|-------------|-----------|
| **Perlin / simplex noise** | Smooth, continuous value fields — the base texture of the page | `noise()` sampled per-pixel or per-vertex |
| **Voronoi cells** | Polygonal cell divisions — cellular structure, growth boundaries | Distance-field Voronoi |
| **Particle residue** | Trails and marks left by moving particles | Particle system history buffer |
| **L-system growth** | Recursive branching structures — plants, crystals, fractals | L-system string rewriting |
| **Flow fields** | Directional vectors rendered as strand/line texture | Noise field sampled along paths |

**The goal:** Every visible surface must be derivable from a function. If you can't describe the texture as an algorithm, it doesn't belong on the page. The texture is data-driven — it changes when the seed, the parameters, or the time step change.

---

## Cellular Noise / Voronoi Surfaces

```js
// Conceptual — voronoi cell rendering
function voronoi(p, cells) {
  let nearest = Infinity, cell = 0;
  for (let i = 0; i < cells.length; i++) {
    const d = dist(p, cells[i].pos);
    if (d < nearest) { nearest = d; cell = i; }
  }
  return cell;
}
```

```css
.voronoi-layer {
  background: transparent;  /* computed per-frame on canvas */
  filter: contrast(1.05) brightness(0.98);
}
```

**Purpose:** Voronoi cells give surfaces a cellular, organic-but-computed quality — crackle patterns, cell membranes, territory maps. Cell borders shimmer as the seed points drift. Voronoi is the texture of *structure emerging from randomness* — the signature generative-algorithmic surface.

---

## Digital Noise Textures

| Texture | Technique | Parameters |
|---------|-----------|------------|
| **Perlin noise field** | Smoothed value noise, 2-4 octaves | Frequency 0.005-0.02, octaves 3, persistence 0.5 |
| **Value noise grain** | Raw random values, smoothed | Cell size 1-3px |
| **FBM (fractal Brownian motion)** | Layered noise octaves | 4-6 octaves, lacunarity 2.0 |
| **Domain warp** | Noise sampling noise | Displacement 20-80px |

**The grain is real data.** Unlike a film grain overlay, generative noise is a live field — it ripples, warps, and responds to the cursor. The texture looks like static because it IS a computed signal, not a flattened effect.

---

## Recursive & Data-Driven Surfaces

| Surface | Treatment |
|---------|-----------|
| **L-system branching** | Recursive growth lines — trunk → branch → twig, 4-8 iterations |
| **Fractal subdivisions** | Self-similar sub-patterns at every scale (diamond-square, midpoint displacement) |
| **Data-driven texture** | Texture maps to live data: FPS, time, mouse position, scroll velocity |
| **Grain from randomness** | Seeded random placement — deterministic per seed, unique per seed |

**The texture must be honest:** if it's data-driven, the data must be real. A texture that claims to visualize the system but is actually a static overlay is the worst kind of fake. Texture density is derived from the density axis (3/6) — moderate: present everywhere, dominant nowhere.

---

## Surface Rules

| Surface | Treatment |
|---------|-----------|
| Background | Full-viewport canvas — noise field, particle trails, procedural pattern |
| Text overlays | Near-opaque (90%), console-layer annotation over the field |
| UI elements | Minimal frames, hairline borders, translucent fills |
| Buttons | "Generate" / "Re-seed" — mono labels, thin outlines, hover = field reaction |
| Navigation | Compact technical strip — coordinates-style links |
| Dividers | None — the field itself separates sections |

**No cards, no panels, no solid backgrounds.** The only surfaces are the generated field and thin instrumentation over it. The UI is a HUD on top of a live simulation — flat, thin, monospaced, and secondary.

---

## Texture Don'ts

| Don't | Do Instead |
|-------|------------|
| Stock photography | Procedurally generated patterns — Perlin, voronoi, L-systems |
| Static grain overlays | Live noise fields — sampled per frame |
| Baked raster textures | Code-generated vector/field textures |
| Random decorative patterns | Seeded, deterministic randomness |
| CSS gradient "noise" | Real algorithmic texture — canvas/WebGL computed |
| Flat solid backgrounds | The generated field IS the background |

# Vocabulary Bank

## Primary Terms

| Term | Why It Matters |
|------|---------------|
| `procedural generation` | Visuals computed by algorithm at runtime instead of pre-designed — the core of the style |
| `particle system` | Thousands of lightweight particles driven by rules — the page's living cells |
| `Perlin noise` | Smooth, organic gradient noise used to drive motion, color, and form |
| `WebGL canvas` | GPU-accelerated rendering the page is built on, not the DOM |
| `real-time render` | Every frame computed live — the scene changes on every visit |

---

## Secondary Terms

| Term | Effect |
|------|--------|
| `flow field` | Particles steered by a vector field — everything drifts along invisible currents |
| `voronoi pattern` | Cell-based tessellation from seed points — organic, data-driven geometry |
| `L-system` | Recursive grammar that grows branching, plant-like structures |
| `seed` | A fixed starting value reproducing the exact same procedural output |
| `field line` | Trace a single particle's path through a noise field — the signature generative mark |
| `distributed motion` | Individual elements each with their own tiny offset — alive without coordination |
| `recursive pattern` | Self-similar structure repeated at smaller scales — infinite depth in a frame |
| `data-driven texture` | Texture derived from computed values, not bitmap assets |
| `fragment shader` | Per-pixel color computation on the GPU — full-screen algorithmic fields |

---

## Context Terms

| Term | Mood |
|------|------|
| `emergent behavior` | Complex global patterns from simple local rules — the system exceeds its code |
| `seeded randomness` | Chaotic but reproducible — every seed is a new world you can return to |
| `code-as-art` | The algorithm is the artwork; the browser is the gallery |
| `always alive` | Movement never stops — the page is a living system, not a static frame |
| `creative coding` | Programming as artistic medium — the culture this style comes from |
| `generative art` | Artwork where the artist writes the rules, not the final image |
| `canvas over DOM` | Rendering on a single full-viewport canvas rather than styled elements |

---

## Banned Terms

| Term | Why It Breaks the Style |
|------|------------------------|
| `static imagery` | The visuals must be alive and computed, never fixed files |
| `traditional DOM layout` | The viewport IS the canvas — no boxed, element-driven page |
| `CSS-only design` | Code generates the imagery; CSS alone cannot make it alive |
| `stock photography` | Stock images are the opposite of procedural generation |
| `pre-rendered assets` | Frames exist before runtime — defeats the always-alive principle |
| `fixed gradients` | Gradients must be animated through noise, not static fills |
| `pixel-perfect mockups` | The work is the system, not a frozen screenshot |
| `hero image` | SVGs and photos step aside — the code itself is the hero |

---

## Prompt-Ready Phrases

```
"WebGL canvas particle system as the entire page (1000+ particles)"
"Perlin noise field driving organic drift — motion from the noise field"
"flow field — particles steered along an animated vector field"
"voronoi-based interlaced, data-driven geometry"
"L-system branching, recursive structures grown at runtime"
"seeded randomness — deterministic, reproducible per seed value"
"algorithmic palette — hue/saturation derived from noise, not hardcoded"
"monospace / technical sans-serif labels — text is metadata, visuals lead"
"minimal UI floating over the live canvas — viewport IS the canvas"
"continuous procedural animation — never static, changes on every visit"
"reduced-motion: freeze the field into a single seeded frame instead of stopping"
```

# When to Use

## Perfect For

| Context | Why This Style Works |
|---------|---------------------|
| **Creative technologist portfolios** | The work IS the medium — code-as-art demonstrates the skills directly |
| **Experimental studios** | Procedural visuals prove the studio's creative-coding capability |
| **Data art installations** | Particle systems and noise fields turn data into living, breathing visuals |
| **Music visualizations** | Real-time rendering and continuous motion match audio dynamics |
| **WebGL showcases** | The style foregrounds the tech it was built with |
| **Generative art platforms / NFT projects** | Seeded randomness and algorithmic palettes feel native to the genre |
| **Tech-forward brand campaigns** | Always-alive visuals make every visit feel like a premiere |

## Brand Personality Match

This style reinforces brands that are:
- **Procedural** — comfortable with visuals being computed, not designed
- **Alive** — never static, always animating, ever-changing
- **Experimental** — pushing boundaries of what a web page can be
- **Precise** — algorithmic rigor rather than hand-drawn whimsy
- **Code-first** — engineers and creative coders as the audience and the subject

## Avoid When

| Context | Why It Fails |
|---------|-------------|
| **Corporate/B2B** | Continuous motion and canvas rendering undermine formal credibility |
| **E-commerce** | The viewport-as-canvas layout can't support product grids or checkout |
| **News/journalism** | Readability dies when text is secondary to particle systems |
| **Healthcare** | Always-alive, disorienting motion is the opposite of reassuring |
| **Government/legal** | Too experimental, too "internet" |
| **Content-heavy sites** | Non-traditional DOM can't carry long-form reading structure |
| **Brands needing trust** | Ever-changing visuals feel unstable — nothing is ever the same twice |
| **Mobile utility apps** | Real-time rendering costs battery and performance for no benefit |

## How to Decide

Ask: **"Does my brand want to feel like a living algorithm — computed, precise, and different on every visit?"**

If yes → Generative Algorithmic / Code-Art.
If no → Consider Data Visualization Aesthetic (if you want data-driven but readable and static), Dark Tech Terminal (if you want technical but DOM-native and text-led), or Data as Texture (if you want algorithmic flavor without canvas takeover).

Reference points: **Data Visualization Aesthetic** (axis color 5, texture 6 — shares algorithmic color and texture but keeps editorial layout), **Dark Tech Terminal** (axis motion 3 — technical and dark but restrained in movement), **Data as Texture** (axis texture 6 — borrow the noise-field texture without the full canvas commitment).

# Reference Gallery

## Live Sites

### Generative Algorithmic Reference Implementation
- **What works:** Procedural canvas/WebGL visuals, particle systems, Perlin noise fields, #BFDB38-style algorithmic accent on algorithmically derived bases, gradient/noise color, monospace or technical sans secondary to visuals, continuous motion
- **URL:** Reference implementation — the canonical example of this style

### Patrik Hübner (huebite.com)
- **What works:** Creative technologist portfolios, WebGL/Three.js experiments, procedural 3D and 2D graphics, strong motion design
- **URL:** huebite.com

### ShaderToy (shadertoy.com)
- **What works:** The definitive shader playground — real-time fragment shaders, noise fields, procedural geometry, algorithmic color computed per-pixel
- **URL:** shadertoy.com

### Chrome Experiments
- **What works:** Canonical WebGL/canvas showcase — particle systems, flow fields, generative art, real-time rendering
- **URL:** experiments.withgoogle.com/collection/chrome (browse the WebGL and canvas archives)

### Nvidia Studio (nvidia.com/en-us/studio)
- **What works:** Technical, precise dark aesthetic wrapping real-time rendering and generation tools — code-adjacent without full canvas takeover
- **URL:** nvidia.com/en-us/studio

### Generative Art / NFT Platforms (fxhash, Art Blocks)
- **What works:** Seeded-random generative output, algorithmically derived palettes, particle and voronoi studies, "different on every visit" ethos
- **URL:** fxhash.xyz, artblocks.io

## Key Visual References

### Procedural Techniques
- **Particle systems** — thousands of particles with velocity, gravity, and repulsion
- **Noise fields** — Perlin/Simplex noise driving position, color, and flow
- **Voronoi patterns** — cell-based segmentation, often animated and colored per-cell
- **L-systems** — recursive branching structures (plants, fractals, tree-like forms)
- **Flow fields** — noise-driven vectors curving particle paths through space
- **Seeded randomness** — the same seed reproduces the same artwork; new seed, new piece
- **Procedural geometry** — meshes, grids, and extrusions computed at runtime, not modeled

### Color References
- **Algorithmically derived palettes** — color mapped through noise fields, hue rotation, or gradient ramps rather than fixed swatches
- **Gradient-based bases** — continuous color transitions across the viewport
- **Neon accents on dark** — bright algorithmic hues (electric greens/cyans/magentas) against deep procedural dark bases
- **Monochrome → accent** — grayscale particle fields punctuated by a single computed color pop

### Typography References
- **Monospace or technical sans-serif** — JetBrains Mono-style, secondary to the visuals
- **Minimal UI labels** — small, uppercase, wide-tracked; never competing with the canvas
- **Small sizes** — display small, body 14-16px, minimal text overall
- **Code-echo styling** — monitored labels, version/seed readouts, FPS counters as decoration

### Motion References
- **Continuous procedural animation** — never-ending, never identical
- **Particle systems** — 60fps canvas updates, gravity and attractor behavior
- **Noise-driven movement** — eased drift, 8-16s cycles, Perlin-sampled
- **Real-time rendering** — scroll and pointer input feed the simulation
- **Entrance** — fade/scale in 800-1500ms; simulation state persists, page never settles

## Screenshot Notes

> When capturing references for this style, look for:
> - The visuals (must be procedural/generative — canvas/WebGL, not stock photography)
> - The color palette (must be algorithmically derived — gradients, noise-driven, not fixed flat swatches)
> - The motion (must be continuous and alive — not one-shot entrance animations)
> - The text density (must be minimal — the canvas carries 90% of weight)
> - The UI shapes (must shed traditional DOM chrome — viewport IS the canvas)
> - The interaction (pointer/scroll must steer the simulation, not just scroll the page)
> - The overall mood (must feel like a living machine — computed, precise, ever-changing)