The Problem
Building 3D building models from scratch is complex. Most tools require low-level graphics programming or force users into rigid, pre-built structures. Teams need a way to define a building's geometry—walls, slabs, roofs, zones—and edit it interactively without writing custom Three.js code for every feature.
What This Does
editor is a 3D building editor built with React Three Fiber and WebGPU. The core architecture is a data-driven scene graph: building elements are plain TypeScript objects (BaseNode with id, type, parentId) stored in a flat Zustand store (useScene), not a nested tree. A "Scene Registry" maps node IDs to Three.js objects for fast lookup, and "renderers" are React components that subscribe to node data and render the corresponding 3D meshes.
The repo is a Turborepo monorepo. The apps/editor package is the Next.js application (UI, tools, editor-specific state). The README describes packages/core (schemas, state, systems) and packages/viewer (rendering), but those directories are not present in the file listing—only apps/editor exists here. The editor ships with a large asset library: 100+ furniture .glb models, icons, and audio files for UI feedback (snap, place, delete).
How To Use It
Setup: The repo has apps/editor/package.json and a root .npmrc, but no lockfile. This is a pnpm-style monorepo (implied by .npmrc and the Turborepo README), but there is no pnpm-workspace.yaml or root package.json in the file listing. The workspace is incompletely committed.
Configuration: apps/editor/.env.example exists. The only environment file is .env.example at the repo root. There is no env.mjs in the root, but apps/editor/env.mjs exists. Actual variable names are not documented in the README.
Running it: The README does not provide commands. From the apps/editor/package.json and next.config.ts, the standard Next.js dev flow applies, but you will need to restore the missing packages first:
Missing: pnpm-workspace.yaml, root package.json, lockfile
After restoring the monorepo structure: cd apps/editor pnpm install pnpm dev
Real-World Use
An architect imports a 2D floor plan, then uses the editor to build walls, place doors and windows, and assign zones. The useScene store persists to IndexedDB with undo/redo (via Zundo middleware). A collaborator opens the same project, and the editor's dirtyNodes set triggers system updates only for changed geometry—not a full re-render. The useEditor store tracks the active tool (e.g., wall, select, pan), and the useViewer store controls camera and level display mode (stacked/exploded).
Code Health & Issues
High - Missing core packages: The README documents packages/core and packages/viewer, but the file listing shows only apps/editor. The repo will not build as committed. High - No lockfile: apps/editor/package.json exists without a lockfile. Builds are non-reproducible. Med - No tests: No test files detected. The editor has complex state logic (Zustand stores, undo/redo, scene registry) with no automated coverage. Med - Tool-specific rules duplication: .claude/rules/ and .cursor/rules/ contain identical rule files (systems.md, events.md, etc.), doubling maintenance. Low - Privacy/Terms pages: apps/editor/app/privacy/page.tsx and terms/page.tsx exist, but no cookie or consent mechanism is visible in the file list.
The Bottom Line
The architectural design is sound—a flat node store with a scene registry is a solid pattern for an editor. The asset library is substantial. However, the repo is incomplete (missing packages, no lockfile, no tests), so it is not runnable in its current state. This is worth watching if the full monorepo is published; as-is, it is a preview of the architecture rather than a usable tool.