Paint: vector background cels on the kept frames
A sketch, and labelled as one. It exists to test whether the aesthetic holds when a human draws the background rather than the tracker deriving it, and it is meant to be replaced by a real paint surface with onion skin and undo. Kept to one dependency-free module so throwing it away is a delete, not surgery. Cels are drawn on the frames that get their own drawing and hold until the next one - the same rule the plate follows, and literally the same lookup, so the two cannot disagree about what is on screen. Editing always targets the cel you can see, so you can scrub anywhere and keep drawing. Pen places vertices and closes on the first one. Edit drags vertices or whole shapes, shift-click inserts, alt-click removes. Layers stack front-at-top with per-layer colour, show/hide and reorder. Drag a strip thumbnail onto the canvas to seed this cel from that one, every layer, as a deep copy - sharing the point arrays would make two cels silently edit each other. Two rules are enforced rather than left to discipline: Colours are PALETTE INDICES, never RGB. Sampling colour from the source is the one move docs/design.md calls irrecoverable, and a paint tool is exactly where that discipline would leak, so the picker cannot express a colour outside the ramp. Vertices snap to the 320x200 grid. On a hard-edged indexed rasteriser a shape nudged by 0.4px moves an edge by a whole pixel or not at all depending on where it happens to land, so sub-pixel vertices shimmer instead of holding still. Drawings autosave to localStorage per take name. They are the only thing here a person made by hand; everything else regenerates. Not in the .take export yet. Also adds serve.py, a no-store dev server. python3 -m http.server sends Last-Modified and browsers cache ES modules on it hard enough that a reload serves a stale app.js against a fresh index.html: the new knobs appear, nothing wires them, no error fires, and it reads as "your feature does not work". That cost real time this session. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
03df81fa0b
commit
9d516a03ac
5 changed files with 558 additions and 3 deletions
43
README.md
43
README.md
|
|
@ -17,10 +17,15 @@ modern conveniences belong in the workflow, not the output. See
|
|||
## Run
|
||||
|
||||
```sh
|
||||
python3 -m http.server 8777 # from this directory
|
||||
# open http://127.0.0.1:8777
|
||||
python3 serve.py # from this directory, then open 127.0.0.1:8777
|
||||
```
|
||||
|
||||
Use `serve.py`, not `python3 -m http.server`. The latter sends `Last-Modified`
|
||||
and browsers cache ES modules on it hard enough that a reload serves a stale
|
||||
`js/app.js` against a fresh `index.html` — new knobs appear in the markup, nothing
|
||||
wires them, no error is raised, and the symptom reads as "the feature does not
|
||||
work". `serve.py` is the same server with `no-store`.
|
||||
|
||||
Static files and ES modules — no build step, no dependencies beyond MediaPipe's
|
||||
wasm, which is fetched from a CDN on first use.
|
||||
|
||||
|
|
@ -267,6 +272,40 @@ egg by construction, and no landmark precision fixes that. Hence the photo.
|
|||
**Save frame 4x** writes the current registered composite as a 1280×800 PNG to
|
||||
draw on.
|
||||
|
||||
## Paint — background cels
|
||||
|
||||
**A sketch.** It exists to test whether the aesthetic holds when a human draws
|
||||
the background instead of the tracker deriving it, and it is meant to be
|
||||
replaced by a real paint surface with onion skin and undo. It is one dependency-
|
||||
free module, `js/paint.js`, so throwing it away is a delete rather than surgery.
|
||||
|
||||
Cels are drawn on the frames that get their own drawing and **hold until the
|
||||
next one** — the same rule the plate follows, and literally the same lookup. You
|
||||
can scrub anywhere and keep drawing on the cel you can see; the header says
|
||||
which one you are editing and how far it holds.
|
||||
|
||||
- **pen** — click to place vertices, click the green box on the first one (or
|
||||
<kbd>Enter</kbd> / double-click) to close.
|
||||
- **edit** — click a shape to select, drag a vertex or the whole shape,
|
||||
<kbd>Shift</kbd>-click an edge to insert a vertex, <kbd>Alt</kbd>-click one to
|
||||
remove it, <kbd>Del</kbd> to delete the layer.
|
||||
- **Layers** stack Photoshop-style, front at the top, with per-layer colour,
|
||||
show/hide and reorder.
|
||||
- **Drag a frame** from the strip onto the canvas to seed this cel from that
|
||||
one, every layer, as a deep copy. **Copy previous** does the same for the
|
||||
previous kept frame, which is the case you reach for constantly.
|
||||
|
||||
Two rules are enforced rather than left to discipline. Colours are **palette
|
||||
indices**, so you cannot pick one that is not in the ramp — sampling colour from
|
||||
the source is the one move `docs/design.md` says is irrecoverable. And vertices
|
||||
**snap to the 320×200 grid**, because on a hard-edged indexed rasteriser a shape
|
||||
nudged by 0.4px moves an edge by a whole pixel or not at all depending on where
|
||||
it lands, which shimmers instead of holding.
|
||||
|
||||
Drawings autosave to `localStorage` per take name. They are the only thing in
|
||||
the tool a person made by hand; everything else regenerates. They are not in the
|
||||
`.take` export yet.
|
||||
|
||||
## Two kinds of sparseness
|
||||
|
||||
Sparseness has two unrelated causes, and conflating them was the original design
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue