目前市面上的 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图形引擎