`/simulate/assets` on lumbridgecorp.com argues that the art in this repository
is code — eight textures drawn on a 2D canvas from seeded value noise,
thirty-five surface roles pairing one of those with a colour and a roughness,
and no binary art anywhere, enforced by a CI job. It made that argument in about
four thousand pixels of prose with nothing on it to look at, which is a strange
way to talk about the appearance of things.
`textures.mjs` writes the library out: one tile per texture kind drawn by
`TextureBin`, multiplied by the colour of the first role that carries it, and a
neutral tile beside it so a reader can see for themselves that the map has no
hue of its own. The role table goes with them as data, so the site sets it in
its own type rather than baking labels into an image.
It is the one capture here that runs against Vite dev rather than `dist/`, and
the reason is in the header of both files. `shots.mjs` and `films.mjs`
photograph the *application*, and the application a visitor gets is the built
bundle. This photographs a *module*. `TextureBin` is not reachable from the
bundle — it exposes no names — and making it reachable would mean a third Vite
entry, which would ship a texture-sheet page to tera.lumbridgecorp.com so that a
script could screenshot it. Vite dev transforms `/src/assets/*.ts` on request,
so the page imports the same files a reader opens on the repository.
Nothing in it re-implements the tables in `materials.ts`: it asks
`MaterialRegistry` for every role in `DEFAULT_INTERIOR_PALETTE` and reports what
comes back, so a role that changes its texture or its roughness changes the
sheet on the website with it.
No GPU, no WebGL, no renderer string to check — Canvas2D and the browser's own
WebP encoder, about two seconds for all sixteen tiles at 97 kB total.
`check-no-binaries` still passes: these live under `scripts/`, and the tiles are
written into the lumbridge-v4 checkout, not this one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
karti
18dadda917