对比分析OSG与Cesium中模型LOD的异同

1. LOD

熟悉渲染的读者可能经常听到LOD(Level Of Detail)，也就是用不同的细节层次来表达同一个对象。比如下图中的雕像，从左到右精细度越来越低，最后甚至仅剩一个轮廓，已经看不出人形。那可能有人会问：为什们要用这么多不同精细度的模型来表达同一个对象呢？归根到底，还是计算机算力不足导致的。

一个复杂的三维场景可能由很多对象组成，如果每个对象都用精细模型渲染，就会增加计算机的渲染负担，难以保证流畅的帧率。为了尽量保持渲染质量不变，图形学研究者提出LOD的概念，即根据物体与观测相机的距离，动态选择不同精细度的模型进行渲染。这也就是说，如果一个物体离我们很远，就可以用很粗糙的模型表示，反正距离很远的时候也看不到细节；当我们逐渐接近这个物体，就调用精细度更高的模型渲染；而当我们重新远离这个物体，计算机渲染的模型精细度也会越来越低。

LOD的出现确实在一定程度上提高场景的渲染效率，而付出的代价就是数据量的增加。毕竟除了最原始的模型，还要在其之上生成多个粗糙的模型。那这些粗糙的模型是怎么来的呢？答案是网格简化。关于网格简化有很多算法，在此不做深入探讨。

2. LOD与PageLOD

作者第一次见到PageLOD是在 OpenSceneGraph库里，甚至很怀疑这个概念是不是OSG开发者提出的。那么PageLOD与LOD有什么区别呢？上面说了，LOD会从一个精细模型生成多个不同细节层次的粗糙模型。那么这些不同细节层次的模型怎么存储呢？一般是存储在同一个文件中，由三维引擎在渲染开始的时候加载到内存中，根据物体与相机距离动态调度，渲染过程中只有一次文件IO。

如果有一份非常大的模型数据，大到计算机内存装不下，这时候就不能把这些不同精细度的模型存储在一个文件中。为了解决这个问题，PageLOD出现了。在PageLOD中，不同细节层次的模型是分成多个文件存储的，在渲染过程中，三维引擎同样会根据物体与相机的距离动态调度，区别在于每次加载新的模型，不再是直接从内存中读取，而是先从文件系统加载到内存，然后再进行渲染。

PageLOD使得渲染过程的IO增加了，因而，如果模型文件较小的情况下用PageLOD必然会导致渲染帧率的下降。而在模型文件比较大的情况下，为了保证能够成功渲染模型，PageLOD可以说是目前唯一的选择。

3. HLOD与PageLOD

正如前面说的，一个三维场景中可能有成千上万个对象，渲染的时候怎么确定每个对象用什么精细度的模型呢? HLOD (Hierarchical LOD)解决的就是多个模型的LOD渲染问题。HLOD顾名思义就是分层LOD，其实和GIS专业里影像金字塔原理一样，越上层的模型越粗糙，越下层就越精细。

那怎么构建这种层级关系呢？想一想数据结构课里是不是学过一些分层的数据结构？没错，就是树。在HLOD中常用的树包括四叉树、八叉树和R树。一般2维和2.5维数据用四叉树，比如影像和DEM；三维数据用八叉树和R树，比如激光点云和BIM。那倾斜摄影是三维的，是不是也用八叉树呢？不是，倾斜摄影用的是四叉树。因为在倾斜摄影中，模型的高度和模型的长、宽相比，非常的小，如果用八叉树建索引，也只有高度最低的那一层才有数据，也就相当于四叉树。同理，对于机载LiDAR点云，一般也是用四叉树做索引。

用树形结构对场景数据组织，在渲染过程中，先从树的根节点开始渲染，其中通常保存场景中最粗糙的模型，当用户逐渐拉近相机与模型的距离，开始慢慢绘制下层节点对应的模型，直至最终绘制叶节点中的最精细的模型。

4. OSG与Cesium中模型LOD的异同

OSG和Cesium都可以用来渲染大场景的三维模型，可以说是目前GIS领域最常用的两个渲染引擎。上述所说的LOD、PageLOD与HLOD在两个引擎中都得到支持，但细节上又有所区别。主要表现在以下几点：

(1)索引结构的存储方式不同。OSG把模型的索引结构直接存储在模型文件(OSG或者OSGB文件)中，而Cesium则是将索引与模型分开，单独存储在Json文件中。比如同一份倾斜摄影数据，OSG格式的通常只有OSGB文件，而Cesium格式则包含Json和b3dm文件。

(2)调度方式的不同。OSG是根据视点距离、或者把视点距离换算成模型在屏幕上的大小，即Pixel Size来判断应该调度什么细节层次的模型进行渲染。Cesium则是通过视点距离计算几何误差，根据模型在屏幕上的渲染误差来决定调度模型的精细度。

(3)LOD的渲染模式的不同。OSG仅支持Replace的LOD模式，即精细模型和粗糙模型不能同时出现，而Cesium则同时支持Replace和Add两种模式，即粗糙模型和精细模型可以同时出现在场景中。

读者可能会很奇怪，为什么Cesium增加Add这种模式呢？因为Replace这种模式不适用大型BIM模型。比如一栋楼有10万个构件(不考虑合并)，而且同时出现在当前渲染窗口，如果是Replace模式，即使是最粗糙层，也会有10万个构件进入渲染管线，哪怕你离的非常远，只能看到一个屋顶。如果引擎支持Add模式，即离的远看到的构件就比较少，视点拉近显示的构件数量逐渐变多，是不是比Replace更合理呢？

而且，Add这种模式下，不需要去做模型简化，也就不会增加数据量。这一点倒不是说OSG比较落后，而是OSG出现的时间比较早，自然不会想到后面会有BIM这种数据。另外，OSG也是可以通过复杂的组织方式来实现Add这种效果，只是会增加数据组织的复杂度。下图为Add模式(左)和Replace模式(右)对比，读者自行判断优劣。

或许有人会说Add这种模式就不属于LOD了，确实如此，所以Cesium说是Level Of Importance，即重要性层次，优先显示重要的对象，先填充满画面，再显示次要的对象。借此来快速填充满整个画面，不让用户有等待加载的感觉。

以上就是本次的全部内容，非常感谢您的阅读。如果喜欢这篇文章，请务必转发，让更多人看到。如果您还未关注本号 ，以免错过更多、更好的文章。