The WebGL landing page runs directly from static assets.
index.html
,
main.js
, and
style.css
form the entry stack, with
dotmatrix.js
supplying the Three.js particle system. Keep component experiments under
test-*.html
and
test-*.js
to avoid polluting production files. Screenshots and outputs generated by the automated puppeteer checks land in the project root alongside the
images/
asset pack. Empty scaffolds exist under
src/
for future modularization—treat them as staging folders and keep ship-ready code at the root until a bundler is introduced.
Serve the site locally so ES modules resolve:
python3 -m http.server 8000
from the repo root, then visit
http://localhost:8000
. Quick spot checks can target individual harnesses such as
http://localhost:8000/dotmatrix.html
or
simple-test.html
. To verify particle behavior headlessly, run
node verify-dotmatrix.js
; for noise evolution snapshots, use
node test-noise.js
. Both puppeteer scripts assume Chromium at
/usr/bin/chromium
—update the path before running if your setup differs.
Follow the existing vanilla JS style: two-space indentation, trailing semicolons, and
const
/
let
scoped at the narrowest block. Favor camelCase for variables and helper functions (
syncParamsToUniforms
), while keeping exported globals on
window
prefixed meaningfully (
dotMatrixParams
). CSS sticks to kebab-case class names and leverages blend modes; mirror those patterns when adding layers. Inline comments should explain intent, not mechanics, and only appear around complex animation math or shader manipulation.
All automated checks depend on a running dev server—start it before executing puppeteer scripts or they will hang on navigation. Tests write PNGs (
dotmatrix-screenshot.png
,
noise-frame1.png
) and JSON logs to the repo root; review outputs and clean up before committing. When adding new harnesses, mirror the
test-noise.js
structure: launch headless Chromium, wait for uniforms to settle, then assert against
window.dotAttributes
or
window.params
snapshots.
History favors short, imperative commit subjects (
"nice motion"
,
"better sizing"
). Keep that tone, limit subjects to ~50 characters, and describe rationale in the body when needed. Pull requests should link the design or issue thread, list affected HTML/JS sections, and attach fresh screenshots or recorded gifs whenever animations change. Note any flags you toggled (e.g.,
SKIP_INTRO_ANIMATIONS
) so reviewers can reproduce your setup.