Pascal Editor: A WebGPU Building Editor Built on React Three Fiber and MCP

A Node-Based Approach to 3D Architecture

Pascal Editor solves a specific problem: how to build a 3D architectural editor that is both data-driven and extensible. Instead of storing a nested scene graph, it uses a flat dictionary of nodes. Each node has an id, a type, a parentId, and metadata. The hierarchy is defined by parent-child references, not by object nesting. This design makes it easy to query, update, and persist scene state. The documentation shows a clear hierarchy: Site, Building, Level, then Wall, Slab, Ceiling, Roof, Zone, Scan, and Guide. This is for developers who want to embed a 3D editor into their own applications, or who want to build custom tools on top of a structured scene model. The MCP (Model Context Protocol) integration is a notable feature: it exposes scene tools and resources to AI hosts, which could enable natural-language-driven editing. This is not a typical end-user tool; it is a developer platform.

The Viewer-Editor Separation and Package Architecture

The repository is a Turborepo monorepo with clear separation of concerns. The core package handles schemas, scene state, and registry contracts. The viewer package handles 3D rendering via React Three Fiber, including default camera and post-processing. The editor package adds interactive tools, selection, and direct manipulation. This separation means you can use the viewer alone to render a scene, or add the editor for editing capabilities. The built-in node definitions live in a separate package, @pascal-app/nodes, which registers a plugin. This plugin architecture allows you to load only the node types you need. The CLI package installs and manages a standalone editor runtime, which is useful for local development. The MCP package exposes scene tools to AI hosts, which is a unique feature. This modularity is a strength: you can pick and choose packages, and the dependencies are explicit. However, it also means a steeper learning curve, as you need to understand how the packages interact.

Getting Started: CLI and Published Packages

The README provides two ways to run Pascal Editor. You can use the CLI without cloning the repository: run `npx @pascal-app/cli editor`. This starts the editor and an authenticated MCP service in the background, picks collision-free loopback ports, and keeps projects in `~/.pascal/data/pascal.db`. This is a quick way to try the editor locally. Alternatively, you can install the published packages: `npm install @pascal-app/core @pascal-app/viewer @pascal-app/editor @pascal-app/nodes`. Then you must load the built-in plugin once before mounting the viewer: `import { loadPlugin } from '@pascal-app/core'; import { builtinPlugin } from '@pascal-app/nodes'; await loadPlugin(builtinPlugin)`. This is a critical step; forgetting it means the viewer will not know how to render nodes. The README also mentions optional capture packages for sessions, but those are transport-neutral extensions. The CLI approach is simpler for evaluation, while the package approach is for embedding.

Scene State and Undo/Redo with Zundo

Scene state is managed by a Zustand store in @pascal-app/core. The store holds a flat dictionary of nodes, root node IDs, and a set of dirty nodes. The store provides CRUD operations: createNode, updateNode, deleteNode. Two middleware are used: Persist, which saves to IndexedDB, and Temporal (Zundo), which provides undo/redo with a 50-step history. This is a concrete mechanism: every change is recorded, and you can step back up to 50 operations. The documentation shows how to access state outside React using `useScene.getState().nodes[id]`, which is useful for systems and callbacks. This design is clean, but the 50-step limit might be too small for complex editing sessions. Also, IndexedDB persistence means data is stored in the browser, which could be a limitation for multi-user collaboration. There is no mention of server-side sync or conflict resolution.

Renderers and the Scene Registry

Renderers are React components that create Three.js objects for each node type. The pattern is: create a placeholder mesh or group, register it with the scene registry using the `useRegistry` hook, and then systems update geometry based on node data. The registry maps node IDs to Three.js objects, and also maintains sets of IDs by type, such as wall, item, zone. This allows systems to access 3D objects directly without traversing the scene graph, which is efficient. For example, a system can get all wall IDs and update their geometry. This is a solid architecture for performance, but it places a burden on developers to ensure that renderers correctly register and unregister nodes. The documentation shows a `SceneRenderer` that dispatches by type, with sub-renderers for each node type. This is a clear pattern, but it means adding a new node type requires writing a new renderer and registering it with the plugin.

Limitations and Trade-offs

Pascal Editor is in beta, with the latest release being v1.0.0-beta.1. That means the API may change. The README does not document any migration path between versions, so upgrading could be painful. The editor relies on WebGPU, which is not supported in all browsers. If your target users use Safari or older Chrome, they may not be able to run the editor. The MCP integration is interesting, but it also introduces a security surface: the CLI starts an authenticated MCP service, and you need to manage authentication. The documentation does not explain how authentication works or how to secure it. Another limitation is the flat dictionary storage: while it is efficient, it can make complex queries harder. The registry is a workaround, but it is an in-memory structure that must be kept in sync with the node dictionary. If they get out of sync, you will have rendering bugs.

Alternatives and Maintenance Considerations

A real alternative is to use a general-purpose 3D engine like Three.js directly, with your own scene graph and editor logic. That approach gives you full control but requires building everything from scratch. Another alternative is to use an existing BIM tool like IFC.js, which focuses on IFC file parsing and visualization. The difference is that IFC.js is oriented toward importing and displaying IFC files, while Pascal Editor has its own node schema and editing tools. If your project requires IFC interoperability, you might need to build a bridge, as Pascal Editor has an IFC importer mentioned in the v0.9.0 release notes, but the README does not detail its capabilities. For maintenance, the project is MIT licensed, which is permissive. The monorepo structure with Turborepo suggests a commitment to code organization, but the beta status means you should expect breaking changes. The last push was in July 2026, which is recent, so the project is actively maintained.

Who Should Use Pascal Editor

Pascal Editor is for developers who want to build a custom 3D architectural application without starting from zero. It is not for end users who want a finished product. The separation of viewer and editor packages means you can use only the viewer to render scenes, which is useful for visualization-only applications. The MCP integration is a differentiator: if you are building an AI assistant that can manipulate 3D scenes, this editor provides a ready-made interface. However, you should verify that the MCP service works in your environment, and that the authentication model meets your security requirements. The project is young, so you should be prepared to contribute fixes or wait for community support. Before adopting, test the CLI locally, check WebGPU support in your target browsers, and review the node schema to see if it covers your building types. If you need IFC import, test that feature specifically, as it is not documented in the README.

Editorial conclusion

Adopt Pascal Editor if you need a programmable, WebGPU-based 3D building editor where scene data is a flat dictionary of typed nodes, and you want to integrate with AI agents via MCP. Do not adopt it if you require a production-ready, feature-complete BIM tool: it is in beta, relies on WebGPU availability, and lacks documented migration paths. Verify first that your target browsers support WebGPU, that the IndexedDB persistence with Zundo undo/redo meets your data-integrity needs, and that the MCP service's loopback port selection works in your deployment environment. The project's separation of viewer and editor packages is a solid foundation, but its future depends on the pace of beta releases and community adoption.

Official sources

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