IFC 几何到浏览器的链路
三条路线，各自的甜点与陷阱——技术选型的核心。
上一课留下的两个问题
上一课那张渲染管线图末尾，留了两个决策点：
- tessellate 在哪儿做？浏览器里现做，还是后端预先做好？
- 预转产物用什么格式？glTF 单文件，还是 3D Tiles 流式切片？
这两个问题的组合，恰好对应业界三条主流路线。这节课把三条路线并排放，让你看到各自的甜点与陷阱。这是后续写 ADR 的核心素材。整课 8 分钟可读完。
三条路线全景
路线 A：浏览器原生解析（web-ifc）
核心组件：web-ifc（C++ 写、编译为 WASM 的 IFC 解析器）+ That Open Engine（其上的 BIM 应用框架）+ Three.js 渲染。
用户上传 IFC，浏览器用 WASM 实时解析 + tessellate，渲染到 Three.js 场景。所有几何计算在浏览器里现做，无需后端预转。
甜点：
- 实时性：上传即看，无转换等待
- 编辑能力：可对 IFC 做增删改（这是预转格式做不到的）
- 架构简单：无需转换服务，无需存储中间格式
陷阱：
- 大模型灾难：数十万构件 + Brep 三角化，浏览器会卡死或 OOM
- 首次加载慢：用户每次打开都要重新 tessellate，没有缓存收益
- 移动端不可用：手机/平板内存撑不住
路线 B：后端预转 glTF（推荐主力）
核心组件：IfcOpenShell（C++/Python，服务端事实标准）做转换 + xeokit 或 Three.js 做浏览渲染。
用户上传 IFC 后，后端用 IfcOpenShell 一次性 tessellate + 导出为 GLB（二进制 glTF）。GLB 作为静态文件存储，浏览器直接加载渲染。
关键命令行：
# 最简转换
IfcConvert input.ifc output.glb
# xeokit 推荐参数（含切片）
IfcConvert input.ifc output.xkt \
--include geometry \
--geometry-slice-size 50 \ # glb 切片 ≤ 50MB
--geometry-tessellated-edges \ # 边线提取（BIM 风格线框）
--cell-size 200 # 按 200m 立方体分块甜点：
- 浏览流畅：GPU 直接吃三角形，秒开
- 全栈开源可控：IfcOpenShell（LGPL）+ xeokit（Apache 2.0），无厂商绑定
- 可缓存复用：转换一次，所有用户共享
- 支持私有化：转换服务可部署在客户机房，满足国内合规
陷阱：
- 需自建转换服务：要部署 IfcOpenShell，处理 RVT 等非 IFC 格式还需额外工具
- 转换耗时不定：复杂模型可能数分钟
- 园区级仍需 3D Tiles：单 glTF 装不下整个园区，需流式切片
路线 C：APS 商业 SaaS（Autodesk）
核心组件：APS Model Derivative API（云端转换）+ APS Viewer（前端渲染）。
上传任意格式（RVT/IFC/DWG/NWD 等 60+ 种），APS 云端转成 SVF2 私有格式，浏览器用 APS Viewer 渲染。
甜点：
- 格式支持最广：唯一原生处理 RVT 的成熟方案（RVT 是闭源格式）
- 开箱即用：无需自建转换管线
- 性能优化成熟：SVF2 已为大模型优化
陷阱：
- 按量计费：Model Derivative 按翻译次数，Viewer 按视图数
- 数据出域：客户模型必须上传 Autodesk 云端，国内政企客户几乎不可接受
- 闭源绑定：SVF2 私有格式，迁移成本高
- Viewer 是黑盒：UI 定制受限
路线 B 的子决策：glTF 还是 3D Tiles？
选了预转路线（B），还要决定预转产物格式。两者不是对立，而是不同尺度的方案：
| 维度 | glTF / GLB | 3D Tiles |
|---|---|---|
| 定位 | 3D 资产传输（"3D 的 JPEG"） | 海量地理空间流式（OGC 标准） |
| 尺度 | 单模型 / 单建筑 | 园区 / 城市 / 国家 |
| 加载方式 | 整体加载 | 层级流式（HLOD，按视锥裁剪） |
| 关系 | 3D Tiles 的叶子瓦片就是 glTF——后者是前者的子集 | |
| 渲染引擎 | Three.js / xeokit 等通用 | CesiumJS（注意：2024-09 已被 Bentley 收购） |
| Pivot 建议 | 起步阶段足够 | 园区/城市级再引入 |
建议：先 glTF，后 3D Tiles。Pivot 起步阶段（单栋/单园区建筑），glTF 完全够用。3D Tiles 的复杂度（CesiumJS 学习曲线 + Bentley 收购带来的合规变数）只有在跨园区、城市级场景才值得引入。
三条路线对应三种客户画像。本课给你一个分层建议：
1. 主力路线 = B（后端预转 glTF + xeokit/Three.js）。开源全栈、可私有化、性能可控——契合 Pivot 多租户 SaaS + 国内合规需求。这是 ADR 的默认推荐。
2. A（web-ifc 原生）作为补充，用于"模型预览""编辑交互"等中小模型场景。比如客户上传 IFC 后给个快速预览，再决定要不要正式入库转换。
3. C（APS）几乎排除。除非某客户深度绑定 Revit 且明确接受数据出域，否则不要走商业路线——多租户 SaaS 用 APS 的边际成本和数据治理风险都不划算。
这个三层结构是后续 ADR 的骨架。第五课会展开成完整的候选方案对比表。