黃丙湖 王 濤 徐幫樹 張家寶 何亞文

1(中國(guó)石油大學(xué)(華東)海洋與空間信息學(xué)院 山東 青島 266580)

2(山東大學(xué)齊魯交通學(xué)院 山東 濟(jì)南 250061)

3(山東科技大學(xué)土木工程與建筑學(xué)院 山東 青島 266590)

0 引 言

BIM(Building Information Modeling)技術(shù)在AECO/FM(Architecture,Engineering,Construction,Operations and Facility Management)行業(yè)的廣泛運(yùn)用[1]和Web 3D技術(shù)日漸成熟,掀起了一股WebBIM研究與應(yīng)用熱潮。由于BIM中包含建筑全生命周期的幾何信息和語義信息,通過BIM服務(wù)器,可將信息實(shí)時(shí)更新和最大范圍共享,提高各個(gè)運(yùn)營(yíng)商之間的溝通效率,減少運(yùn)營(yíng)成本。

在WebBIM的研究中,魏國(guó)富等[2]基于OBJ與SVG的ID映射,實(shí)現(xiàn)模型與平面圖紙的二三維聯(lián)動(dòng)。Wei[3]通過將Autodesk Forge View、Dynamo與Flux的集成,開發(fā)了一款BIM參數(shù)化設(shè)計(jì)系統(tǒng),允許多人協(xié)同設(shè)計(jì)。Scully等[4]利用3D Repo云服務(wù)設(shè)計(jì)了基于X3DOM的3D BIM版本控制系統(tǒng)。劉小軍等[5]提出了一套面向手機(jī)網(wǎng)頁瀏覽大規(guī)模三維場(chǎng)景的漫游算法。Chen等[6]提出基于Bigtable和MapReduce的分布式系統(tǒng)框架用于存儲(chǔ)、瀏覽和計(jì)算大規(guī)模BIM數(shù)據(jù)。

然而BIM有眾多的數(shù)據(jù)源,各數(shù)據(jù)依賴于軟件系統(tǒng)環(huán)境而無法直接被WebGL讀取和渲染,IFC(Industry Foundation Classes)標(biāo)準(zhǔn)的發(fā)布,有助于BIM數(shù)據(jù)在不同軟件平臺(tái)之間實(shí)現(xiàn)共享和交換。在這里,BIM模型可以劃分為IFC標(biāo)準(zhǔn)模型和專業(yè)軟件模型[7],對(duì)于這兩類模型的數(shù)據(jù)轉(zhuǎn)換,有眾多的學(xué)者做了相關(guān)研究。Xu等[8-9]利用IFCOpenShell工具實(shí)現(xiàn)對(duì)IFC數(shù)據(jù)的提取與格式轉(zhuǎn)換。針對(duì)專業(yè)軟件模型,除了眾多軟件生產(chǎn)商提供的解決方案如Autodesk Forge View、FME、BimAngle Engine和SimLab等,也同樣引起了相關(guān)從業(yè)者和學(xué)者的關(guān)注。Jeremy Tammik開源了RvtVa3c項(xiàng)目,對(duì)Revit數(shù)據(jù)的自定義導(dǎo)出具有很好的指導(dǎo)意義。陳志楊等[10]借助Revit API完成BIM屬性信息和幾何信息的提取。

現(xiàn)今,隨著數(shù)據(jù)量激增,對(duì)本已經(jīng)包含大量信息的BIM數(shù)據(jù)而言,有限的存儲(chǔ)資源和計(jì)算能力成為技術(shù)發(fā)展的瓶頸,BIM輕量化成為關(guān)鍵技術(shù)[11-12]。Zhou等[13]基于IFC數(shù)據(jù),利用Delaunay三角剖分算法對(duì)B-rep(Boundary Representation)模型進(jìn)行重構(gòu)并通過實(shí)例復(fù)用實(shí)現(xiàn)BIM輕量化存儲(chǔ)。Zhou等[14]提出S-LPM框架,通過對(duì)Mesh分割和重復(fù)體素去除操作,實(shí)現(xiàn)模型輕量化,Liu等[15]將其運(yùn)用至智慧城市可視化管理中。

綜上所述,由于IFC作為一種開放的數(shù)據(jù)標(biāo)準(zhǔn),有較多的學(xué)者對(duì)其進(jìn)行深入的研究。但由于IFC涉及廣泛的應(yīng)用領(lǐng)域和模型參數(shù)化設(shè)計(jì)給幾何數(shù)據(jù)重構(gòu)與數(shù)據(jù)輕量化帶來一定的困難。作為商業(yè)模型數(shù)據(jù),往往有軟件廠商提供相應(yīng)的解決方案和軟件接口服務(wù)。轉(zhuǎn)換的數(shù)據(jù)會(huì)用于特定的平臺(tái),轉(zhuǎn)換的細(xì)節(jié)對(duì)于用戶來說是“黑箱操作”。借助IFC、IndoorGML、FBX、OBJ等一些中間數(shù)據(jù)進(jìn)行交換會(huì)產(chǎn)生一定的數(shù)據(jù)冗余和數(shù)據(jù)損失,隨著轉(zhuǎn)換鏈的增長(zhǎng),這些風(fēng)險(xiǎn)發(fā)生的概率會(huì)增加。本文從應(yīng)用的角度出發(fā),借鑒RvtVa3c開源項(xiàng)目,通過Revit API,設(shè)計(jì)RVT轉(zhuǎn)GLB數(shù)據(jù)的程序接口,實(shí)現(xiàn)BIM數(shù)據(jù)的輕量化存儲(chǔ),在一定意義上減少信息在轉(zhuǎn)換過程中發(fā)生丟失的現(xiàn)象。

1 Revit幾何信息描述

Revit是一個(gè)記錄與設(shè)計(jì)的平臺(tái),一份Revit數(shù)據(jù)中不僅包含模型的幾何信息,同時(shí)包含設(shè)計(jì)所需的明細(xì)表、設(shè)計(jì)圖紙與二維和三維的視圖信息等。在數(shù)據(jù)提取與轉(zhuǎn)換過程中,首先需要了解Revit坐標(biāo)系和幾何數(shù)據(jù)結(jié)構(gòu)。

1.1 Revit坐標(biāo)系

Revit使用三種坐標(biāo)原點(diǎn),分別為測(cè)量點(diǎn)、項(xiàng)目基點(diǎn)和圖形原點(diǎn)。以測(cè)量點(diǎn)為原點(diǎn)的坐標(biāo)系為測(cè)量坐標(biāo)系,用于描述項(xiàng)目基點(diǎn)在真實(shí)世界中的位置;以項(xiàng)目基點(diǎn)為原點(diǎn)的坐標(biāo)系為局部坐標(biāo)系,用于描述建筑間的相對(duì)位置關(guān)系;而以圖形原點(diǎn)為坐標(biāo)原點(diǎn)的坐標(biāo)系為模型坐標(biāo)系,用于描述三維視圖中各個(gè)構(gòu)件的幾何位置,原點(diǎn)為(0,0,0)。在三維視圖中,族實(shí)例可用Transform表示為：

(1)

式中：O為距離圖形原點(diǎn)的位移;(a1,a2,a3)T、(b1,b2,b3)T、(c1,c2,c3)T為族實(shí)例本地坐標(biāo)系的坐標(biāo)軸在模型坐標(biāo)系中的向量表示。

其次,Revit在三維視圖中使用左手坐標(biāo)系,以屏幕向右為X軸正方向,豎直向上為Z軸正方向,垂直屏幕向里為Y軸正方向;而WebGL多使用右手坐標(biāo)系,即水平向右為X軸正方向,豎直向上為Y軸正方向,垂直屏幕向外為Z軸正方向,圖1表示Revit坐標(biāo)系轉(zhuǎn)向WebGL右手坐標(biāo)系的過程,其中當(dāng)模型需要整體偏移或姿態(tài)調(diào)整時(shí),可在GLTF的根節(jié)點(diǎn)Node中指定偏轉(zhuǎn)矩陣。

圖1 坐標(biāo)轉(zhuǎn)換

1.2 Revit模型信息組織

Revit建模是基于對(duì)象的,族(或稱為圖元)是一類相同構(gòu)件的抽象,如單扇窗、雙扇窗、百葉窗等,族的參數(shù)定義了構(gòu)件的行為。族類別是對(duì)族集合的分類,如窗、柱、墻等,而族類型是對(duì)族的細(xì)分,它定義了某一族的不同尺寸與材料等。在三維視圖中所看到的每個(gè)構(gòu)件,都是某一族類型的實(shí)例,對(duì)于尺寸大小固定的族類型可以通過Transform矩陣來構(gòu)建不同位置的構(gòu)件。

在BIM輕量化中需要獲得每個(gè)構(gòu)件的圖形信息,如圖2所示,每個(gè)構(gòu)件可以由任意一個(gè)圖形元素構(gòu)成。在數(shù)據(jù)轉(zhuǎn)化過程中,需要獲取組成這些圖形元素的點(diǎn)坐標(biāo)、索引和法向量等幾何信息以及變換矩陣信息。

圖2 Revit圖形元素

2 GLTF信息描述

一個(gè)好的數(shù)據(jù)結(jié)構(gòu)影響著傳輸、渲染和功能實(shí)現(xiàn)。GLTF(GL Transmission Format)作為面向圖形實(shí)時(shí)快速渲染,可擴(kuò)展的數(shù)據(jù)傳輸格式。它因直接傳輸給圖形API,不需要二次轉(zhuǎn)換,格式開源而得到業(yè)界的廣泛認(rèn)可。因此本文選用GLB作為BIM模型信息的存儲(chǔ)格式。

2.1 GLTF數(shù)據(jù)結(jié)構(gòu)

通常,一個(gè)GLTF文件包含以JSON格式存儲(chǔ)的場(chǎng)景信息文件和一個(gè)存儲(chǔ)幾何信息的二進(jìn)制文件,gltf文件中buffers數(shù)組的每個(gè)元素通過URI引用bin文件。如圖3所示,gltf文件中包含場(chǎng)景、相機(jī)、節(jié)點(diǎn)樹、材料信息、緩沖區(qū)信息等,各個(gè)鍵值元素之間通過索引進(jìn)而描述整個(gè)場(chǎng)景需要繪制的信息,bin文件主要包含頂點(diǎn)坐標(biāo)、頂點(diǎn)索引、法向量、關(guān)鍵幀、綁定姿勢(shì)的逆矩陣等。而紋理信息可以在gltf中的images元素通過URI引用外部的圖片文件,也可以同幾何信息一樣寫入bin文件中或者以base64編碼寫入gltf的buffers中。

在gltf場(chǎng)景文件中,scene指定scenes數(shù)組中需要渲染的node節(jié)點(diǎn),nodes數(shù)組中的每個(gè)node元素既可以指向一個(gè)mesh元素,也可以有子節(jié)點(diǎn)。多個(gè)node可以指定同一個(gè)mesh元素,實(shí)現(xiàn)幾何數(shù)據(jù)的復(fù)用,減少數(shù)據(jù)冗余。圖4顯示從gltf和bin文件中獲取信息繪制線段的過程。圖中indices和POSITION分別指向頂點(diǎn)索引和頂點(diǎn)坐標(biāo)的accessor存取器元素,accessor描述從bufferView中獲取數(shù)據(jù)方式和數(shù)據(jù)類型。同樣,兩個(gè)accessors中的bufferView各自指向bufferViews中對(duì)應(yīng)頂點(diǎn)索引和頂點(diǎn)坐標(biāo)的bufferView元素,bufferView描述其在整個(gè)二進(jìn)制緩沖區(qū)的位置,字節(jié)長(zhǎng)度以及數(shù)據(jù)存儲(chǔ)的間隔等信息。meshes中mode指示獲取數(shù)據(jù)后的繪制方式,如點(diǎn)、線、三角扇等。其中componentType、type、mode和target屬性值均是常量枚舉值。

圖4 GLTF數(shù)據(jù)解析

每個(gè)node還可以指定該節(jié)點(diǎn)的4×4矩陣用于調(diào)整姿態(tài),在渲染時(shí),所有的子節(jié)點(diǎn)都必須經(jīng)過父節(jié)點(diǎn)矩陣左乘。一般的,node中的矩陣還可以分解為T×R×S,T與S分別表示偏移和縮放,均為32位浮點(diǎn)值類型、長(zhǎng)度為3的數(shù)組,而R表示四元數(shù)旋轉(zhuǎn),為32位浮點(diǎn)值類型、長(zhǎng)度為4的數(shù)組。

相比于歐拉變換容易產(chǎn)生萬向節(jié)死鎖問題以及矩陣變換至少需要存儲(chǔ)9個(gè)參數(shù)參與計(jì)算,四元數(shù)變換只需存儲(chǔ)4個(gè)參數(shù)就可以完成復(fù)雜的旋轉(zhuǎn)。令旋轉(zhuǎn)單位四元數(shù)q=[w,x,y,z],向量p=[0,vx,vy,vz],則經(jīng)過q變換后的向量為：

p′=qpq-1

(2)

p′=[wxyz]×[0vxvyvz]×

[w-x-y-z]

(3)

(4)

因此,四元數(shù)(右手性)轉(zhuǎn)換成3×3矩陣為：

(5)

根據(jù)式(5),可以求得旋轉(zhuǎn)矩陣對(duì)應(yīng)的四元數(shù)。

2.2 GLB數(shù)據(jù)結(jié)構(gòu)

如前所述,通常GLTF文件主要包含gltf和bin文件,就意味著至少要向服務(wù)器發(fā)送兩次Http請(qǐng)求,而將bin數(shù)據(jù)以base64編碼寫入gltf文件中則在渲染時(shí)需要額外的解碼時(shí)間。在考慮后期工作需要頻繁調(diào)度數(shù)據(jù),本文最終采用GLB數(shù)據(jù)格式。

如圖5所示,GLB文件是將gltf和bin文件整合在一起以小端字節(jié)序存儲(chǔ)的二進(jìn)制文件。它開始包含12字節(jié)頭,分別為magic、version和length,用于描述文件的GLTF ASCII碼、版本信息和整個(gè)文件所占的字節(jié)長(zhǎng)度。Chunk 0與Chunk 1分別為JSON存儲(chǔ)區(qū)和bin存儲(chǔ)區(qū),length和type均占四個(gè)字節(jié),用于描述JSON和bin的字節(jié)長(zhǎng)度與識(shí)別JSON和BIN字符的ASCII碼。Chunk 0和Chunk 1各存儲(chǔ)的字節(jié)長(zhǎng)度缺省為4的倍數(shù),否則在Chunk 0和Chunk 1后分別用0x20和0x00占位以滿足規(guī)則。

圖5 GLB數(shù)據(jù)結(jié)構(gòu)

2.3 通用GLTF數(shù)據(jù)轉(zhuǎn)GLB數(shù)據(jù)

如下所示,為通用的GLTF數(shù)據(jù)結(jié)構(gòu),將buffer中的uri屬性設(shè)置為null,借助Newtonsoft將GLFT對(duì)象序列化并壓縮成不含空格、換行符的JSON字符串,并將該字符串轉(zhuǎn)換為UTF-8編碼的字節(jié)數(shù)組。根據(jù)2.2節(jié)GLB的數(shù)據(jù)結(jié)構(gòu),用對(duì)應(yīng)的數(shù)據(jù)類型依次寫入0x46546C67、2(GLTF版本為2)、總字節(jié)長(zhǎng)度值、JSON字節(jié)長(zhǎng)度值、0x4E4F534A、JSON字節(jié)數(shù)組、BIN字節(jié)長(zhǎng)度值、0x003E4942,以及每個(gè)BinaryData的幾何數(shù)據(jù)。其中在JSON區(qū)與BIN區(qū)用0x20和0x00所占位數(shù)計(jì)入總字節(jié)長(zhǎng)度和各區(qū)的字節(jié)長(zhǎng)度。

public struct GLTF

{

public Asset asset {get;set;}

public List scenes {get;set;}

public List nodes {get;set;}

public List meshes {get;set;}

public List buffers {get;set;}

public List bufferViews {get;set;}

public List accessors {get;set;}

public List materials {get;set;}

public List textures {get;set;}

public List images {get;set;}

public List samplers {get;set;}

}

public struct BinaryData

{

public List vertexes=new List();

public List normals=new List();

public List uvs=new List();

public List indexes=new List();

}

3 RVT數(shù)據(jù)轉(zhuǎn)換

3.1 數(shù)據(jù)轉(zhuǎn)換

在BIM輕量化的工作中,用于數(shù)據(jù)轉(zhuǎn)換所設(shè)計(jì)的功能主要封裝在以下幾個(gè)類中：

GLTF：包含GLTF的數(shù)據(jù)結(jié)構(gòu)以及常量枚舉。

Map：GLTF中Node、Material、Mesh等數(shù)據(jù)的容器,用于索引的維護(hù)和數(shù)據(jù)的提取與復(fù)用。

GltfMath：用于坐標(biāo)轉(zhuǎn)換、四元數(shù)、包圍盒、最值、向量和矩陣等計(jì)算。

GltfCheck：對(duì)GLTF數(shù)據(jù)的檢查,剔除不合格數(shù)據(jù),維護(hù)索引。

GltfExportContext：繼承Revit IExportContext接口,實(shí)現(xiàn)數(shù)據(jù)的讀取與寫入操作。

其中,Revit提供IExportContext接口以支持BIM數(shù)據(jù)的提取,基本流程如圖6所示。通過遍歷每個(gè)構(gòu)件,實(shí)現(xiàn)坐標(biāo)、法向量、材質(zhì)等信息的提取。

圖6 IExportContext遍歷數(shù)據(jù)流程

根據(jù)接口函數(shù)遍歷的流程,本文在每個(gè)函數(shù)中設(shè)計(jì)了不同的功能：

OnViewBegin：獲取并計(jì)算模型相對(duì)測(cè)量點(diǎn)的旋轉(zhuǎn)四元數(shù)R和偏移矩陣T并賦給RootNode。

OnElementBegin：創(chuàng)建Node節(jié)點(diǎn),計(jì)算構(gòu)件在三維視圖中的包圍盒,提取屬性信息。

OnInstanceBegin：對(duì)含有非Instance的幾何信息,創(chuàng)建子節(jié)點(diǎn)、Mesh、Accessor、BufferView、Buffer對(duì)象,并維護(hù)之間的索引關(guān)系;實(shí)例化Instance子節(jié)點(diǎn),添加父節(jié)點(diǎn)對(duì)Instance子節(jié)點(diǎn)的索引;計(jì)算偏轉(zhuǎn)矩陣并將矩陣入棧。

OnMaterial：在幾何表面的呈現(xiàn)上,GLTF是基于物理的渲染,即通過金屬度和粗糙度來計(jì)算表面的反射效果。該函數(shù)負(fù)責(zé)將Revit的材質(zhì)信息轉(zhuǎn)換為GLTF的材質(zhì)信息,并提取材料屬性;對(duì)已存在相同的Material,記錄該Material的索引,將賦給要?jiǎng)?chuàng)建的Mesh.Primitive中的Material屬性。

OnPolymesh：坐標(biāo)轉(zhuǎn)換,借助RvtVa3c中的VertexLookupInt類實(shí)現(xiàn)頂點(diǎn)去冗。對(duì)于存儲(chǔ)單個(gè)Mesh數(shù)據(jù),需要一定的頂點(diǎn)冗余,如圖7所示,Face1、Face2、Face3共用v1頂點(diǎn),但v1點(diǎn)可能對(duì)應(yīng)多個(gè)法向量或紋理坐標(biāo),因此頂點(diǎn)去冗范圍被限制于繪制單個(gè)面的幾何數(shù)據(jù)。提取坐標(biāo)、法向量,并生成在當(dāng)前Mesh的頂點(diǎn)索引。

圖7 面幾何數(shù)據(jù)去冗

OnInstanceEnd：每個(gè)Instance對(duì)應(yīng)一個(gè)Mesh,并賦予一個(gè)由InstanceNode.NodeName與InstanceNode.getSymbolId().IntegerValue組成的ID。如圖8所示,①和②是具有相同ID、不同位置的構(gòu)件,對(duì)已存在相同ID的Mesh,添加Node對(duì)Mesh的索引;否則創(chuàng)建Mesh、Accessor、BufferView和Buffer對(duì)象,維護(hù)之間索引。計(jì)算該Instance的四元數(shù)R和偏移矩陣T,并賦給Node節(jié)點(diǎn),矩陣出棧。

圖8 族實(shí)例幾何數(shù)據(jù)的復(fù)用

另外,族的結(jié)構(gòu)影響數(shù)據(jù)讀取的行為,對(duì)于同一個(gè)族實(shí)例,也可以實(shí)現(xiàn)內(nèi)部幾何元素的復(fù)用,如圖9所示,欄桿構(gòu)件中包含①實(shí)例,①實(shí)例嵌套著②和③子實(shí)例。

圖9 復(fù)合族實(shí)例

OnElementEnd：對(duì)含有非Instance的幾何信息,創(chuàng)建子節(jié)點(diǎn)、Mesh、Accessor、BufferView和Buffer對(duì)象,維護(hù)索引。

OnLinkBegin：Revit建模過程中,通常會(huì)將項(xiàng)目文件拆分成多個(gè)子文件,目的在于方便管理和減少系統(tǒng)運(yùn)行負(fù)擔(dān)。通過OnLinkBegin函數(shù),將鏈接文件的坐標(biāo)系轉(zhuǎn)到當(dāng)前項(xiàng)目文件的模型坐標(biāo)系中,切換當(dāng)前document對(duì)象,矩陣入棧,將遍歷鏈接文件中的構(gòu)件。

OnLinkEnd：矩陣出棧。

Finish：文件寫入前進(jìn)行數(shù)據(jù)清洗,并檢查GLTF中各個(gè)屬性內(nèi)部的枚舉值、字節(jié)統(tǒng)計(jì)值、數(shù)據(jù)類型、字節(jié)偏移以及屬性內(nèi)部和屬性之間索引的正確性。文件寫入時(shí)動(dòng)態(tài)分配內(nèi)存,例如索引一般不會(huì)超過兩個(gè)字節(jié)。

3.2 數(shù)據(jù)清洗

在數(shù)據(jù)導(dǎo)出過程中,容易產(chǎn)生空節(jié)點(diǎn),造成數(shù)據(jù)不夠整潔、數(shù)據(jù)量增大的情況,甚至?xí)谧x取時(shí)發(fā)生解析錯(cuò)誤。增加條件判斷以應(yīng)對(duì)發(fā)生空節(jié)點(diǎn)的情況往往會(huì)因?yàn)闂l件判斷不當(dāng)而導(dǎo)致數(shù)據(jù)損失,索引錯(cuò)位而難以維護(hù),并且也很難預(yù)防各種出現(xiàn)空節(jié)點(diǎn)的情況。因此本文不再關(guān)注對(duì)發(fā)生不合格節(jié)點(diǎn)情況的判斷,而是最后將每個(gè)構(gòu)件所對(duì)應(yīng)的節(jié)點(diǎn)從數(shù)據(jù)集中單獨(dú)提取出來進(jìn)行維護(hù)。圖10所示為從數(shù)據(jù)集中提取并維護(hù)索引的雙扇窗節(jié)點(diǎn)及其子節(jié)點(diǎn),其中Node1、Node6為空節(jié)點(diǎn),需要被識(shí)別和清除。任何一個(gè)空節(jié)點(diǎn)的清除將會(huì)影響其他節(jié)點(diǎn)位置的變化、潛在空節(jié)點(diǎn)的產(chǎn)生以及節(jié)點(diǎn)在父節(jié)點(diǎn)中索引的變化。

圖10 節(jié)點(diǎn)清洗

對(duì)每個(gè)節(jié)點(diǎn)進(jìn)行檢查,算法流程如下所示。

1) 初始化,獲得Nodes數(shù)組中的根節(jié)點(diǎn)RootNode,根據(jù)RootNode中的children數(shù)組遞歸循環(huán)整個(gè)Nodes數(shù)組,在遞歸循環(huán)中實(shí)例化Segment,每個(gè)Segment中包含當(dāng)前Node、Node在數(shù)組中的索引Index、Node的父節(jié)點(diǎn)索引ParentIndex以及在父節(jié)點(diǎn)的children數(shù)組中的索引DeleteIndex,返回包含Segment的數(shù)組Segments。

2) 遍歷Segments,對(duì)每個(gè)Segment.Node進(jìn)行檢查,偽代碼如下：

輸入：Seg

輸出：none

BEGIN

1： Node←Seg.Node;

2： If(Node.Children is not null and

Node.Children.Count is 0) Then

3： Node.Children←null;

4： If(Node.Children is null and Node.Mesh is null)

Then//節(jié)點(diǎn)不合格

5： Index←Seg.Index;

//該節(jié)點(diǎn)的刪除會(huì)導(dǎo)致后面節(jié)點(diǎn)位置的變化

6： For I←Index+1 to Segments.Count

7： Do TemSeg←Segments[I];

8： TemSeg.Index←TemSeg.Index-1;

9： ParentIndex←TemSeg.ParentIndex;

//對(duì)不是根節(jié)點(diǎn)的父節(jié)點(diǎn)children數(shù)組進(jìn)行維護(hù)

10： If ParentIndex is not -1 Then

11： ParentNode←Segments[ParentIndex].Node;

12： DeleteIndex←TemSeg.DeleteIndex;

13： ParentNode.Children[DeleteIndex]=TemSeg.Index;

//對(duì)父節(jié)點(diǎn)在待刪節(jié)點(diǎn)之后,對(duì)父節(jié)點(diǎn)索引減1

14： If ParentIndex>Index Then

15： ParentIndex←ParentIndex-1;

16： Delete Segments[Index];//節(jié)點(diǎn)刪除

17： PIndex←Seg.ParentIndex;

18： DIndex←Seg.DeleteIndex;

//不合格節(jié)點(diǎn)刪除對(duì)其父節(jié)產(chǎn)生影響

19： If PIndex is not -1 Then

20： PNode←Segments[PIndex].Node;

21： For J←DIndex+1 to PNode.Children.Count

22： Do

Segments[PNode.Children[J]].DeleteIndex=J-1;

23： Delete PNode.Children[DIndex];

//遞歸,對(duì)父節(jié)點(diǎn)進(jìn)行檢查

24： Seg←Segments[PIndex] Goto(1);

END

3) 遍歷Segments,提取Node,返回Nodes數(shù)組。

4 實(shí)驗(yàn)與展示

本文采用C#語言和Visual Studio 2012工具對(duì)Autodesk Revit 2018進(jìn)行二次開發(fā)。將教學(xué)樓、住宅小區(qū)和某施工場(chǎng)地BIM模型作為實(shí)驗(yàn)數(shù)據(jù),使用插件分別將其導(dǎo)出為未執(zhí)行輕量化操作的GLB數(shù)據(jù)、執(zhí)行輕量化操作的GLB數(shù)據(jù)和屬性信息文件,并用Draco對(duì)輕量化后的GLB數(shù)據(jù)進(jìn)行壓縮,處理結(jié)果如圖11所示。

圖11 Revit文件、未輕量化、輕量化與壓縮文件大小對(duì)比

在調(diào)試過程中分別統(tǒng)計(jì)了各GLB數(shù)據(jù)中Mesh的數(shù)量,如表1所示。Mesh數(shù)量在一定程度上體現(xiàn)數(shù)據(jù)輕量化的效果,每多一個(gè)Mesh,在GLB中的bin區(qū)至少多包含一份幾何數(shù)據(jù),與之對(duì)應(yīng),在JSON區(qū)多包含一份獲取該幾何數(shù)據(jù)的描述信息。另外,輕量化的結(jié)果因模型而異,對(duì)于富含相同構(gòu)件的BIM模型,輕量化的結(jié)果較好。其中恒大場(chǎng)布模型包含214個(gè)Mesh,原因在于該模型大部分所用的是自定義的族,細(xì)分的粒度不如Revit內(nèi)建的族,例如,在塔吊的模型解析過程中,幾何數(shù)據(jù)作為一個(gè)整體被提取。

表1 GLB中Mesh數(shù)量統(tǒng)計(jì)

同時(shí),將住宅小區(qū)模型與恒大場(chǎng)布模型的輕量化并經(jīng)過Draco壓縮處理的結(jié)果上傳至阿里云服務(wù)器,輕量化未經(jīng)過壓縮處理的結(jié)果上傳至Cesium Ion平臺(tái)進(jìn)行測(cè)試,如圖12所示,左側(cè)為Three.js渲染結(jié)果,右側(cè)為Cesium的渲染結(jié)果。其中,渲染被Draco壓縮的GLB模型之前需要解碼,解碼時(shí)間內(nèi)會(huì)阻塞前端頁面響應(yīng),HTML5引入了WebWorker工作線程可以很好地解決此問題,并且Three.js內(nèi)置了子線程解碼模型并將解碼后的數(shù)據(jù)發(fā)送給主線程進(jìn)行渲染的功能。

圖12 模型在Three.js與Cesium引擎中的渲染效果

在對(duì)屬性信息提取的工作中,基于RvtVa3c對(duì)構(gòu)件工程信息提取工作的基礎(chǔ)上,進(jìn)一步提取材料屬性、物理屬性,并將屬性信息以JSON格式寫入info文件中,屬性ID與GLB中node.name一一對(duì)應(yīng),教學(xué)樓模型的屬性信息如圖13所示。

對(duì)數(shù)據(jù)損失進(jìn)行評(píng)估時(shí),發(fā)現(xiàn)住宅小區(qū)模型構(gòu)件總數(shù)為7 489個(gè),而渲染結(jié)果顯示7 480個(gè),損失9個(gè)構(gòu)件,如圖14所示,在轉(zhuǎn)換過程中會(huì)有較小的數(shù)據(jù)損失。

圖14 住宅小區(qū)模型數(shù)據(jù)轉(zhuǎn)換損失評(píng)估

5 結(jié) 語

BIM模型作為建筑參數(shù)化的載體,具有空間不均勻、高度復(fù)雜、語義豐富和數(shù)據(jù)量大等特性。將BIM與互聯(lián)網(wǎng)技術(shù)相結(jié)合,需要從數(shù)據(jù)結(jié)構(gòu)與算法、數(shù)據(jù)傳輸以及計(jì)算機(jī)圖形學(xué)等方向做相應(yīng)的研究。但是BIM有眾多的數(shù)據(jù)源,增加了數(shù)據(jù)使用成本,給數(shù)據(jù)融合造成了一定的難度。而IFC作為BIM的數(shù)據(jù)標(biāo)準(zhǔn),借助其進(jìn)行數(shù)據(jù)交換,很大程度上受限于各個(gè)軟件平臺(tái)對(duì)標(biāo)準(zhǔn)的實(shí)現(xiàn)程度以及模型輕量化帶來的難度。本文借助Revit API實(shí)現(xiàn)BIM輕量化,仍有很大的不足：(1) 該轉(zhuǎn)換方法僅僅適用于Revit平臺(tái),不具有普適性。(2) 數(shù)據(jù)在轉(zhuǎn)換過程中仍有少量幾何數(shù)據(jù)損失,需要進(jìn)一步完善。(3) 需對(duì)數(shù)據(jù)的加載以及渲染策略進(jìn)行優(yōu)化。因此這些不足也是以后需要研究方向。