Project North direction: data-model property + viewport compass
Problem or motivation
Pascal has no first-class North in its data model. The word "north" appears only as informal English in template comments, and the two templates that use it don't even agree:
packages/mcp/src/templates/two-bedroom.ts:14— "zrunning north/south (positive z points south)"packages/mcp/src/templates/garden-house.ts:14— "back garden zone immediately to the north of the house" (without specifying which axis)
There's no northDirection, northDeg, compass, or any other
orientation primitive anywhere in the schema. So:
- Templates that try to use north pick their own convention silently.
- Authors generating geometry from a real-world source (a land survey with bearings from North, a north-up site plan, a 2-D plotting library) have nothing to anchor their input against. The external-coordinate gotcha documented in #337 / #356 is partly because there's no canonical North to map page-up coordinates onto — the README has to tell authors to verify with a guide image.
- Users have no on-screen indication of which direction is north when inspecting a scene. The 2-D plan panel applies a 90° rotation and the 3-D top-down snap defaults to a ~45° offset (also documented in #337), so "north on the page" doesn't map intuitively to anything.
This is what surfaced #337 in the first place — building geometry programmatically from a surveyor's report (every wall a bearing from True North) means chasing the rotation manually, because the editor has nothing to anchor it against.
Proposed solution
A tiered approach so the maintainer can pick a starting point. Tier 1 on its own would close the gap meaningfully; Tier 2 makes it complete.
Tier 1 — minimum viable (a property, a widget, a default)
- Add
northDirection: number(radians, CCW from world+Xto match Pascal's existing rotation conventions) toSiteorBuilding. Default to whatever the current templates implicitly assume so existing scenes don't move. - Render a small north-arrow widget in viewport corners (or near the
existing camera-mode button in
apps/editor/components/viewer-toolbar.tsx), rotating with the camera so it always points to true north on screen. - Clean up the conflicting template comments while in the area.
Tier 2 — high-leverage follow-ups
- "Rotate to north-up" view command — orbits the 3-D top-down camera so
north faces screen-up, and adjusts
FLOORPLAN_VIEW_ROTATION_DEG/ the floor-plan SVG group rotation so 2-D plan view does the same. - Surface
northDirectionover MCP (settable viaapply_patch/ readable fromget_scene). Agents authoring from a survey can drop the value in once and have everything else line up — closes the loop the README PR opens.
Tier 3 — explicitly out of scope for v1, mentioned so it doesn't get baked into the wrong place
- Revit-style True North vs Project North separation (Project
North = aligned to a building facade for drawing clarity, True North
= the cardinal). Worth considering if Pascal ever wants sun-studies
- multi-building campuses, but not necessary for the immediate gap.
- Sun / shadow studies tied to
northDirection+ lat/long + date/time.
Alternatives considered
- Document the gap only (what PR #356 does). Helpful but doesn't solve the underlying issue: even after reading the docs an author still has to verify orientation against a guide image every time.
- Per-template / per-author conventions (status quo). Already visibly broken — the two-bedroom template says +Z is south and the garden-house template says the garden is to the north without saying which axis.
- Skip the data-model change; add only a UI compass that points to world +Z (or +X) regardless. Tempting but doesn't help anyone authoring from a real-world bearings source; it just relabels the existing world axes.
Additional context
Every comparable tool has this:
| Tool | What they do |
|---|---|
| Revit | Distinct True North vs Project North; sun/shadow studies, energy modelling key off it |
| ArchiCAD | Project north in Project Preferences |
| SketchUp | Solar North toolbar with a settable north angle |
| Vectorworks | Plan rotation to true north as a project setting |
| Civil 3D / AutoCAD | North angle on the drawing; standard in civil/site work |
| Floorplanner / Roomstyler / similar SaaS | Rotatable north-arrow widget |
| QGIS / ArcGIS / any GIS layout | North arrow as a first-class layout primitive |
So Pascal not exposing this is the unusual position rather than the ask being unusual.
Open questions
SiteorBuilding? Site is the outermost container and multiple buildings could share a site's north. Building already has arotation: [x,y,z], so Building.rotation[1] is roughly "this building's facade angle relative to site axes". Storing north on Site keeps these orthogonal; storing on Building lets each building have its own. My instinct says Site, but you may have a reason to put it on Building.- Default value? Defaulting to "true north = +Z" matches the
two-bedroom.tstemplate's stated convention ("+Z = south" inverted) and is the most common assumption in north-up site plans. Worth defaulting explicitly rather than leaving it implicit as today. - Widget UI? A separate corner widget is the obvious choice, but
could also be a small N marker on the existing camera-mode button,
or a compass overlay near the orthographic-camera toggle in
viewer-toolbar.tsx:438. Likely a design call.
Happy to take a stab at Tier 1 if there's interest; want to confirm the schema placement and widget direction first.
Related: #337, #356.
Source: pascalorg/editor