(南京林業(yè)大學 土木工程學院，南京 210037)

引言

在新冠疫情影響下，北京市住房和城鄉(xiāng)建設委員會于2020年5月20日發(fā)布了第125號文《關于進一步做好常態(tài)化疫情防控期間房地產(chǎn)開發(fā)項目售樓場所管理的通知》，其中第九條指出要加大科技應用，鼓勵開發(fā)企業(yè)充分利用電話、互聯(lián)網(wǎng)、虛擬現(xiàn)實技術(shù)(VR)、直播售樓等非直接接觸方式，開展線上樓盤展示、宣傳等營銷活動。建筑信息模型(Building Information Modeling，BIM)是建筑領域的新概念，具有可視化、協(xié)調(diào)性、模擬性和優(yōu)化性的特點[1]。且BIM精細程度高，特征參數(shù)化，語義信息豐富，BIM已經(jīng)成為城市精細化、智慧化、標準化管理的重要數(shù)據(jù)源[2]?？梢夿IM的出現(xiàn)附著了建筑物的整體信息，可以提供單棟建筑的精確信息模型。喬國臻和張茹涵[3]等運用無人機傾斜攝影技術(shù)構(gòu)建實景三維模型，再使用BIM+GIS數(shù)據(jù)集成技術(shù)實現(xiàn)BIM模型和真實三維模型的結(jié)合，搭建了一套帶有GPS車輛實時監(jiān)控與調(diào)度和報警點自動定位等功能的智慧警務系統(tǒng)。楊田[4]將fbx格式的BIM模型導入支持OSGB格式的Skyline軟件中實現(xiàn)BIM與傾斜攝影模型的融合，并以3DML格式保存，再利用Spatial Framework Services進行發(fā)布，提供給不同領域、不同的部門和不同的設備使用。李明濤[5]分析了IFC和CityGML模型文件架構(gòu)，研究了這兩種數(shù)據(jù)模型的編碼規(guī)則。將skp格式的SketchUP模型轉(zhuǎn)換為支持IFC標準的3ds格式模型，并在FME開發(fā)平臺上，把3ds格式模型分解與CityGML建立語義映射。實現(xiàn)了把建筑空間信息傳遞到其周圍地理環(huán)境中，并能查詢和分析三維GIS建筑室內(nèi)的信息。

建筑信息模型具有海量數(shù)據(jù)，在加載和渲染模型時對電腦本身的配置要求很高，而且對于普通客戶無法實際地去操作這些大型軟件。然而5G時代的到來在促進通信行業(yè)發(fā)展的同時，也為實現(xiàn)三維模型在B/S架構(gòu)下展示提供了技術(shù)支持。所以本文采用將BIM通用標準轉(zhuǎn)換為能夠流式傳輸而且可以使建筑物數(shù)據(jù)集、BIM模型、點云和傾斜攝影等大模型比較流暢地在Web端進行瀏覽展示的3D Tiles數(shù)據(jù)格式，以提高在Web端加載BIM模型的速度，實現(xiàn)跨平臺展示三維模型，并且為開發(fā)企業(yè)提供新的營銷方案。

1 標準解析

1.1 IFC標準

IFC(Industry Foundation Classes，工業(yè)基礎類)標準是buildingSMART提出的開放數(shù)據(jù)標準，現(xiàn)已成為國際標準(ISO16739)。IFC標準被廣泛地應用在軟件兼容性的研究[6]，數(shù)據(jù)交換標準研究[7]和關系數(shù)據(jù)庫的研究[8]。IFC標準的技術(shù)架構(gòu)分為四個層次，如圖1所示，由上至下分別為：領域?qū)?Domain Layer)、共享層(Interoperability Layer)、核心層(Core Layer)和資源層(Resource Layer)[9]。每層中都包含一系列的信息描述模塊，并且遵守一個規(guī)則：每個層次只能引用同層次和下層次的信息資源，而不能引用上層次的資源，當上層資源發(fā)生變動時，下層是不會受到影響的。

圖1 IFC4的基本架構(gòu)Fig.1 Schema of IFC4

IFC標準資源層(IFC—Resource Layer)：是IFC體系架構(gòu)中的最底層也是整個體系的基本層，能為其他層所引用； IFC標準核心層(IFC—Core Layer)：是IFC體系架構(gòu)中的第二層，能為共享層和領域?qū)铀茫?IFC標準共享層(IFC—Interoperability Layer)：是IFC體系架構(gòu)中的第三層，該層主要是服務于領域?qū)?，使得領域?qū)有畔⒖梢赃M行交互； IFC標準領域?qū)?IFC—Domain Layer)：是IFC體系架構(gòu)中的最頂層，該層主要定義了面向各個專業(yè)領域的實體類型。每一層使用或是引用定義在核心和獨立資源層上的信息模型都是獨立的。其主要作用是深入到各個應用的領域內(nèi)部，形成專題信息，比如暖通領域(HVAC Domain)、工程管理領域(Construction Management Domain)等，而且還可以根據(jù)實際需要不斷進行擴展。

1.2 3D Tiles標準解析

3D Tiles數(shù)據(jù)規(guī)范標準是由Cesium團隊AGI公司在2016年推出的，該數(shù)據(jù)規(guī)范標準是在glTF基礎上提供了LOD能力。由于該數(shù)據(jù)規(guī)范標準具有流式傳輸?shù)膶傩运?D Tiles可以使建筑物數(shù)據(jù)集、BIM模型、點云和傾斜攝影等大模型比較流暢的在Web端進行瀏覽展示。同時它還定義了一個分層數(shù)據(jù)結(jié)構(gòu)和一組瓦片格式，用于提供可渲染內(nèi)容。在3D Tiles中，切片數(shù)據(jù)集是在空間數(shù)據(jù)結(jié)構(gòu)(樹)中組織的一組圖塊。一個瓦片數(shù)據(jù)集由至少一個瓦片數(shù)據(jù)集JSON文件描述，該文件包含切片集元數(shù)據(jù)和切片對象樹[10]。

3D Tiles中的Tile，即瓦片，它包含用于確定是否渲染瓦片的元數(shù)據(jù)和對渲染內(nèi)容的引用以及所有子瓦片的數(shù)組，用于組織3D Tiles的空間結(jié)構(gòu)[11，12]，它的數(shù)據(jù)結(jié)構(gòu)可見圖2。

2 BIM模型數(shù)據(jù)格式轉(zhuǎn)換

圖2 瓦片的數(shù)據(jù)結(jié)構(gòu)Fig.2 Data structure of tileset

通過閱讀相關文獻可發(fā)現(xiàn)目前在BIM模式數(shù)據(jù)轉(zhuǎn)換的過程中幾何信息和屬性信息丟失、語義信息歧義等是較為突出的問題[13-15]。并且目前還沒有方法能夠?qū)FC直接轉(zhuǎn)換成3D Tiles。因此在本文中，首先將IFC標準文件導出為數(shù)據(jù)源，分析BIM文件和3D Tiles文件之間的映射關系。然后，將拆分后的IFC模型進行重組，以便生成包含屬性信息的JavaScript Object Notation(JSON)文件，和用來存儲建筑構(gòu)件幾何信息的建筑構(gòu)件IFC模型。根據(jù)分析得到BIM文件與3D Tiles文件之間的映射關系可以將IFC模型中包含的屬性信息傳遞給3D Tiles。同時，在轉(zhuǎn)換的過程中完成了坐標轉(zhuǎn)換和數(shù)據(jù)映射以確保BIM模型能快速地在Cesium框架中進行渲染交互。

2.1 BIMServer解析BIM模型數(shù)據(jù)

IFC模型中必不可少的兩種信息分別是建筑構(gòu)件的幾何信息和用來描述建筑構(gòu)件的屬性信息。通常在IFC標準中幾何信息表達方法分為三種類型：邊界描述(B-rep)、掃描體和構(gòu)造實體幾何方法(CSG)[14，16]。IFC模型中的屬性信息包含大量的結(jié)構(gòu)細節(jié)，包括對600多個建筑實體的定義和300多個建筑類型的定義，以及各個建筑構(gòu)件(例如IfcSite、IfcBuilding和IfcBuildingStorey)之間的語義連接[17]。

為了保留BIM模型中大量的幾何信息和屬性信息，必須按照規(guī)則對IFC文件進行分割處理，以便保留建筑構(gòu)件模型和相關的屬性信息。本文采用GitHub上的開源工具BIMserver對IFC文件如圖3所示進行分割。BIMserver是基于BIM的服務器管理平臺，將IFC文件上傳到BIMserver，并通過IFCEngine拆分模型，以便獲得構(gòu)件模型(IFC文件)和與構(gòu)件相關的屬性文件(JSON文件)。

圖3 分割IFC文件Fig.3 Split IFC file

在BIMserver提取IFC文件的過程中，將根據(jù)3D Tiles模型的要求編輯IFC文件并再次處理其幾何信息和相關的屬性信息以便篩選出所需要的數(shù)據(jù)，如果確定是需要的數(shù)據(jù)則輸出其幾何信息和與之相關聯(lián)的屬性信息。最終將獲取到的局部坐標系下構(gòu)件的幾何位置信息，幾何表示方式和材質(zhì)信息存儲到JSON文件中。

2.2 分析IFC轉(zhuǎn)換成OBJ

(1)OBJ文件的幾何和材料定義

對象文件(.obj或OBJ)是一種文本文件格式，用于定義對象的幾何和其他屬性。OBJ格式文件由頂點坐標(vertex coordinate)，法線坐標(normal coordinate)、紋理坐標(texture coordinate)和闡明三者之間連接性的文本文件組成，OBJ格式文件示例如圖4所示。根據(jù)OBJ文件的示例可見，每行的第一個字符指定命令的類型，后跟任意參數(shù)。該文件由工具讀取并從上到下進行解析。OBJ文件中包含的最常見的關鍵詞是幾何頂點，紋理坐標，法線頂點和多邊形面。頂點命令v(在OBJ文件的第3行中標記)指定了一個頂點，后面跟三個表示該點坐標(x，y，z)的浮點值。OBJ文件的第27行中標記的頂點法線命令指定一個法線向量，后跟三個浮點值，它們表示法線的坐標(x，y，z)。頂點紋理命令vt的特征在于它是0到1之間的浮點值，它定義了紋理的映射方式，而面命令f指是由列出的頂點組成的多邊形。如示例OBJ文件中的第36行所示，多邊形面命令f是由頂點v，紋理vt和法線vn組成，它們表示一個三角形面元素，而OBJ文件正是在IFC標準下從建筑構(gòu)件模型轉(zhuǎn)換而來的。

圖4 OBJ文件的示例Fig.4 An example of OBJ file

(2)IFC到OBJ的轉(zhuǎn)換

圖5 IFC轉(zhuǎn)換成OBJ的流程Fig.5 IFC-to-OBJ process

IFC是基于Express語言的開放文件格式標準[18]，用于描述BIM模型中模擬的建筑物。Express旨在促進屬于已定義的類的規(guī)范，和與類相關的屬性(顏色、大小、形狀和材料等)。IFC概念是由IfcElement實體在Express語言中經(jīng)過相關的拓撲關系組織構(gòu)建起的。且IFC概念架構(gòu)通過IfcLocalPlacement、IfcElementQuantity和IfcPropertySet關系明確了與IFC模型元素之間的區(qū)別。與IfcElement相關的屬性集由IfcPropertySet定義，與IfcElement相關的數(shù)量由IfcElementQuantity定義，與IfcElement相關的位置信息由IfcLocalPlacement定義。

本研究將從IfcLocalPlacement，IfcElementQuantity和IfcProoertySet關系中提取的屬性值與OBJ文件的幾何材料屬性進行關聯(lián)。因此IFC-Express實體可以轉(zhuǎn)換為OBJ類。本文提出的轉(zhuǎn)換方法是逐行從IfcElement實體中提取局部屬性和其繼承的屬性。但是由于Express實體沒有使用全局定義對IFC屬性進行描述[19]，因此在Express實體轉(zhuǎn)換為OBJ類時需要將局部坐標轉(zhuǎn)換為全局坐標。同時，還需要提取相應的材料信息以便完成后續(xù)的紋理轉(zhuǎn)換。本文通過使用OBJ材料模板庫(Material Template Library，MTL)的伴隨文件(.mtl)來提取材料信息，其可以通過IFC數(shù)據(jù)模型中的IfcRelAssociatesMaterial和IfcRelDefinesByProperties關系與分配到的材料信息進行關聯(lián)。這樣我們可以根據(jù)全局坐標系中IFC模型的幾何信息創(chuàng)建一個頂點、紋理和法線坐標數(shù)組，構(gòu)建完整的三角形面，同時生成一個新的OBJ文件。

如圖5所示，將IFC轉(zhuǎn)換為OBJ的具體過程可以分為以下三個步驟。第一步分析并提取三角形面的頂點坐標，該三角形面依賴于多個IfcLocalPlacemet對象的嵌入式應用，以允許將IfcElement對象通過上文所述的IfcLocalPlacement放置在另一個IfcElement對象位置的全局坐標系內(nèi)。第二步是分析和提取法線和紋理浮點值，最后一步是分析和提取材料信息。本文采用Github上提供的一種IFC到OBJ轉(zhuǎn)換的開源庫IfcOpenShell，該框架可將IFC實體攜帶的所有隱式幾何轉(zhuǎn)換為任何軟件都可以理解的顯示幾何。IfcOpenShelll支持在C/C++繼承開發(fā)環(huán)境(C-free5)中進行編譯。

2.3 分析OBJ轉(zhuǎn)換成glTF

(1)glTF的基礎結(jié)構(gòu)

現(xiàn)有的文件格式不適用于3D模型的快速傳輸：有些不包含任何場景信息，而僅包含幾何數(shù)據(jù)； 而其他應用程序希望數(shù)據(jù)能在應用程序之間交換，但是它們的主要目標是保留與3D場景有關的信息，從而導致文件數(shù)據(jù)量很大，很復雜并且很難解析。glTF文件格式旨在提高3D模型的網(wǎng)絡傳輸效率，因此glTF使用JSON來描述場景結(jié)構(gòu)，該結(jié)構(gòu)非常緊湊并且可以輕松解析。并且glTF文件將3D模型的數(shù)據(jù)以可以被普通圖形API直接使用的形式存儲，不需要解碼或者預處理3D數(shù)據(jù)，其基礎結(jié)構(gòu)如圖6所示。Scene是整個場景的入口點，由node圖(樹)結(jié)構(gòu)組成； node是場景層級中的一個節(jié)點，可以包含位置變換，也可以有子節(jié)點； 同時，node通過指向mesh、camera、skin來描述node的形變； mesh描述在場景中出現(xiàn)的幾何物體，并通過accessor(訪問器)來訪問其真實的幾何數(shù)據(jù)，并通過material(材質(zhì))來確定渲染外觀； texture定義如何將紋理映射到模型上。

圖6 glTF基礎結(jié)構(gòu)Fig.6 glTF basic structure

(2)OBJ到glTF的轉(zhuǎn)換

通過前面BIMserver拆分IFC文件和IFC轉(zhuǎn)OBJ這兩步驟便可獲得模型拆分后的子模塊，此時便可將相應的子模塊和其相關的材料數(shù)據(jù)寫入進glTF文件中。并且在轉(zhuǎn)換的過程中要確定頂點坐標和紋理坐標之間的對應關系，這樣才能將紋理信息準確映射到3D模型表面。由于子模塊之間的不連續(xù)性，導致頂點坐標的ID值也需要寫入glTF文件中進行區(qū)分，以便轉(zhuǎn)換過程中快速調(diào)用頂點信息。在glTF文件中，建筑物由存儲在三角形面中的網(wǎng)格組成，且相同的建筑物組件具有相同的標識符。因此在最終的glTF文件中不僅包含頂點位置、頂點法向量和頂點紋理坐標而且包含網(wǎng)格標識符。

2.4 glTF轉(zhuǎn)換成b3dm

glTF作為文件主體的一部分，其與文件頭、功能表和批處理表一起轉(zhuǎn)換為二進制glTF(glb)，以形成b3dm切片數(shù)據(jù)文件。批處理表是用來存儲用戶定義與模型相關的數(shù)據(jù)，該數(shù)據(jù)用于與用戶進行交互，但不會影響模型的呈現(xiàn)方式，例如填充UI或發(fā)出代表性專業(yè)REST API請求等。

盡管在實際的建筑項目中建筑構(gòu)件的數(shù)量非常龐大，但是在每層相同的位置上其墻、門和窗戶都是相同的，并且其中很大一部分是相同構(gòu)件的簡單重復。因此在b3dm的文件頭中，為每個構(gòu)件分配了一個batch_id，且相同id值的頂點具有相同的組成構(gòu)件。因此存儲在b3dm文件主體的批處理表中的屬性信息也可被稱為batch_id，其數(shù)據(jù)結(jié)構(gòu)如圖7所示。

圖7 b3dm數(shù)據(jù)結(jié)構(gòu)Fig.7 b3dm data structure

由圖2瓦片的數(shù)據(jù)結(jié)構(gòu)可知b3dm和瓦片數(shù)據(jù)一起組成了3D Tiles文件，且該瓦片數(shù)據(jù)包含了用于組織3D Tiles空間數(shù)據(jù)的元數(shù)據(jù)。

3 Cesium解析模型b3dm文件

由于IFC模型采用的是局部坐標系，而3D Tiles模型采用的是全局坐標系，且在Cesium框架中使用的3D數(shù)字地球采用的是全球笛卡爾坐標系，其地理中心是坐標的原點[20]。因此在加載模型時，采用的坐標系是局部笛卡爾坐標系。所以Cesium需要對轉(zhuǎn)換后的模型進行坐標系轉(zhuǎn)換處理，如圖8所示，其中立方體表示具有局部坐標(Xm，Ym，Zm)的建筑構(gòu)件。當建筑構(gòu)件從局部坐標轉(zhuǎn)換為全局坐標時，建筑構(gòu)件的相對位置也會發(fā)生變化。建筑構(gòu)件會分別圍繞X軸，Y軸，Z軸旋轉(zhuǎn)，兩個坐標系之間的過渡矩陣計算如下：假設在3D Tiles的全局坐標系中，IFC模型在局部坐標系下的原點(x1，y1，z1)； 局部坐標系的Z軸垂直于地面； Y軸指向正北； 坐標軸對應得自旋轉(zhuǎn)矩陣為Rx，Ry，Rz；θx，θy，θz是旋轉(zhuǎn)矢量分別和X軸，Y軸和Z軸之間的夾角。

圖8 坐標轉(zhuǎn)換Fig.8 Coordinate transformation

(1)

(2)

(3)

(4)

基于上述的坐標系轉(zhuǎn)換矩陣，可將IFC模型從局部坐標過渡到全局坐標，且能夠在Cesium的全球笛卡爾坐標系下準確加載和渲染。

4 案例分析

為了驗證上述IFC到3D Tiles格式轉(zhuǎn)換方法的可行性，本文選取某BIM模型進行測試。該模型信息：3層教學樓，大小為12MB； 硬件環(huán)境：Intel(R)Core(TM)i5-9400F CPU@2.90GHz，內(nèi)存為16.0GB，顯卡為NVIDIA GeForce GTX 1660 SUPER； 軟件環(huán)境：Microsoft Edge瀏覽器，Tomcat服務器。

4.1 模型數(shù)據(jù)量解析

(1)運用Revit軟件將教學樓模型以IFC格式導出，并將導出的文件上傳至BIMserver服務器，使其拆分成保存幾何信息的IFC文件和保存屬性信息的JSON文件。使用Python語言結(jié)合GitHub上的開源軟件ifcopenshell解析IFC文件，計算IFC模型中包含的建筑構(gòu)件。此步驟所采用的是Python3.5和ifcOpenShell-python for python 3.5。其相關代碼與結(jié)果可見下圖9和圖10，可見該教學樓IFC模型中包含了IfcSlab、IfcDoor、IfcBeam和IfcWallStanardCase等構(gòu)件。

圖9 解析IFC模型的代碼Fig.9 Code to parse the IFC model

圖10 部分IFC模型構(gòu)件Fig.10 Part of IFC model components

(2)經(jīng)過上述IFC到OBJ、OBJ到glTF以及glTF到3D Tiles的轉(zhuǎn)換后，產(chǎn)生如圖11所示的3D Tiles格式的瓦片數(shù)據(jù)集，其中包含存儲幾何信息的b3dm文件和存儲屬性信息的json文件。最終將該3D Tiles瓦片數(shù)據(jù)集導入至開源的Cesium平臺中，實現(xiàn)在web端加載BIM模型的功能。

圖11 3D Tiles瓦片集Fig.11 3D Tiles tile set

4.2 加載幀率分析

3D Tiles是在glTF格式的基礎上增加了HLOD功能，而glTF是目前公認的適用于網(wǎng)絡傳輸三維模型的數(shù)據(jù)格式。因此本研究將該教學樓模型在轉(zhuǎn)換成glTF格式時導入至WebGL中加載，并將最終生成的3D Tiles格式的模型導入至Cesium中加載。分別檢測記錄兩次加載模型時的幀率，幀率直接反應系統(tǒng)的流暢程度，幀率越高，加載速度越快，則用戶的體驗感越好。其加載模型時的幀率對比如圖12所示，從圖中可見加載3D Tiles模型時的幀率要高于加載glTF模型時的幀率，且加載3D Tiles模型的用時短于加載glTF模型。因此采用3D Tiles數(shù)據(jù)標準加載模型既可以減少計算機數(shù)據(jù)處理量也可以提高Web端加載模型時的速度。

圖12 glTF與3D Tiles加載幀率對比Fig.12 Comparison of glTF and 3D Tiles loading frame rate

5 結(jié)論

本文基于對IFC標準和3D Tiles標準的分析，分三個步驟準確地將IFC模型中的幾何信息和屬性信息映射到3D Tiles模型中。并解析了Cesium中使用的全球笛卡爾坐標系和IFC模型采用的局部坐標系之間的區(qū)別，通過轉(zhuǎn)換矩陣實現(xiàn)了BIM模型在Cesium平臺的精確加載，實現(xiàn)了在Web端快速加載BIM模型。本文不僅降低了對計算機的負擔，而且提高了模型加載速度，為開發(fā)企業(yè)提供了新的營銷方案。