基于內(nèi)存數(shù)據(jù)庫的三維模型管理方法

劉天漪，鐘志農(nóng)，熊 偉，甘麟露，陳 犖

(國防科技大學(xué) 電子科學(xué)與工程學(xué)院，湖南 長沙 410073)

0 引 言

三維場景是三維地理信息系統(tǒng)的重要組成部分，如何實現(xiàn)三維場景的流暢顯示是目前三維地理信息系統(tǒng)的重要問題。三維模型是組成三維場景的主要元素，每個模型同時包含頂點、紋理和語義等多種信息，其結(jié)構(gòu)復(fù)雜，內(nèi)容豐富，數(shù)據(jù)量大。就一個城市場景而言，三維模型的數(shù)據(jù)量少則幾個GB，多則上百GB。在面向Web的三維可視化應(yīng)用中，由于三維模型數(shù)據(jù)量大，造成磁盤I/O和網(wǎng)絡(luò)傳輸時間較長，瀏覽器端等待繪制的時間也會增加，可視化效率會降低。因此，為實現(xiàn)三維場景的流暢顯示，需要對三維模型進(jìn)行高效組織管理。

目前，三維模型的格式和來源多樣，并在數(shù)據(jù)組織和管理上沒有統(tǒng)一的標(biāo)準(zhǔn)?，F(xiàn)階段常用的管理方法與二維數(shù)據(jù)類似，主要有文件管理方式[1]和關(guān)系數(shù)據(jù)庫管理方式[2]。采用文件系統(tǒng)管理方式，三維模型未得到有效的組織，數(shù)據(jù)冗余量大。而基于數(shù)據(jù)庫的管理方式則主要管理三維模型的元數(shù)據(jù)信息，側(cè)重解決模型的存儲、檢索等方面的問題，較少涉及對三維場景可視化效率的研究。兩種方式在實際Web應(yīng)用中，均存在存取模型速度慢、響應(yīng)時間長、可視化效率低等問題。為克服上述問題，本文提出了一種基于redis內(nèi)存數(shù)據(jù)庫的三維模型管理方法。實驗結(jié)果表明，采用該方法管理三維模型，能較大提高三維場景可視化的效率。

1 相關(guān)核心技術(shù)

1.1 glTF三維模型

在通過瀏覽器瀏覽三維場景時，三維模型數(shù)據(jù)是網(wǎng)絡(luò)傳輸?shù)闹饕獌?nèi)容，傳輸效率直接影響模型可視化效果。因此，需要一種占用空間小、傳輸速度快、與圖形繪制接口良好對接的三維模型數(shù)據(jù)格式。

glTF是一種專為WebGL設(shè)計的，利于高效傳輸和加載三維場景的三維模型格式[3]。它描述三維模型全場景，包含模型的網(wǎng)格結(jié)構(gòu)、紋理圖片等信息，其結(jié)構(gòu)如圖1所示。一個完整的glTF模型共分4個部分：.gltf文件，.bin文件，.glsl文件和.jpg或.png文件。其中，.gltf文件是整個模型的核心，它存儲模型的節(jié)點層次、材質(zhì)、相機(jī)等信息；.bin文件是二進(jìn)制幾何文件，主要存儲模型的頂點坐標(biāo)和坐標(biāo)的索引等信息；.glsl文件是著色器文件，主要存儲圖像渲染所需的頂點著色器和像元著色器；.jpg或.png文件是模型的紋理貼圖文件。在實際應(yīng)用中，為降低前端瀏覽器的并發(fā)請求數(shù)，可將著色器文件、二進(jìn)制幾何文件和貼圖文件利用Data URL技術(shù)，以base64字符串格式內(nèi)嵌到glTF文件中，成為一體。

圖1 glTF模型Fig.1 glTF model

將貼圖文件以base64編碼的方式內(nèi)嵌到glTF中，在使用時還需要另外解碼，且三維模型文件大小增加了30%左右。為解決上述問題，Khrono組織官方引入Binary glTF擴(kuò)展[4]，它既能夠?qū)⑺術(shù)lTF資產(chǎn)整合到一個文件中，又能夠解決base64位編碼帶來的損失。Binary glTF文件結(jié)構(gòu)如圖2所示。它由三部分組成：20位的頭文件(20-byte header)、json格式的場景描述(content)以及二進(jìn)制塊(body)。其中二進(jìn)制塊是最關(guān)鍵的部分，它包含所有的頂點、索引、圖片和著色器信息，將所有的整型、單精度浮點型的頂點數(shù)據(jù)以四字節(jié)的數(shù)組編碼。

圖2 binary glTF文件結(jié)構(gòu)Fig.2 Binary glTF file structure

1.2 redis內(nèi)存數(shù)據(jù)庫

redis是一種鍵值對(Key-Value)數(shù)據(jù)庫[5]，它利用哈希表在鍵(key)與值(value)建立映射關(guān)系。鍵值對建立之后，通過key可以快速查找到對應(yīng)的value。因此對于單個key的查找來說，Key-Value存儲能夠獲得良好的性能。

利用redis數(shù)據(jù)庫管理三維模型的優(yōu)點主要有：

1）減少磁盤I/O，提高模型存取速度。由于redis是內(nèi)存數(shù)據(jù)庫，所有的數(shù)據(jù)不經(jīng)過磁盤直接調(diào)用，對于加載數(shù)據(jù)量較大的三維模型，縮短了響應(yīng)時間。

2）支持集群模式。單個計算機(jī)的內(nèi)存容量有限，因此存儲大數(shù)據(jù)量的三維模型受到限制。而redis提供Cluster集群方案，可以將內(nèi)存容量擴(kuò)展，并對數(shù)據(jù)分塊存儲。

3）持久化設(shè)計。redis作為內(nèi)存數(shù)據(jù)庫，能夠在將數(shù)據(jù)加載到內(nèi)存操作的同時，異步將其flush到硬盤中保存，以此保證服務(wù)器重啟后數(shù)據(jù)不丟失。

4）豐富的數(shù)據(jù)結(jié)構(gòu)。與其他非關(guān)系型數(shù)據(jù)庫不同，redis中數(shù)據(jù)類型不僅限于字符串，還支持字符串列表、無序不重復(fù)的字符串集合、有序不重復(fù)的字符串集合以及key-value都為字符串的哈希表。

5）地理特性。Redis數(shù)據(jù)庫可以存儲地理空間信息，并進(jìn)行簡單的操作。

1.3 WebGL技術(shù)與Cesium三維引擎

WebGL誕生于2010年，是由科納斯組織(KhronosGro up)開發(fā)和維護(hù)的一種基于 JavaScript免費(fèi)的、跨平臺的應(yīng)用程序接口API[6]。它運(yùn)用JavaScript腳本制作Web交互式三維圖形程序，利用統(tǒng)一的OpenGL接口，通過底層圖形處理硬件加速功能進(jìn)行圖形渲染。利用WebGL技術(shù)，可以無需插件，直接通過瀏覽器加速圖形硬件，提高渲染速度。

Cesium是一個通過Web瀏覽器創(chuàng)建三維地球和二維地圖的JavaScript庫[7]。它無需任何插件，能夠在支持HTML5標(biāo)準(zhǔn)的瀏覽器上運(yùn)行。由于Cesium基于WebGL技術(shù)提供圖形加速，因此在渲染較復(fù)雜的三維模型時可以顯著提高性能，適合大范圍三維場景的可視化。除此之外，Cesium還廣泛收集庫，能夠在三維地球上執(zhí)行各類地理信息分析。

2 基于redis的三維模型管理方法關(guān)鍵技術(shù)

2.1 三維模型數(shù)據(jù)格式轉(zhuǎn)換

目前，glTF還未成為行業(yè)標(biāo)準(zhǔn)，各大商業(yè)建模軟件還不支持直接以glTF格式導(dǎo)出三維模型，只能先以collada格式導(dǎo)出，再通過數(shù)據(jù)預(yù)處理過程轉(zhuǎn)成glTF格式。還可根據(jù)需要，轉(zhuǎn)成Binary glTF格式。

具體流程如圖3所示。

圖3 數(shù)據(jù)預(yù)處理流程Fig.3 Data pretreatment process

1)利用建模軟件CityEngine，建立費(fèi)城地區(qū)大規(guī)模三維場景數(shù)據(jù)集，以collada格式導(dǎo)出。建模后的費(fèi)城數(shù)據(jù)集共有collada模型文件412個，紋理圖片125張，共41.5 M。

2)采用mpi并行框架，編寫多進(jìn)程批處理轉(zhuǎn)換程序mpicollada2glTF.py，將模型全部轉(zhuǎn)化成glTF格式。同時利用python語言的xml解析模塊xmlElementree解析collada模型，提取元數(shù)據(jù)信息，包括模型的名稱、高度、底面中心坐標(biāo)、底面中心坐標(biāo)Geohash值及其他相關(guān)屬性信息，名字作為下一步查詢模型的索引，坐標(biāo)信息用來決定模型在可視化過程中放置的位置。把所有模型的元數(shù)據(jù)信息寫入一個xml元數(shù)據(jù)文件，作為下一步調(diào)度模型可視化的索引文件。

3)通過利用python語言編寫的批處理程序gltf2glb.py把所有g(shù)lTF模型轉(zhuǎn)換為Binary glTF格式，并存入數(shù)據(jù)庫管理，以便下一步調(diào)用。

2.2 基于redis的三維模型數(shù)據(jù)存儲結(jié)構(gòu)

根據(jù)空間數(shù)據(jù)庫的一般組成結(jié)構(gòu)和三維模型數(shù)據(jù)的特點，設(shè)計基于redis的三維模型數(shù)據(jù)庫。它為三級存儲結(jié)構(gòu)，如圖4所示。

圖4 基于redis的三維模型三級存儲結(jié)構(gòu)Fig.4 3-level store structure of 3D model based on redis

第一級為三維空間數(shù)據(jù)庫，包括一個區(qū)域集列表和描述該空間數(shù)據(jù)庫的元數(shù)據(jù)信息。區(qū)域集列表采用redis的set數(shù)據(jù)結(jié)構(gòu)存儲所有的區(qū)域集名稱，key=3DsetsList，value為數(shù)據(jù)庫內(nèi)所有的區(qū)域集，利用redis的smembers命令可返回三維空間數(shù)據(jù)庫中所有的區(qū)域集成員；空間數(shù)據(jù)庫元數(shù)據(jù)信息采用redis的hash數(shù)據(jù)結(jié)構(gòu)管理，包括數(shù)據(jù)庫的名稱(name)，描述(description)和版本(version)。

第二級是區(qū)域集，按照區(qū)域?qū)⑷S模型劃分到不同的集合中。和上一級結(jié)構(gòu)類似，區(qū)域集也包括兩部分，即區(qū)域內(nèi)建筑要素集合和區(qū)域的元數(shù)據(jù)信息。區(qū)域內(nèi)建筑要素集合同樣采用set數(shù)據(jù)結(jié)構(gòu)管理區(qū)域內(nèi)所有的建筑要素，key=Dataset:A:ModelList，value為區(qū)域內(nèi)所有建筑要素，可通過keys命令獲取區(qū)域內(nèi)全部建筑，也可判斷某建筑是否在該區(qū)域集內(nèi)。利用geoadd命令可將區(qū)域集內(nèi)建筑元素及其經(jīng)緯度坐標(biāo)信息全部添加，還可利用geopos命令獲取建筑元素地理位置，方便在可視化過程中將模型放置在正確地理位置；區(qū)域集的元數(shù)據(jù)信息也采用hash數(shù)據(jù)結(jié)構(gòu)，包括該區(qū)域的名稱，包圍盒范圍(Xmax，Xmin，Ymax，Ymin)，此外由于每個區(qū)域集建模的參考系不一定完全相同，所以還需要將坐標(biāo)參考系信息(SRID)作為重要元數(shù)據(jù)信息存儲。

第三級為建筑要素，不僅管理三維模型空間信息，也管理語義信息。用hash數(shù)據(jù)結(jié)構(gòu)存儲模型的經(jīng)緯度信息、Geohash值和全部模型資產(chǎn)(.gltf文件)。Geohash 字段用來存儲該建筑要素的空間編碼，空間編碼可將模型底面中心的二維位置坐標(biāo)轉(zhuǎn)化為一維的字符串，以string類型存儲，它將是進(jìn)一步研究中構(gòu)建redis集群索引的基礎(chǔ)。.gltf文件以string格式存儲在geometry字段中，代表該模型元素的全部資產(chǎn)；建筑要素的語義信息較多，適合用hash數(shù)據(jù)結(jié)構(gòu)存儲，包括名稱(name)，id等其他屬性信息。

為保證建筑要素的key值唯一，需要將三維空間數(shù)據(jù)庫、區(qū)域集、建筑要素3個部分組合起來，每部分的名稱都需要保證全局唯一。以費(fèi)城數(shù)據(jù)集某一建筑要素為例，設(shè)計其key為db1:phil:Shape1.gltf，通過主鍵索引，即可從數(shù)據(jù)庫db1、區(qū)域phil、建筑名Shape1.gltf獲得唯一建筑要素。采用這種方式組織三維模型，可以迅速檢索所需空間數(shù)據(jù)庫、區(qū)域集、建筑要素及其相關(guān)信息。通過這樣的策略，在下一步的數(shù)據(jù)發(fā)布階段，使得服務(wù)器端可以直接通過key定位指定模型，將數(shù)據(jù)返回瀏覽器前端進(jìn)行繪制。

2.3 數(shù)據(jù)的發(fā)布與可視化

由于redis中的數(shù)據(jù)存儲在內(nèi)存中，而Cesium繪制引擎通過調(diào)用統(tǒng)一資源定位符(url)獲得數(shù)據(jù)資源，因此需要建立Web服務(wù)，將內(nèi)存數(shù)據(jù)庫中的數(shù)據(jù)通過url發(fā)布。數(shù)據(jù)發(fā)布過程如圖5所示，其基本流程如下：瀏覽器端先向Web服務(wù)發(fā)出Get請求，當(dāng)Web服務(wù)收到Get請求后，從基于redis的三維模型數(shù)據(jù)庫中調(diào)用所需模型，然后通過Web服務(wù)將請求的模型返回給前端，最終由Cesium引擎實現(xiàn)可視化。其中Web服務(wù)基于輕量級Web應(yīng)用框架Flask編寫，將自定義的get函數(shù)動態(tài)綁定到url上，可以實現(xiàn)前端通過url獲取內(nèi)存中數(shù)據(jù)的功能。而自定義的get函數(shù)，就是根據(jù)key從三維模型數(shù)據(jù)庫中取得模型數(shù)據(jù)的過程。

圖5 三維模型數(shù)據(jù)發(fā)布過程Fig.5 3D data publish process

3 實驗結(jié)果與分析

為驗證本文提出的方法對可視化效果的優(yōu)化，進(jìn)行了兩組對比實驗。一是對采用傳統(tǒng)文件系統(tǒng)和本文方法管理的模型加載時間對比，二是采用本文方法管理glTF模型和帶有Binary glTF擴(kuò)展的模型加載時間對比。實驗環(huán)境配置如下：瀏覽器端為Intel i5-4570 CPU，16G內(nèi)存；服務(wù)器端為4個Intel Xeon E5-4620 2.2GHz CPU，529G內(nèi)存。瀏覽器端操作系統(tǒng)為win7，安裝有chrome瀏覽器；服務(wù)器端操作系統(tǒng)為centOS，安裝有redis數(shù)據(jù)庫。實驗數(shù)據(jù)為費(fèi)城某城市場景，經(jīng)過預(yù)處理后生成的glTF格式的數(shù)據(jù)量大小為868.4 M，再轉(zhuǎn)換為Binary glTF格式的數(shù)據(jù)量大小為868.4 M。

3.1 不同管理方法下模型的加載效率測試

前端分別對文件系統(tǒng)和本文提出的三維數(shù)據(jù)庫請求50、100、200、300個模型，進(jìn)行3次測試，取3次實驗耗時的平均值。采用傳統(tǒng)文'件系統(tǒng)和本文方法管理的模型加載時間對比如圖6所示。

圖 6 不同管理方式加載時間對比Fig.6 Comparison of different management approaches'loading time

不難看出，無論采用哪種管理方法，隨著模型數(shù)量的增多，加載時間幾乎都呈線性增長。采用本文方法管理的模型，全部加載時間小于從文件系統(tǒng)加載模型的時間，且兩者的時間差值隨著模型數(shù)量的增大而增大。

可視化情況對比如圖7所示，圖7（a）為從文件系統(tǒng)獲取，圖7（b）為從redis獲取。相同時間內(nèi)，瀏覽器界面上的模型數(shù)量存在明顯差異。采用本文方法管理的模型比采用文件系統(tǒng)管理的模型數(shù)量多，可視化效率更高。

圖7 加載模型情況對比圖Fig.7 Comparison of visualization between different management approaches

分析兩者性能差異原因，主要在于本文提出的方法基于redis內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)存放在內(nèi)存中，服務(wù)器在接到前端請求后，不需要先從磁盤取出數(shù)據(jù)，減少了磁盤I/O，縮短了響應(yīng)時間。而傳統(tǒng)的文件系統(tǒng)，數(shù)據(jù)存放在硬盤中，需要先將數(shù)據(jù)傳輸?shù)絻?nèi)存中，請求才能得到響應(yīng)。因此受制于磁盤I/O瓶頸，采用文件系統(tǒng)管理三維模型比采用本文方法管理三維模型加載效率低。

3.2 不同格式模型的加載效率測試

采用本文方法，分別加載普通glTF格式模型和Binary glTF格式模型，不同格式數(shù)據(jù)加載時間對比如圖8所示。

圖8 不同格式模型加載時間對比Fig.8 Comparison of different format models of loading time

加載Binary glTF模型所需時間比加載普通的glTF模型略有縮短，但效果不夠明顯，加載300個模型的時間僅縮短1s左右。分析其原因，主要在于Binary glTF模型的數(shù)據(jù)量小于普通glTF模型的數(shù)據(jù)量，所以縮短了模型的內(nèi)容下載時間。完整的模型加載時間包括排隊時間、遲滯時間、網(wǎng)絡(luò)連接時間、請求時間、等待響應(yīng)時間、內(nèi)容下載時間等，其中內(nèi)容下載時間不是影響整個模型加載時間的主要因素。因此采用Binary glTF模型，不會顯著提升模型的加載效率。

除此之外，在加載全部數(shù)量的模型時，采用glTF模型出現(xiàn)滑動鼠標(biāo)不流暢、瀏覽器卡頓甚至崩潰的情況，而采用Binary glTF模型則可以全部加載。由此可見，采用數(shù)據(jù)量更小的Binary glTF模型對前端壓力更小。

加載全部模型俯視圖如圖9所示，模型細(xì)節(jié)圖如圖10所示。

圖9 費(fèi)城數(shù)據(jù)集的全部模型Fig.9 All models of the Philadelphia dataset

圖10 費(fèi)城數(shù)據(jù)集的模型細(xì)節(jié)Fig.10 The model details of the Philadelphia dataset

4 結(jié)束語

本文提出了一種基于redis內(nèi)存數(shù)據(jù)庫的三維模型管理方法，設(shè)計和實現(xiàn)了以redis為基礎(chǔ)的三維模型數(shù)據(jù)庫的分級組織結(jié)構(gòu)，對普通glTF模型和Binary glTF模型進(jìn)行管理。實驗結(jié)果表明，較之常用的文件管理方式，該方法有效提升模型的加載效率。模型調(diào)用速度顯著提高，模型加載時間平均縮短20%左右，可視化效果更加流暢。除此之外還發(fā)現(xiàn)，盡管數(shù)據(jù)量更小的Binary glTF模型在提升模型加載效率方面效果不明顯，但其減小的數(shù)據(jù)量足夠減輕前端的繪制壓力，且減少了網(wǎng)絡(luò)傳輸時間，也在一定程度上提高了可視化效率。因此，采用本文提出的基于redis的三維模型管理方法管理數(shù)據(jù)量小、適合可視化的Binary glTF模型，可以有效提高三維模型的可視化效率，優(yōu)化可視化效果。

在下一步的研究中，還需要考慮更大規(guī)模的模型場景可視化效率。擬考慮對三維模型進(jìn)行LOD分級，在一次性加載大規(guī)模的模型時根據(jù)視點高度選擇合適層級的模型進(jìn)行加載，進(jìn)一步提高模型加載效率，減輕前端瀏覽器繪制壓力，優(yōu)化三維場景可視化效果；另外還可以采用redis集群，以geohash值作為索引，將地理臨近的三維模型映射到同一節(jié)點中，實現(xiàn)高效率的范圍查詢。