So scenography splits the problem in two.

Data vs. runtime​

The whole library rests on one rule: a gallery is data, and behavior is code, and the two never mix.

• A scene definition is plain, JSON-serializable data — walls, artworks, a camera. No three.js, no closures. It is what an editor produces and a database stores.
• The engine is the runtime that materializes that data with three.js and runs it.

import { defineScene } from '@scenography/core';

const scene = defineScene({
  walls: [{ id: 'room', path: [[300, -300], [-300, -300], [-300, 300]], edges: [{ segment: 0, name: 'north' }] }],
  artworks: [{ id: 'lucho', location: { type: 'wall', edge: 'north', position: '50%' }, src: '/lucho.jpg', size: [120, 160] }],
  camera: { start: { position: [0, 170, 0] } },
});

Where we are now​

scenography is in alpha (0.x). The core is working end to end: you can describe a space, render it with a free-roaming camera, hang artworks on named wall edges, layer a DOM overlay over the canvas, and edit the scene on the fly — the engine reconciles changes by id, so you can add a wing or drop one while you walk through it.

The packages today: core (the language), engine (the three.js runtime), props (set dressing), overlay (the HUD), and react (bindings).

What's next​

Walls will gain chamfered and rounded corners and inside/outside offset; floors, ceilings, and textures are coming; and camera tours and zones will arrive as data, with the motion and triggers wired by id in the engine. See the roadmap for the full picture.

The API will keep changing while we're on 0.x — that's the point of alpha. If you try it, open an issue.