ArchSight Graphics v1.4.0 发布：工程模型能打开以后，审阅结果还要留得住

8 月 2 日，ArchSight Graphics v1.4.0 正式发布。

7 月的 v1.3.0 解决了一个直观问题：怎样把 BIM / IFC 工程模型放回道路、园区和城市背景中。到了 v1.4.0，我们把注意力转向另一个更难被截图说明的问题：模型进入浏览器以后，能否稳定选中同一个构件，完成审阅，并把结果带到下一次打开。

这不是多加几个按钮。它决定了三维模型停留在演示，还是开始成为可复核的工程工作对象。

从 v1.3 到 v1.4，具体改了什么

四条线最能说明这次升级：

| v1.3.0 已经做到 | v1.4.0 继续补上的部分 | | --- | --- | | BIM 与现场背景进入同一视图 | 本地模型目录和转换后的 3D Tiles 进入真实界面，支持按需加载、失败恢复和长会话释放 | | 图层和配准状态可以保存 | 构件选择、定位、隐藏、隔离、外观覆盖、测量和剖切进入同一审阅链路 | | 模型可以被浏览和操作 | 用稳定的 elementKey 贯通不同精细层级，视角变化后仍能认出同一个工程对象 | | 产品能力主要集中在 Workbench | @archsight/graphics 与加载器以 1.0.0 首次形成独立、可交付的 SDK 版本 |

四条线里，耗时更多的是把“加载成功”之后的工作补完整。

大模型进入浏览器，不等于进入工作流

工程模型轻量化通常先回答速度问题：模型怎样拆分，怎样按需传输，怎样在远近视角之间切换。

但工程审阅还会继续追问：远景中的代理构件和近景中的精确构件，是不是同一个对象？切换精细层级以后，已经选中的构件会不会丢？之前做过的隐藏、着色和批注，是否还能找到原来的对象？

v1.4.0 用稳定的构件身份贯通这些状态。模型可以按视角和预算加载不同层级，审阅记录不再依赖某一块临时网格。对使用者来说，最直接的意义是：镜头远近变化，不应把一次工程判断变成另一件事。

图 1 流式模型在发布验收中保存并重开，测量与选中状态恢复
图 1 流式模型在发布验收中保存并重开，测量与选中状态恢复

本地 IFC 也不再只有“整份读入浏览器”这一条路。模型可以先编译为 .archsight-model，并从同一份结构化结果派生 3D Tiles：前者保留精准 BIM 与语义主线，后者服务远程流式浏览。L0、L1、L2 分别承担远景代理、真实简化和精确回退，浏览器按需要逐步水合，而不是一开始就把全部几何压进内存。

这里的目标不是给出一个脱离模型、设备和网络条件的“快多少”数字，而是让加载、降级、恢复和资源释放都有明确路径。

审阅结果单独保存，不改写源模型

v1.4.0 把常用动作连成了一条可以保存的审阅链：选择与定位构件，查看只读属性，执行隐藏、隔离和外观覆盖，添加测量或剖切，再把这些变化随项目保存。

重新打开项目后，系统根据稳定的构件身份恢复审阅增量。原始 IFC 和发布后的 3D Tiles 仍然是只读主制品，审阅结果单独记录，不把颜色、可见性或批注写回源文件。

图 2 v1.4.0 将构件身份、审阅动作与项目记录连成闭环
图 2 v1.4.0 将构件身份、审阅动作与项目记录连成闭环

这个边界很朴素：源模型回答“原来是什么”，审阅增量回答“这次检查做了什么”。两者分开，结果才容易追溯、撤回和复核。

SDK 1.0.0：从仓库能力变成独立交付

v1.4.0 同期完成了 ArchSight Graphics SDK 的首次正式交付。@archsight/graphics 和 @archsight/graphics-loaders 以 1.0.0 固定公开入口、类型声明和版本边界，通过独立 Release 交付，不发布到公开 npm。

SDK 面向需要把工程模型查看、选择、属性、隔离、测量、剖切和状态输出嵌入自有系统的开发团队。它不包含 Workbench 界面，也不包含 Authoring、几何内核和 Model Compiler。

已部署的 SDK Example 是一套独立的只读示例应用。它集中展示功能场景和对应源码，便于先判断集成方式；示例应用当前版本为 1.1.0，不等同于本次首次交付的 SDK 包版本 1.0.0。

图 3 SDK Example 默认页展示 BIM 与现场背景，并提供功能场景与源码入口
图 3 SDK Example 默认页展示 BIM 与现场背景，并提供功能场景与源码入口

SDK Example 与 Workbench 是两个独立入口，Workbench 当前没有跳转按钮。SDK Example 访问地址：graphics.archsight.cn/sdk/，复制到浏览器即可打开。

我们也用真实公开样例做了字段验证：一份约 17.3 MB 的 IFC 和一份约 10.6 MB 的 CC0 建筑 3D Tiles，均进入独立示例链路。数字只说明本次验证输入，不代表所有模型都能得到相同表现。

“可计算”为什么仍值得单独提出

轻量化引擎解决的是模型怎样更快进入浏览器。我们还希望继续回答：这个对象到底是什么，它的几何是否有效，当前允许执行哪一种操作，结果依据从哪里来。

v1.4.0 已经铺下部分底层基础：受控的 Rust / WASM 几何链能够生成 BRep 与 Mesh；构件有稳定身份；几何和审阅结果能够保留来源关系。这些能力让系统不只剩下一张渲染网格。

但它们还不等于“已经可以做工程计算”。当前正在补的是计算资格与证据层：同一个对象用于显示、距离测量、面积体积、布尔运算或图纸投影时，资格并不相同；系统需要明确给出 verified、approximate 或 blocked，并说明原因。几何回退可以保证对象仍然可见，却不能冒充精确计算结果。

图 4 从模型可见到可计算，中间还需要资格与证据层
图 4 从模型可见到可计算，中间还需要资格与证据层

专业结构分析、能耗分析和工程量计算还需要各自的分析模型、荷载、材料、边界条件与规范合同，不能由一份可显示的三维网格自动推出。计算资格系统属于 v1.4.0 发布后的研发方向，不是本版本已经交付的公开功能；SDK 1.0.0 也不包含这套几何内核和模型编译链。

这恰好是 ArchSight Graphics 与普通轻量化浏览器想要拉开的距离：不急着把“能显示”改写成“能计算”，先让每一步判断有资格、有证据、有边界。

现在可以验证什么

使用者可以从几项具体工作开始：

  1. 在 Workbench 中选择本地模型目录或转换后的 3D Tiles，观察加载、视角切换和失败恢复。
  2. 选择构件后执行定位、隐藏、隔离、外观覆盖、测量和剖切，检查不同精细层级下对象身份是否连续。
  3. 保存并重新打开项目，确认审阅记录能否恢复，同时核对源模型没有被改写。
  4. 在 SDK Example 中查看场景与源码，判断公开 API 是否适合嵌入现有系统。

在官网搜索 ArchSight Graphics 可以进入 Workbench；SDK Example 请使用上面的独立地址。正式项目测试仍建议从一份许可清晰、范围可控的模型开始，记录格式、体量、构件数、设备和失败现象，再决定是否扩大验证。

当前边界

v1.4.0 不是多人协同审阅平台，也不编辑源 IFC 几何，不把审阅属性写回 3D Tiles。SDK 首版不是 Workbench 的完整拆包，不包含 Authoring、模型编译和通用工程计算。

本地目录、流式发布和浏览器缓存各有责任：.archsight-model 是精准 BIM 主制品，3D Tiles 是可选的远程流式派生，浏览器存储只是缓存。任何损坏、校验失败或协议不兼容，都应退回上一份可用制品或重新选择来源，不能把失败目录继续当作可信输入。

从 v1.3.0 的“模型回到现场”，到 v1.4.0 的“审阅结果留得住”，ArchSight Graphics 正在补的是工程三维最容易被演示跳过的部分。下一步走向计算，也会沿用同一个原则：能显示的先如实显示，能验证的给出证据，不能进入计算的明确阻断。

关注我们

欢迎搜索并关注 筑见实验室，获取更多建筑 AI、结构计算与工程数字化实践：