这个开源 3D 建筑编辑器，把最容易失控的几层东西拆开了

wsleepybear
对比与选型
11天前
104热度
0评论

大多数浏览器 3D 项目，难点不是“画出来”，而是后面越做越乱。 pascalorg/editor 值得看的地方，是它已经把数据、渲染和编辑器交互拆开了。所以它不像一个会动的 demo，更像一套真的能继续长的空间编辑器底座。

仓库地址放前面：https://github.com/pascalorg/editor

项目卡片

项目名：Pascal Editor
GitHub：https://github.com/pascalorg/editor
增长信号：主仓库公开信息显示约 5.1k Star，最近发布到 v0.3.0
一句话判断：这项目最值钱的地方，不是效果有多炫，而是它已经有了“继续加功能也不容易炸”的骨架。

图注：仓库 README 自带演示视频入口，能直观看到它不是静态场景浏览，而是面向编辑动作的 3D 空间工具。

它为什么值得看？

这个仓库是一个 Turborepo monorepo，主干拆成三层：

@pascal-app/core：节点 schema、场景状态、几何 system、空间查询、事件总线
@pascal-app/viewer：React Three Fiber 渲染、默认相机/控制、显示模式
apps/editor：真正的编辑器 UI、工具、面板、编辑行为

这层拆法很关键。

很多团队做 3D 编辑器，最后都会把“看场景”和“改场景”写成一锅。功能加得越多，状态越乱，后面每次改动都容易牵一大片。

Pascal Editor 比较难得的地方，是它一开始就在认真处理这个问题：先定义场景是什么，再定义怎么显示，最后再加怎么编辑。

这意味着你理论上可以只复用 core + viewer 去做只读场景，也可以在上面继续长出不同的编辑器交互层。这个思路本身，就比“先把功能堆出来再说”更值钱。

第一层：它的数据建模，明显是按编辑器思路来的

仓库把整个 3D 场景抽象成一组 Node。

从 Site → Building → Level → Wall / Slab / Ceiling / Roof / Zone / Scan / Guide，本质上都是节点。每个节点都继承基础结构，带有 id、type、parentId、visible 这些属性。

真正关键的是，它没有把场景存成深层嵌套树，而是放进一个扁平字典里，再通过 parentId 和 children 维持关系。

这个设计对编辑器特别友好：

CRUD 更直接
撤销 / 重做更容易接
dirty node 增量更新更顺
渲染层不用跟着业务层一起套娃

看 packages/core/src/store/use-scene.ts，场景 store 的核心状态其实很直接：

tscode

useScene.getState() = {
  nodes: Record<AnyNodeId, AnyNode>,
  rootNodeIds: AnyNodeId[],
  dirtyNodes: Set<AnyNodeId>,
  createNode(),
  updateNode(),
  deleteNode(),
}

而且它不只是存当前状态，还加了两层很编辑器化的能力：把场景持久化到 IndexedDB，以及通过 Zundo 保留 50 步 undo/redo 历史。

看到这里，我基本就知道它不是那种“看起来很像产品，实则还停在演示层”的项目了。

图注：这张配图对应文章里最关键的一点：场景不是一棵越长越深的 UI 树，而是一套可以被编辑器系统持续操作的节点模型。

第二层：React 管结构，System 管重算

Pascal Editor 另一个很对的判断，是它没把几何更新硬塞进 React 组件。

它的做法是：

Renderer 先创建占位 mesh / group
用 useRegistry 把对象注册进 scene registry
节点变化后标记为 dirty
各类 system 再在 useFrame 里只处理 dirty node，重算几何或位置

README 里明确列了几类核心 system：

WallSystem：墙体几何、转角 miter、门窗开洞
SlabSystem：楼板多边形几何
CeilingSystem：天花板几何
RoofSystem：屋顶几何
ItemSystem：挂件、家具、灯具等对象定位
LevelSystem：楼层显示模式和垂直位置

如果你做过 React + Three 的复杂交互，就会知道这条线值钱在哪：React 适合声明结构，不适合背所有实时几何计算。

一旦墙体、开洞、层级显示、碰撞校验都混进组件层，项目后面很容易越来越慢，也越来越难维护。Pascal Editor 至少把这条边界立住了。

图注：这里真正值钱的不是“有渲染”，而是只重算 dirty node，把 React 声明式结构和几何系统更新拆开。

第三层：它没有用一个大 store 硬扛全部状态

这个仓库用了三套 Zustand store 来分担职责：

useScene：场景数据本身
useViewer：查看状态，比如当前层级选择、楼层模式、相机模式、单位制
useEditor：编辑器状态，比如 phase、mode、当前 tool、floorplan 面板开关

这不是小题大做，反而是很实用的工程判断。

因为 3D 编辑器里最怕的不是状态多，而是状态边界不清。你很难分清某次改动到底是在改“场景数据”、还是“视图状态”、还是“编辑器 UI 状态”。

Pascal Editor 的拆法至少让这三种东西各归各位了。

图注：示意它的核心分层：core 管节点和几何系统，viewer 管显示与相机，editor 管工具和交互。

v0.3.0 这一版，真正重要的是什么？

如果只看 README，你会以为它主要在讲 3D 建筑编辑器架构。但仓库最近的 v0.3.0 更新，其实把它往更完整的编辑器体验又推了一步。

从 tag v0.3.0 的提交说明里，能看到几个重点：

新增了 2D floorplan panel
支持墙体测量、单位切换
重做了 command palette
增强了 wall drafting、polygon editing、roof segment 编辑
viewer store 里也加了 metric / imperial 单位状态

但真正重要的，不是它又多了几个面板。而是作者开始正面处理一件现实的事：

空间产品可以用 3D 来理解，但高频编辑往往还是要落回 2D。

这也是我对它改观最大的一点。

很多空间编辑器都爱强调 3D 视图本身，但真正进入高频编辑阶段，用户还是会更依赖平面。Pascal Editor 这一版至少说明，它已经不满足于“在 3D 里做编辑”，而是在往更完整的工作流走。

图注：比起继续堆 3D 特效，2D floorplan 面板这类能力更像“编辑器开始走向真实工作流”的信号。

如果你想抄它的思路，先看这 3 处

1. `packages/core/src/store/use-scene.ts`

先看场景数据怎么存，dirty node 怎么管理，persist 和 undo/redo 怎么挂进去。

2. `packages/viewer/src/store/use-viewer.ts`

看 viewer 状态如何与数据层分离，尤其是 selection、level mode、unit 这种典型“不是业务数据，但又很关键”的状态。

3. `packages/editor/src/store/use-editor.tsx`

看编辑器如何把 phase、mode、tool 拆开，而不是靠一个 currentTool 变量硬撑全场。

如果你自己也在做 Web 端重交互 3D 产品，这三处比单看 UI 效果更有参考价值。

最后怎么判断这个项目？

我一开始其实也以为，这又是一个“React Three Fiber 做了个建筑编辑 demo”的仓库。

但顺着 README、store 和最近 release 看下来，我会改口：它已经明显在往一套真正的 Web 空间编辑器系统走，而不是停在“能编辑几个墙体”的阶段。

它当然还不是一个已经打磨完成的成品编辑器。但如果你想看“浏览器里的 3D 编辑器怎么从 demo 长成系统”，这个仓库已经很值得研究了。

至少它踩对了方向：

场景先建模，再谈交互
viewer 和 editor 分层
React 管结构，system 管重算
状态按职责拆开
2D 与 3D 并存，而不是互相替代

这几个判断，比单纯把画面做炫更难，也更值钱。

如果这篇对你有用，建议点个关注。我会持续把 GitHub 上值得用的 AI 工具拆成「最短上手闭环 + 坑点清单 + 可复用配置」，让你少走弯路。

关注微信公众号

想第一时间看到后续的工具拆解与实战更新，欢迎扫码关注公众号。