Scenography
Declarative 3D art galleries: describe a space as data, let a three.js engine run it
Scenography builds 3D exhibition spaces out of data. A gallery is a JSON-serializable description of walls, artworks and a camera, and a three.js (opens in a new tab) engine takes that description and runs it.
The whole design rests on keeping two layers apart. The definition is pure
data: no three.js, no closures, nothing a database cannot store or an editor
produce. The behaviour is the runtime that materialises it, with triggers and
scripts wired by id. Neither half knows how the other is implemented, which is
what makes a scene something you can save, version and edit rather than
something you have to write.
Plugins all the way down
Every element of a scene, walls, artworks, floor, water, sky, audio, light, models and video, is a plugin with a data half and a runtime half. So are the systems: first-person controls, focus, cardboard. The kernel ships none of them, so a project only pulls in what it actually puts on screen.
Stack
TypeScript throughout, with three as a peer dependency rather than a bundled
one. The workspace is a pnpm monorepo laid out as core/* for the kernel and
its bindings, plugins/* for elements and systems, and apps/* for the demo.
Built with tsdown (opens in a new tab), tested with
Vitest (opens in a new tab), linted and formatted with
oxlint (opens in a new tab) and oxfmt. Releases are cut by a CI workflow that
derives the next version from conventional commits, publishes every package to
npm under the @scenography scope, and tags the release.
There are React bindings, a declarative <Gallery> component, but the core is
framework-agnostic on purpose: the overlay layer is plain DOM, and nothing in
the kernel assumes a UI library.
Status
Alpha (0.x) and under active development. The API changes between minor
releases and it is not meant for production yet. The source lives on
Codeberg, where I am focusing my open-source visibility.