Pascal Editor: a WebGPU 3D building editor you can run locally with npx

What Pascal Editor solves, and who it is aimed at

Pascal Editor is a 3D building editor built with React Three Fiber and WebGPU, and the repository is a Turborepo monorepo that splits the product into reusable packages rather than shipping one application. The split is the point. @pascal-app/core holds node schemas, scene state and registry contracts. @pascal-app/viewer renders. @pascal-app/editor adds tools, panels and selection. @pascal-app/nodes supplies the built-in node definitions and renderers. @pascal-app/cli installs and manages a local runtime.

The audience is therefore not only architects. It is developers who want an architectural scene graph they can extend, and people who want the editor running on their own machine without cloning the repository. The README states that Node.js 22.13 or newer can create a persistent local Pascal installation, and that the CLI keeps projects in ~/.pascal/data/pascal.db. The homepage is https://editor.pascal.app, and the licence is MIT.

The node hierarchy and the flat dictionary that holds it

Nodes are the data primitives. Every node extends BaseNode, which carries an id auto-generated with a type prefix such as wall_abc123, a type discriminator, a parentId, a visible flag, an optional saved camera and optional metadata. The documented hierarchy runs Site, then Building, then Level, and under a Level sit Wall with Item children for doors and windows, Slab, Ceiling with Item children for lights, Roof, Zone, Scan for 3D reference and Guide for 2D reference.

The storage choice is worth pausing on. Nodes live in a flat dictionary, Record<id, Node>, not a nested tree, and parent-child relationships are expressed through parentId and a children array. That makes lookups by id constant time and avoids deep traversal when a system needs one node, at the cost of keeping two representations of the same relationship consistent. The README does not describe a repair path for a node whose parentId and whose parent's children array disagree, which is the failure mode this design invites.

State is held in Zustand stores, one per package. useScene in @pascal-app/core holds nodes, rootNodeIds, dirtyNodes and the createNode, updateNode and deleteNode operations. It is persisted to IndexedDB with undo/redo via Zundo, with a 50-step history, and transient nodes are excluded from persistence. useViewer in @pascal-app/viewer holds the current selection, the level display mode (stacked, exploded or solo) and the camera mode. useEditor in apps/editor holds the active tool, structure layer visibility and panel states.

Renderers, the registry, and how geometry actually updates

The rendering path is a two-step pattern that keeps React out of the hot loop. A renderer component creates a placeholder mesh or group, registers it with the useRegistry hook, and then systems update the geometry from node data. Registration looks like this:

const ref = useRef<Mesh>(null!)
useRegistry(node.id, 'wall', ref)

The registry is a sceneRegistry object with a nodes map from id to Object3D and a byType index holding sets for wall, item, zone and the other types. Systems can therefore reach a Three.js object directly instead of walking the scene graph. SceneRenderer dispatches through NodeRenderer by type into BuildingRenderer, LevelRenderer, WallRenderer, SlabRenderer, ZoneRenderer, ItemRenderer and the rest.

The dirtyNodes set in useScene is the bridge: nodes pending a system update are tracked there, so a system can act on what changed rather than re-evaluating the whole scene. The README does not give the scheduling order in which systems run against dirty nodes, and that ordering matters when one system's output feeds another.

Installing Pascal Editor locally with the CLI

The README gives a single command for a persistent local installation, and it does not require cloning the repository. Node.js 22.13 or newer is stated as the requirement.

npx @pascal-app/cli editor

The README states that this starts the editor and an authenticated MCP service in the background, selects collision-free loopback ports, and keeps projects in ~/.pascal/data/pascal.db. Because the ports are chosen automatically, the URL printed at startup is the one to open; do not assume a fixed port. The README points to https://editor.pascal.app/docs/developers/local-editor for pnpm and Bun commands, project management, MCP setup, updates, storage paths and troubleshooting, so treat that page as the reference for anything beyond the basic launch.

To let an AI host drive the scene, the README says to configure the agent to launch this command:

pascal mcp connect

For a container deployment, the repository ships a Dockerfile and a docker-compose.yml. The compose file pins the mapping to 3000:3000 and explains why in a comment: the /scenes route fetches its own API through a base URL that only NEXT_PUBLIC_APP_URL can override, and Next inlines that at build time, so a remapped host port produces 500s. The compose file also sets PASCAL_DATA_DIR to /data and mounts a named volume there, with the comment that without the volume every saved project is discarded when the container is recreated.

Embedding the viewer in your own React application

The viewer runtime and the built-in node definitions are separate packages. The README gives this install line for the full built-in viewer set plus the optional capture extension:

npm install @pascal-app/core @pascal-app/viewer @pascal-app/editor @pascal-app/nodes
npm install @pascal-app/capture-protocol @pascal-app/capture-viewer

Before mounting the Viewer component, the built-in plugin has to be loaded once. The README shows the call as an awaited import pair:

import { loadPlugin } from '@pascal-app/core'
import { builtinPlugin } from '@pascal-app/nodes'

await loadPlugin(builtinPlugin)

The React example itself lives in packages/viewer/README.md under the usage heading, not in the top-level README. If you skip the plugin load, no built-in node types are registered, and the dispatcher has nothing to render for them. The capture packages are described as an optional transport-neutral extension, so they are not needed for a plain viewer.

Where the package split becomes a constraint

The separation of concerns is clean on paper and demanding in practice. A single scene spans three Zustand stores in three packages, and the README shows both access patterns: the React subscription form through a selector, and the imperative form through useScene.getState() or useViewer.getState() for callbacks and systems. Mixing the two carelessly is easy, because both are always available.

The flat dictionary plus children arrays is a second constraint. Any code that mutates parentId has to maintain the parent's children list, and the README documents no invariant check for that. A third is the build environment. The Dockerfile carries a comment that next build runs under node, that the image's node is a shim re-execing bun, and that Next 16's build crashes it, a segfault on 1.3.14 and a turbopack CommonJS wrapper error on 1.3.0, on both arm64 and amd64. The Dockerfile works around this by installing nodejs from apk. Anyone building their own image on the oven/bun base should expect the same problem.

Finally, the project is described as built with WebGPU. The README does not document a WebGL or canvas fallback, so browser support is a hard gate rather than a degradation path.

How Pascal Editor differs from three.js scene tooling

The nearest comparison is not a CAD product but the general three.js ecosystem, where react-three-fiber gives you a renderer and leaves the scene model to you. Pascal Editor supplies that model: typed nodes with a discriminator, a documented architectural hierarchy, a registry that maps ids to Object3D instances, and a dirty-node set that tells systems what changed. You get undo/redo through Zundo with a 50-step history and IndexedDB persistence for free, and you get an editing layer with tools, panels and direct manipulation in @pascal-app/editor.

The trade is scope. A hand-rolled react-three-fiber app can hold any scene you can describe, including non-architectural ones. Pascal Editor's node types are building types, and the renderers and systems are written for them. If your scene is a product configurator or a data visualisation, the hierarchy is overhead. If your scene is a building with levels, walls, slabs and zones, the hierarchy is the work you would otherwise redo. The IFC importer noted in the v0.9.0 release notes is a signal of which direction the project expects data to arrive from.

Release cadence, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-07-30. The most recent release is v1.0.0-beta.1, dated the same day, which means the newest line is a beta. Before that came v0.9.1 on 2026-06-10 with a preset system, rooms and templates and building manipulation, and v0.9.0 on 2026-05-27 with in-world handles, render modes and an IFC importer. That is a steady sequence of minor releases with feature-sized changes, and the jump to a 1.0 beta suggests the API surface is being settled rather than frozen.

The practical upgrade cost sits in the package boundaries. The published units are @pascal-app/core, @pascal-app/viewer, @pascal-app/editor, @pascal-app/nodes, @pascal-app/cli, @pascal-app/mcp, @pascal-app/capture-protocol and @pascal-app/capture-viewer, and the root package.json carries per-package release scripts such as release:viewer, release:core, release:editor, release:nodes, release:mcp and release:cli that dispatch a GitHub workflow. Packages can therefore move independently, and a version bump in one does not imply the others moved. Pin the versions you depend on rather than tracking a floating range.

The licence is MIT. That permits commercial use and modification, and it comes with no warranty, which is the standard MIT position. This is a description of the licence text, not legal advice; read LICENSE in the repository before relying on it.

Editorial conclusion

Adopt Pascal Editor if you want a scene graph you can extend with your own node types and renderers, or if you want to run the editor locally without cloning the repository. Do not adopt it if you need a general-purpose mesh modeller or a CAD kernel; the node hierarchy is architectural (site, building, level, wall, slab, ceiling, roof, zone) and the geometry systems are built around that. Before committing, verify two things in your own environment: that Node.js 22.13 or newer is available, since the CLI states that requirement, and that the browser you target supports WebGPU, because the README describes the project as built with WebGPU and does not document a fallback renderer.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes