Summary
The MCP package documents units (metres) and per-tool parameters well, but I couldn't find an author-facing statement of the coordinate convention. When generating geometry programmatically (e.g. from a land survey), this is the first thing you need and currently have to reverse-engineer from source.
What's missing
There's no doc stating that:
- 2-D points —
wall.start/wall.end and the polygon/holes of slab, zone, ceiling — are [x, z] on the X–Z ground plane, with Y up.
- The second component maps straight to world Z, no negation: the editor builds geometry as
new Vector3(point[0], y, point[1]).
- Rotations are radians, stored as Euler
[x, y, z] tuples.
This matters for anyone authoring from a north-up source (a survey with bearings from North, a north-up site plan, most 2-D plotting libraries): because the plan embeds into X–Z, such layouts come in mirrored when viewed top-down, and there's currently no note about it. examples/generate-apartment.md only uses axis-aligned boxes ([0,0] → [10,0]), so the handedness never surfaces in any example.
Suggestion
Add a short "Coordinate conventions" section to packages/mcp/README.md: axes, units, radians, the [x,z] → (x, y, z) mapping, the top-down-mirror caveat for externally-computed coordinates, and one non-axis-aligned example. Happy to open a PR if that's welcome.
Verified against pascalorg/editor @ main
packages/core/src/services/snap.ts — "Snaps a 3D point to a regular grid in the X/Z plane, preserving Y."packages/core/src/services/movement.ts — movePlanToward packs [x, y, z] and returns [result[0], result[2]].packages/nodes/src/{wall,slab,ceiling}/tool.tsx — new Vector3(point[0], y, point[1]).packages/core/src/schema/nodes/level.ts — level: z.number() (floor base elevation, metres).
(Found while building a site model from a real property report via the MCP server — the plan↔world handedness was the one thing that took real digging to pin down.)
Summary
The MCP package documents units (metres) and per-tool parameters well, but I couldn't find an author-facing statement of the coordinate convention. When generating geometry programmatically (e.g. from a land survey), this is the first thing you need and currently have to reverse-engineer from source.
What's missing
There's no doc stating that:
wall.start/wall.endand thepolygon/holesofslab,zone,ceiling— are[x, z]on the X–Z ground plane, with Y up.new Vector3(point[0], y, point[1]).[x, y, z]tuples.This matters for anyone authoring from a north-up source (a survey with bearings from North, a north-up site plan, most 2-D plotting libraries): because the plan embeds into X–Z, such layouts come in mirrored when viewed top-down, and there's currently no note about it.
examples/generate-apartment.mdonly uses axis-aligned boxes ([0,0] → [10,0]), so the handedness never surfaces in any example.Suggestion
Add a short "Coordinate conventions" section to
packages/mcp/README.md: axes, units, radians, the[x,z] → (x, y, z)mapping, the top-down-mirror caveat for externally-computed coordinates, and one non-axis-aligned example. Happy to open a PR if that's welcome.Verified against
pascalorg/editor@ mainpackages/core/src/services/snap.ts— "Snaps a 3D point to a regular grid in the X/Z plane, preserving Y."packages/core/src/services/movement.ts—movePlanTowardpacks[x, y, z]and returns[result[0], result[2]].packages/nodes/src/{wall,slab,ceiling}/tool.tsx—new Vector3(point[0], y, point[1]).packages/core/src/schema/nodes/level.ts—level: z.number()(floor base elevation, metres).(Found while building a site model from a real property report via the MCP server — the plan↔world handedness was the one thing that took real digging to pin down.)