河北BIM公司谈BIM模型量化

轻量化是已经是BIM业界人所共知的一个概念，虽然至今没有任何严谨的学术或者理论定义，但是这个概念已经几乎成为了行业的标准。它的大意是说，一个适用用于浏览器端渲染的模型数据，包括几何数据和行业数据，必然可以做的很小，如果和原建模软件的原始模型文件比较的话，如果做到1/4那是及格标准，做到1/10，乃至1/20之一是。今天我们将讨论下这个概念下具体的技术实现方案和背后的计算机图形学理论，并且希望得出一个对整个行业有参考价值的结论。
纵观现在国内几十种BIM的产品，以及结合我们对近30年计算机图形理论的资料挖掘，我们认为轻量化并不是一个准确的定义，的轻量化在无论产品的数据流上还是在理论基础上都没有太多可实现性。我们同时认为，轻量化这个概念应该更正为文件压缩，并且于现在的通用文件压缩连接起来，毕竟在实质上，它们是完全相同的。
本文会先对从技术理论出发，介绍可以支撑实现“轻量化”的四个图形学技术方向，并且在实际应用过程中产生的工程问题，后会给出一个综合的轻量化实现框架，以及给出理论上上轻量化可以做到小压缩比。
定义
在讨论轻量化的可行技术方案之前，我们需要对轻量化进行一个定义和概念厘清。本文所探讨的轻量化，指对三维建筑模型模型，例如Revit，IFC等文件中三维几何数据部分的数据压缩。本文针对的轻量化不涉及任何其他非三维几何数据，包括纹理图片、材质信息、建筑BIM信息、二维图形信息以及软件特有的附加信息。很多平台产品将自己的纯三维几何数据大小和带有众多信息的原模型大小相对比，得出自己轻量化程度高的结论是非常不科学的。
我们需要对三维几何信息进行进一步定义。这里的三维信息特指三维三角形网格(triangular mesh)或者三维线网格(polyline mesh)。每一个mesh由一个顶点数组和一个索引数组组成。顶点数组中每一个顶点一定包含position，即三个32bit IEEE754 floating number，分别对应顶点的x, y, z坐标，可能包含normal，即三个32bit IEEE754 floating number，可能包含纹理坐标UV，即两个32bit IEEE754 floating number，可能包含顶点颜色，即四个8bit byte，分别对应RGBA四个通道。针对三角形网格，因为考虑渲染效率，一定采用顶点法线(vertex normal)，而不是面法线（face normal)。索引数组为一个unsigned int 16的数组，元素个数为3 * 三角形数量或者2 * 线段数量。
除了定义mesh，我们进一步定义轻量化的应用场景。轻量化仅指进轻量化程序处理后用于保存和网络传输的数据量可以压缩到比原始三维网格的数据量小。在进行渲染前，轻量化的数据可能会解压缩以便是适配于GPU渲染API的需要，解压缩的数据量可能会增大，甚至比原先的三维网格数量量更大，这是为了渲染效率优化的考虑。本文所讨论的轻量化仅针对优化存储优化和传输优化，并不针对渲染的优化。同时，我们认为因为渲染的API的接口规范已给定，渲染时实现还原度的无损数据压缩是不存在的，虽然本文后对这类应用情况也提出了一种可行性方案。
技术方向
轻量化的技术方向大致可以分为Instancing，Compression，LOD和Parameterization。下文对四个技术方向以及其落地分别进行探讨。
Instancing
Instance，多实例是已经非常普遍的渲染技术[2]。它的原理是针对同样的几何物体，只保存一份几何数据，通过在渲染管线中分别绘制若干次，且每次应用不同的几何变化和材质信息得到在同一帧多个类似几何物体的渲染效果。用实际的例子说，如果要绘制很多相同的桌子，我们只需要使用一份桌子的几何数据，然后绘制多编，每一遍把桌子放在不同的位置即可。目前的渲染管线已经完全将instancing放在了硬件管线中执行，大大节约了GPU内存的开销和CPU的计算开销（主要指发起一个drawcall的驱动使用CPU资源）[1, 3]。WebGL 1.0中可以通过使用ANGLE_instance_arrays[3]就扩展实现这个功能，在WebGL 2.0中已经有原生API支持，即gl.drawElementsInstanced。
对应轻量化的Instancing表达，已经有一定的研究[4,5]。研究的主要解决问题，如何在一个场景中，对几何体进行一一对比，如果两个几何体是同一个几何体，那么只需要实际保存一份几何数据，将另外一个几何体压缩为一个空间变化和材质信息。判断两个几何体是否相同往往从附加在几何体上的语义出发，例如两个几何体是不是都标记为一张桌子，或者直接从mesh相似度出发。纯几何的算法是非常具有挑战性的，因为单纯的内存比较显然在大多数情况下不适用，只要索引数组略有变化或者一个简单的平移变换，这种比较就失效了。现在业界应用比较多的是Hausdorff距离[6]，即计算两个mesh之间的小欧式距离。这个距离算法一样对简单的旋转无能无力。
另一方面在建筑建模中，我们发现大多数的建模软件已经内置了Instancing的功能。一个物体如果在场景中重复出现多次，在模型文件中它的几何数据只保留了一份，每一个实例压缩为了一个4x4空间变换矩阵。这样的发现告诉我们，在BIM的数据流中想通过instancing来减少几何数据的大小已经不太现实，源文件已经在这个方面做到了更好。
综上所述，在实际的生产环境中，利用Instancing来减少原始文件的尺寸，效果不会太好。
压缩
压缩的概念就很好理解，就是和普通的文件压缩类似。有两种方向，种是几何无关的，例如直接用将模型数据进行gzip压缩后保存，因为浏览器原生支持gzip解压[7]，在传输过程还是gzip压缩数据，而在应用层已经为解压后的模型数据，根据我们经验，针对上文中提及的几何数据，gzip的压缩率在2:1，即能压缩到原始数据一半的大小。二种方向是几何相关的，比如Google的Draco库[8]，Khronos的Open3DGC[9]。Draco的公开资料中并没有提及它的具体算法，但是它的压缩率是惊人的，见图2。对于Open3DGC，它在一定程度上利用了quantization的方法，是一种有损压缩。虽然他们加入了针对几何信息更好的压缩，但是本质上还是一种压缩算法，需要在载入到GPU前将数据解压缩。