Make sense(5) 数据库内存储三维模型的思考

1. 三维模型是否需要入库?

三维模型数据在某种程度介乎矢量数据与遥感影像数据之间:

• 既像影像数据,具有整体性意义:往往以整个场景的形式出现
• 又像矢量数据一样可以拆分为若干单个部件(影像则一般不会拆为单个像素)

也就是说,三维模型可以被入库,但不是那么方便,因而并没有类似矢量数据入库这种被广泛使用的存储方式.但根据实际的业务需求不同,可以设计如下几种入库方式.

1.1 模型以文件形式存储,元数据入库

这是最常见且简单的三维数据管理机制,虽然看起来简陋且没有技术含量,但其实满足了大多数使用场景,也没有引入新的问题.

这种机制的使用场景往往有如下的特点:

• 模型与模型之间没有关联,一般都是独立使用
• 模型本身基本不发生修改,没有修改的需求

这种机制更多的抹除了三维模型自身的特征,而是当做一个普通的数据来处理.

1.2 模型以文件形式存储,元数据和空间索引入库

这是第一种机制的优化,将模型的空间索引(如外包三维盒)入库,在复杂度不增加很多的情况下提供了很多新的功能,使模型与模型可以产生逻辑上的关联.不过这种方案依旧是小的修补,没有带来根本上的革命.

1.3 模型完全入库

所谓完全入库,并非将三维模型以二进制的形式整体存储到一个字段中去,而是将场景模型打散为若干部件,每一个部件转换为内部存储结构,存储在一条或多条记录中.

使用完全入库的方法可以给我们带来更多关于使用场景的想象:

• 动态/细粒度的修改/删除/增加模型
• 按需实时获取动态范围的数据
• 可以进行灵活的库内数据计算
• 可以利用数据库的生态,例如并行计算/存储扩展等

想法固然美好,但依然要回归现实:

• 实现上述想法的需要支付的代价是什么?
• 是否能同时实现上述想法?

2. 数据结构设计遇到的问题

我们不讨论具体的技术实现(比如底层使用CGAL),而是需要思考,我们的数据入库后是为了做什么的:

• 用来做各种空间分析,例如光照,投影面积/轨迹/碰撞等分析(简称算)
• 用来最终输出数据准确可浏览的模型(简称看)

这两种需求本身并不冲突,但底层存储的数据结构设计却可能存在冲突.

为看而优化的设计:

• 为了方便浏览与传输,减少数据量,数据应尽可能多的使用引用,旋转矩阵等面向GPU友好的机制.
• 为了数据的准确存储,应兼容更多的常用三维格式,保留尽可能多的原始信息
• 需要设计材质/纹理等引用机制,以减少存储压力,

为算而优化的设计:

• 为了加速计算,数据结构要尽可能的以最终模式存储,避免运算时的动态引用,旋转(类似GLTF格式)
• 空间分析时,材质/纹理/法线/uv等都不参与计算,应尽可能不存储

可见,两种场景对底层数据结构的需求是对立的,算和看难两全,无法用简单的方式覆盖两种使用场景.

3. 问题的核心与解决思路

既然算,看无法同时保证,那就把它们分开处理,因为一般来说,算的东西和看的是不一样的.

例如在BIM场景中,进行碰撞检测分析时,没必要拿精确拟合的圆形管线来计算,它们只会徒增计算量,对最终的结果基本不产生影响,使用近似的多边形柱替代即可完成任务.但我们最终浏览的时候,还是希望尽可能展示光滑的拟合管线.

所以可以制定这样一种策略:

• 三维数据依然以组件级别粒度入库
• 库内数据结构包含两部分(表内孪生):
  1. 经过简化用于计算的纯模型
     • 该模型应该具有以下特点:
       • 使用时不需要经过任何矩阵变换就能直接用
       • 为了减小计算量和存储压力,在业务允许的情况下顶点数尽可能少
       • 可能会有大量重复数据,这就是用空间换时间的代价
     • 该精简模型可由用户自行指定,也可由库内函数自动生成
  2. 包含纹理/材质/uv/法线的原始模型
     • 因为他们不再参与库内计算,因此可以使用引用的方式,减少重复存储,节省空间
     • 或者可以直接使用一种常用格式作为这部分的存储机制(如gltf格式),方便直接兼容更多的三维模型格式
• 抛弃实时动态生成,充分利用上述机制,从实际出发,通过业务优化实现近似的功能:
  • 实时动态生成很诱人,但随着数据量的扩大,计算量也在不断加大,保证实时性的成本太高,而且可能实际使用到的机会不多
    • 无缓存可能是不值得追求的伪圣杯
    • 在三维浏览场景中,真实时动态可能是个伪需求
  • 数据库的计算资源并不不便宜,动态生成不容易缓存,重复计算的压力会比较大
  • 通过业务进行流程优化尽管没有那么高大上,但更加实际

综上,没有银弹,一切到要根据实际使用场景来做选择.