Kimetron Isle
— World-Coordinate Canvas

Give coordinates a meaning.

We built both Plesfeda and Sethera Piece on top of React Flow, and that taught us something: what the canvas library handles for you stops at rendering, dragging, selection, and the viewport — layout and domain semantics were all on our side anyway. Which means the coupling is thin, and a replacement is feasible.

But a React Flow clone would be pointless. Looking around, every canvas/diagram library out there uses screen coordinates, pixels, and a downward Y axis. In CAD the coordinate itself is design data — yet no engine treats it as a first-class citizen. That gap is where Kimetron Isle lives.

The world-coordinate model

Object position and size live in real-unit world coordinates, not screen pixels. Zoom is a drawing scale, not a magnification.

• Real units mm / m / inch / px as first-class units — a world where 1 unit = 1 mm, so drawings read like measurements
• Selectable origin Bottom-left + Y-up (CAD/math convention) or top-left + Y-down (screen convention)
• Built-in snapping Grid, vertices, edge midpoints, and centers are engine snap targets; drivers inject their own via snapExtra
• Collision & occupancy solid objects may not overlap while edge-touching stays legal; canOverlap declares pair exceptions and collisionMode (none / flag / reject) picks the behavior
• Rotation & polygons Rotation is honored all the way down to OBB/SAT collision; kind:'polygon' hit-tests and collides correctly even when concave
• Programmatic movement objectsIn (range queries), canPlace, and tryMove — AI-driven motion goes through the same collision policy as gestures
• Undo & serialization Immutable model ops, document-level undo/redo, JSON serialize/deserialize built in

Three layers, and a "thin domain layer"

@kimetron/core (vanilla TypeScript — model, geometry, selection, drag, hit-testing, no DOM), @kimetron/dom (SVG/CSS renderer and pointer input), and @kimetron/react (a thin adapter). Semantics belong to the user: Kimetron assigns meaning only up to geometry and interaction. "A door may sit on a wall", "a rock cannot be moved", "two units may not overlap" — all of these are driver policies.

The proof of that boundary is the driver collection in the repo.

• plan — a building sketch 10 mm grid, thickness×length walls meeting in "|-" junctions, rulers, dimension lines, wall centerlines, and architectural area readouts (site / building / core / inner) — all in a thin driver layer
• game — two units wandering a building 30 cm units roam via tryMove. Solid walls and rocks (locked concave polygons) block; the gate is the only way out; units can't stack, and adjacency triggers effect links
• plesfeda / sethera spikes Our two production apps migrated onto the engine — edge semantics, shape kinds, locking, page frames, and the HUD all fit as-is

The name

Kimetron fuses the Sumerian ki (place, earth — the counterpart of an, heaven) with the Greek metron (measure): "a place that measures" is built right into the letters.

Isle is a floating island — a soft, natural word against the geometric hardness of Kimetron, and a homophone of aisle keeps it from sounding too technical.

An honest status

v1.0.0 is a stability commitment — the API has been additive-only since 0.6.0. There is still room to grow, though.

• Associated dimensions, named layers, block references Structural gaps remain for CAD use; they're the 1.x expansion territory
• Svelte/Vue adapters not built yet "Structurally possible" is the v1.0 promise; implementation follows demand
• No collaboration or cloud storage Local-first by design — data stays in JSON files and localStorage