IFC 的几何是怎么存的

一个反直觉现象

假设你拿到一个 50MB 的 IFC 文件。在 Revit 里双击，几秒就打开了，旋转流畅。同一个文件用浏览器解析渲染，可能要等 30 秒，转一下卡一下。

第一反应可能是"浏览器性能差"或"WebGL 不行"。但真实原因更微妙：IFC 文件里存的根本不是"三角形"，而是"形状的数学描述"，渲染前必须先把它"算成"三角形。这一步计算，就是浏览器卡死的根源。

这节课拆开 IFC 的三种主流几何表示，让你之后看到任何 IFC 解析性能讨论，都能立刻判断瓶颈在哪。整课 7 分钟可读完。

同一面墙，三种存法

IFC 里同一面墙（比如长 4m、厚 0.2m、高 3m 的墙），可以由三种完全不同的方式描述。这三种方式存的数据量、解析难度、渲染友好度截然不同。

SweptSolid —— "配方"，需要"烹饪"

SweptSolid 描述一个 2D 截面 + 一条路径（通常是直线挤出或旋转）。墙、梁、柱、管道这类"沿一个方向延伸"的构件，几乎都用这种方式。

数据上极其紧凑：一个矩形截面定义（4 个点）+ 一个挤出向量（3 个数）就能描述一面墙。这是 IFC 中最常见的表示，也是 web-ifc 等解析库的甜点——计算量小，几行代码就能把截面挤出成三角形网格。

Brep —— "精确图纸"，渲染前要解算

Brep（Boundary Representation，边界表示）用面、边、顶点精确描述实体边界。每个面可以是平面，也可以是复杂曲面（圆柱面、NURBS 曲面）。它追求的是数学上的精确——一个圆柱就是真正的圆柱，不是离散的三角形。

这种精确性是 BIM 设计端的刚需（用于碰撞检测、工程量计算、CAM 加工），但对浏览器是灾难：GPU 只认三角形，所以每个曲面都要先 tessellate（三角化）。复杂曲面（如异形幕墙、自由曲面屋顶）的三角化计算极其昂贵，可能秒级甚至分钟级。这是浏览器渲染 IFC 的主要性能瓶颈。

Tessellation —— "做好的菜"，GPU 直接吃

Tessellation 表示 IFC 已经把曲面离散成了三角形网格，存的是顶点坐标数组 + 三角形索引数组。这正是 GPU 喜欢的格式，几乎零计算直接渲染。

IFC 4 起官方支持 Tessellation 表示，但设计院交付的 IFC 极少主动用这种表示——因为生成时占用文件大、且失去精确性。它更多出现在导出端：当你用 IfcOpenShell 把 IFC 转 glTF 时，本质上就是在做"把 SweptSolid/Brep 统一 tessellate 成三角形"。

第四种 CSG（布尔运算组合基本体）在早期 IFC 中存在，现已罕见，不展开。

一个必须分清的概念：几何 vs 拓扑

IFC 把"形状"拆成两个独立的资源：

• 几何（Geometry）——回答"什么形状"：坐标点、曲面方程、向量。IfcGeometricModelResource
• 拓扑（Topology）——回答"谁连到谁"：这个面由哪几条边围成、这条边共享给哪两个面。IfcTopologicalRepresentationResource

这两者分开存，是 Brep 精确性的根基——同样的几何可以有多种拓扑解释，同样的拓扑可以挂不同几何。但对渲染来说，你最终要把拓扑 + 几何合成一个统一的三角形流，这个合成就是 tessellation 干的事。

渲染管线的真相

无论 IFC 里用的是 SweptSolid 还是 Brep，屏幕上显示的永远是三角形。所以从 IFC 到屏幕，必经这条管线：

这张图揭示了两个关键决策点：

1. tessellate 在哪儿做？在浏览器里现做（卡顿但实时），还是在后端预先做好（一次性成本，浏览时流畅）？
2. 预转产物用什么格式？glTF（单文件，适合单建筑）、3D Tiles（流式切片，适合园区/城市级）？

这两个问题就是下一课的主题。

一个工程级实测数据

开源 BIM viewer xeokit 做过一组 IFC 转换基准测试，结论很硬：

一个 729MB 的 IFC 文件，转成 xeokit 自家的 XKT 格式（本质就是预转 + 压缩的三角形流），结果是 73.95MB——体积压到 1/10，且无需运行时 tessellate，浏览器秒开。
转换参数必须切片：-s 50（每片 glb ≤ 50MB，规避浏览器内存上限）、-t 200（按 200×200×200m 立方体切几何，规避大世界坐标浮点抖动）。

这个数据是业界共识的缩影：大型 BIM 模型在浏览器里直接解析 IFC 是反模式。web-ifc 这类原生解析库只适合中小模型与交互编辑场景，不适合做运营期数字孪生的主视图。