做一个能用的 BIM 引擎，到底要踩多少坑？
目前市面上的 BIM 引擎不少，各家特色鲜明。但要真正做出一个能用的引擎，到底需要做哪些工作？结合我们自研 TinyBIM 引擎的经验，我把它总结为三步。
第一步：先把"看起来"做好
一个引擎，渲染效果必须过关。PBR 材质、环境光遮蔽（AO）、基于图像的照明（IBL）、抗锯齿、高质量阴影——这些都是基本功。
如果直接使用 Three.js、Babylon 这类开源渲染引擎，这些特性开箱即用，上手很快。但自研引擎的话，每个效果都需要花时间去研究和实现。
自研和开源，各有各的好。在 TinyBIM 中，我们选择了最新的WebGPU作为底层图形 API。原因很简单：底层 API 的上限更高，能更精细地控制渲染管线，为后续的大场景优化打下基础。
第二步：解决"加载快"的问题
BIM 引擎和普通渲染引擎最大的区别，在于场景规模。
我们测试过某大型机场的机电模型：原始 Revit 文件约 5GB，构件数量 100 多万个，顶点数超过 10 亿。在 TinyBIM 中，用 RTX 2060 显卡打开，仅需 10 秒左右。
怎么做到的？
第一，数据要小，传输要快。5GB 的原始模型，压缩后约 500MB。这个压缩比不算高——因为是机电模型，复用的几何体较少。如果是建筑结构模型，压缩效果通常会更好。
第二，数据分块，按需下载。打开建筑模型时，如果你只看外观，内部构件大概率不会下载。只有当它们进入视野，才会开始加载——你会看到模型"生长"出来的过程。
pbr
第三步：让"不卡顿"成为常态
这也是我们选择自研而非开源引擎的重要原因。
渲染引擎的优化，必须围绕底层图形 API 来做。内部文档数据与图形渲染数据要保持高度一致，并且充分复用。使用底层API自研，这些都更好实现。
大场景不卡顿，关键在两点：
一是降低数据加载对操作的影响。按需加载时，不能让后台加载卡住用户的交互。这需要精细的异步调度。
二是高效的剔除与合批。100 多万个构件不可能全部渲染，必须只渲染视野内的。剔除后，还要把材质相同的构件合并到同一个 Draw Call。
但构件数量庞大，简单的数组循环都会带来巨大开销。需要各种算法和技巧来优化——而在 WebGPU 中，计算着色器就是顶级解法。直接用 GPU 并行计算，速度提升非常明显。
写在最后
这些坑踩完，TinyBIM 也就成型了。
引擎本身免费使用，转换后的数据可以下载，配合我们提供的 JS SDK 即可私有化部署。
TinyBIM-国内首个基于WebGPU的BIM图形引擎