返回 BIM 与 IFC 博客
每个处理整合模型的人都会撞上同一堵墙：建筑 + 结构 + 机电（MEP）合并后的 IFC 有 600 MB 到 1 GB 以上。你一在浏览器里打开它，风扇就开始狂转，内存飙升到 1.7 GB 以上，帧率跌到个位数，最后标签页崩溃。这并不是你操作有误。大型 IFC 文件之所以会拖垮大多数 Web 查看器，有非常具体的原因。
- 1 GB+ — 典型的整合模型
- 1.7 GB — 即使优化后的内存占用
- 3 FPS — 未经优化的模型
- 12× — 开源工具比商业工具慢
大型 IFC 文件为什么会让浏览器崩溃
单线程解析
把 IFC 文本转换成 3D 几何是 CPU 密集型工作，传统上只在一个线程上运行。整个文件必须解析完才能开始渲染，因此解析期间界面会卡住。
内存上限
即使是优化过的模型，也可能占用约 1.7 GB 内存。在 8 GB 内存的笔记本电脑上，浏览器会触及单个标签页的内存上限，渲染进程随之被终止，这就是你看到的“标签页已崩溃”页面。
网格化的开销
IFC 几何通常以参数化实体（拉伸体、扫掠体）定义。为了用 WebGL 显示，需要把它们网格化为三角网格，这会让数据量和计算量成倍增加：每一帧都要推送数百万个三角形。
先全部加载
大多数查看器会预先下载并转换整个文件，尽管你任何时候都只会看其中的一小部分。在全部处理完之前，什么都不会渲染。
为什么开源查看器感觉比商业查看器慢
一个在社区中广为流传的基准测试结果很能说明问题：一个 288 MB 的电气模型，在某款开源工具中加载约需 830 秒，而在一款商业查看器中只需约 67 秒，慢了 12 倍以上。这种差距并不神秘。商业查看器往往通过更直接地表达参数化形体来避免完整的网格化，而且会在你打开模型之前，就先在服务器上把它预处理成适合流式加载的格式。
开源查看器要 830 秒，商业查看器只要 67 秒。这里面的秘诀是什么？
IfcOpenShell GitHub：查看大型整合模型
所谓“秘诀”就是预处理和流式加载，而这恰恰也是问题所在。最快的开源流程（把 IFC 转换为 xeokit 的 XKT 或 glTF）需要技术知识，还需要一台服务器来完成转换。这对产品团队来说没问题，但协调员不可能这样处理一个客户刚通过邮件发来的文件。
真正有效的策略
- 一次转换，多次加载：把 IFC 一次性解析为快速的几何格式（Fragments、XKT 或 glTF/GLB），之后每次打开都加载这个格式。运行时解析 IFC 太慢，不适合反复使用。
- 分块（Tiling）：把模型分割成若干空间块，只加载和绘制相机附近的部分。
- 剔除（Culling）：跳过屏幕外或被遮挡的几何，而不是每一帧都把它推送给 GPU。
- 几何压缩：对重复构件去重（每个相同的螺栓或栏杆柱都引用同一个网格），并对坐标进行量化，以缩小数据量。
- 打开之前先精简文件：只导出你需要的专业，并压缩为 ifcZIP 以便传输。
如何在不借助服务器、不上传的情况下打开大型模型
本查看器使用 WebAssembly 在客户端解析 IFC，并把转换后的几何缓存在浏览器的源私有文件系统（Origin Private File System）中，因此代价高昂的解析只需进行一次，再次加载速度快约 10 倍。无需上传，也不用搭建服务器：你既能获得商业流程“一次转换”的好处，又不必把模型发送到任何地方。在同一视图中整合多个专业模型也是同样的方式：逐个加载即可。
打开一个真实规模的模型
一个由 Revit 导出的完整 IFC4 建筑模型，达到实际生产规模。打开它，看看较大的文件如何在浏览器中加载和缓存，然后再试试你自己的大型整合模型。
IFC4 · 14 MB
打开交互式 IFC 查看器
结论：查看一个 1 GB 的模型，你并不需要 64 GB 内存的工作站，也不需要付费平台。你需要的是一条只解析一次、缓存结果、只绘制你正在看的内容的处理流程，而这在浏览器标签页里就能实现。
为什么大型 IFC 文件会让浏览器崩溃？如何查看 1 GB 的模型
