Principle 01
Open the instrument, not an installer.
The editor starts from a URL, with no account, license check, or watermark. A browser is the delivery mechanism, not a thin shell around a hosted render service.
About / open by design
Projection mapping should open like a link.
Projektor is an attempt to make the daily mapping loop—add a surface, fit it, give it media, and send it live—available without a native install or closed project format.
Working principles
The product decisions follow from the architecture.
Principle 02
Keep the working state close.
Rendering, project state, autosave, files, camera input, and screen capture stay in the browser. There is no Projektor account, project database, or upload step.
Principle 03
Make the core inspectable.
The editor, render engine, output, and optional MCP server live in the same MIT-licensed repository. The implementation can be read, forked, embedded, and changed.
Principle 04
Treat light like an instrument.
Geometry and show controls stay direct and visible. Projektor favours precise manipulation, quick feedback, and a clean output over layers of setup ceremony.
The engine boundary
The renderer does not know about the interface.
That separation is enforced in the repository. It lets the editor and clean output window share one rendering path, and it keeps the WebGL core usable without the Next.js shell.
Inspect the engine ↗- 01 · EditorReact + Zustand
Turns direct manipulation into validated scene-state changes with undo and redo.
- 02 · ScenePlain data
Carries surfaces, media references, masks, colour, groups, and Looks as serializable state.
- 03 · EngineRaw WebGL2
Consumes that scene without importing React, Next.js, or Zustand, then renders the pixels.
- 04 · OutputBrowser window
Uses the same engine and receives scene updates over a same-origin BroadcastChannel.
Why the browser
The web changes how a mapping project travels.
- 01
Try the full editor before downloading or creating anything.
- 02
Encode a project into a URL that another browser can open and fork.
- 03
Embed a mapped scene in an iframe using the same web-native runtime.
- 04
Use browser camera, screen-capture, MIDI, audio, and display APIs directly.
Honest limits
Browser-based is a boundary, not a magic trick.
Projektor is useful because of what the browser enables. It should be equally clear about the production workflows the browser does not cover today.
One machine
Editor and output synchronize in the same browser profile. Projektor does not distribute output across networked render nodes.
No native video routing
The browser sandbox does not expose Syphon, Spout, or NDI. Those workflows need a native companion or a different tool.
No large-venue control stack
There is no DMX fixture system, multi-projector edge-blending workflow, or full media-server playback environment.
Pre-1.0
Projektor is actively developed, but it does not claim the deployment history or redundancy of established live-production software.
MIT / contributions welcome
Read it, run it, or help shape the next surface.
The contribution guide documents the engine boundary, test gates, and paths for adding shapes and media sources.