Scenography

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 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 behavior is the runtime that materializes 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, tested with Vitest, linted and formatted with oxlint 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.