Design and implementation of bridge information management system based on BIM

2.1 System analysis

BIMS aims to use informatization and digitization technology to realize the visual display of bridge 3D model and the collaborative management of the bridge information. Traditional 3D model visualization is designed and developed based on the Client/Server(C/S), which needs professional applications. Moreover, this strong specialization limits the application of BIMS. The BIMS model usually consumes too many computer resources due to its large volume, and the rendering speed is unsatisfactory [14]. In bridge maintenance, the construction personnel needs to understand the real-time environmental data of the bridge to analyze the bridge structure load and propose a reasonable bridge maintenance scheme. According to the above demand analysis, the system design scheme based on B/S is determined, which has the three characteristics listed below:

2.1.1 Virtual visualization

Bridge model virtual visualization is the key of the BIMS. Virtual visualization mainly includes 3D model visualization and monitoring of data visualization. This paper employs WebGL technology and Three.js 2 as the overall framework. It proposes a 3D model rendering method based on the B/S to realize 3D model rendering and redrawing on the browser. Data visualization is used to display the information about the bridge’s components and the node monitoring, including historical data query and data dynamic curve display. Maintenance personnel can develop a reliable bridge maintenance program by checking and analyzing the data. The system communicates with the information collection equipment through the server, and the collected bridge information is stored on the server. The node monitoring information is displayed on the browser by calling the interface to realize the visual management of the data.

2.2 System function module design

According to the above analysis, the bridge information management system mainly includes four modules:

3.1 Data Acquisition

Bridge monitoring information is mainly collected by information monitoring nodes. The information monitoring node is built with IoT technology as the core. Through the analysis of bridge collapse accidents, four digital sensors of temperature, humidity, wind speed and pressure are selected as information acquisition equipment. After the information is collected, it is transmitted to Microprogrammed Control Unit(MCU) for processing, and then uploaded to the cloud server through the Lora gateway, which is associated with the sensor in the 3D model to realize digital-model fusion. Figure 1 shows the architecture of the data acquisition.

OPEN IN VIEWER

Fig. 1

Data acquisition.

BIMS aims to provide an open, cross-platform BIM online visualization scheme. However, for large bridge structures, there are many static attribute information in the process of building a 3D model, resulting in an excessively large final volume of the 3D model [15]. The large volume model file consumes more computer resources and increases the rendering time of the model. Therefore, the model file must be lightened. Figure 2 shows the lightweight model scheme divided into two steps: geometry file extraction and model compression.

OPEN IN VIEWER

Fig. 2

Model lightweight programme.

IFC data is an international standard for BIM system integration, data exchange and sharing. It can be used to describe the interaction of building objects and components [16, 17]. The origin of IFC is to integrate construction engineering data into an information model that includes all aspects of the construction industry, such as geometry, topology, attributes, cost, materials, etc. It makes the simple data exchanged more complicated [18]. Simultaneously, in 3D model rendering, a large number of building parameters and attribute information in IFC are not applied, but they take up a lot of storage space, slowing down the rendering speed of the model. Therefore, to build a Web-BIM system, the required data must be extracted from IFC files to reduce the model volume. Figure 3 shows the scheme of model geometry information extraction.

OPEN IN VIEWER

Fig. 3

Data extraction of the 3D geometric model.

OPEN IN VIEWER

Fig. 4

Edgebreaker Traverse access.

The first step of model lightweight is model data extraction. IFC contains the elements from each class in the BIM model, such as color, material, geometry, size, etc. The number and type of elements in the bridge’s BIM model are different and the geometric structures of the original model need to be preserved after data extraction. To reduce the error of model information extraction, it is necessary to analyze the structures of the IFC file. Extract and encapsulate the class corresponding to the element information of the geometric model. The geometric storage of model elements is defined by the IfcLocalPlacement interface; The quantity storage of model elements is defined by the IfcElementQuantity interface; The attribute storage of model elements is defined by the IfcPropertySet interface. The model’s detailed state in the 3D scene is described by texture mapping. Texture mapping can be divided into color texture mapping and geometric texture mapping. Texture coordinates are essentially the mapping between texture pixels and screen space pixels, which can be understood as the transformation of the space coordinate system. Each vertex is marked with two coordinates U and V, representing the horizontal and the vertical axes, respectively. The UV value represents the percentage position of the vertex in 3D coordinates. The model’s attribute value can be extracted from Ifcplocalplacement, Ifcpropertyset, and Ifcelementquantity, associated with the definition in obj file to realize the encapsulation of IFC to Obj format.

Reducing the volume of the model can significantly improve its rendering speed. The Obj file is a standard 3D model file format that supports conversion between different formats. Since the Obj file only contains the geometric information of the 3D models, it has a small volume suitable for this system. The model volume has decreased after exporting the bridge geometry model data from the IFC file and encapsulating it into Obj format. To further reduce the volume of the model, the model must be processed by the compression algorithm.

Draco is an open-source 3D model compression algorithm frequently used to compress and decompress triangular geometric meshes and point cloud data to improve the storage and transmission rate of 3D graphics [19]. Draco combines the Edgebreaker algorithm and the parallelogram difference method. It compresses the surface information of the model through the Edgebreaker algorithm to generate a Corner Table data format, which represents the encoding of the connectivity association between a triangular mesh and a boundary vertex. The attribute information of the vertices is then compressed using the parallelogram difference method, encoded, and stored separately. The Draco algorithm supports two compression methods: lossy and lossless. To protect the integrity of the 3D model, this paper uses a lossless compression method to further lighten the model file.

The Edgebreaker algorithm is the core of the Draco algorithm. Edgebreaker algorithm traverses the triangular mesh of the model in the order of spiral (depth-first) triangle span tree. When it traverses one mesh, it outputs a topological relation descriptor of the mesh and boundary clers including the polygon in the encoded part. Clers relational characters are composed of sets {C, L, E, R, S} and different characters represent different meanings. For example, C indicates the traversal vertex is not on the boundary topology. The L and R indicate the traversed vertex is on the boundary, in addition to the current edge, there is a side in different directions on the boundary of the current triangle. S means the figure can be divided into two parts; E means all three sides of the triangle are on the boundary.

The coding process of obj format file using Draco algorithm is shown in Fig. 5. Firstly, read the model’s information from the folder and choose the compression encoding method according to the model’s type. Then encode and store the model’s mesh information, and compress the stored information through the Edgebreaker algorithm, including the model’s topological relations, vertex attribute information, etc. Finally, the compressed information is stored in the Corner Table to obtain the lightweight model file.

OPEN IN VIEWER

Fig. 5

Obj coding flow chart in file format.

Figure 6 shows the visual design scheme in the system.

OPEN IN VIEWER

Fig. 6

The development process of visualization function.

WebGL technology promotes the development of 3D model visualization technology. Three.js is an open-source framework of WebGL, a lightweight graphics rendering engine that runs on the Web. It simplifies the bottom API of WebGL and covers up many troubles of 3D model rendering. It can realize online visualization of the 3D model via browser rendering engine [20]. The lightweight model is uploaded to the server as a call, and the JavaScript and WebGL are programmed to realize the rendering of the bridge 3D model in the browser. Figure 7 shows the rendering steps of the 3D model on the browser. There are four steps in the rendering process.

OPEN IN VIEWER

Fig. 7

Rendering steps.

The rendering process begins when the user’s requested HTML text reaches the rendering engine via the browser’s network layer. After the model has been lightweight, its volume is reduced, and its rendering speed is accelerated.

The coordinate system in WebGL is different from the world coordinate system of other software [21]. Therefore, the model needs to be transformed when it is loaded in the browsers. The coordinate transformation of the model is achieved by multiplying the transformation matrix and the point coordinate vectors in the 3D model. The position of the points in the 3D space needs to be represented by homogeneous coordinates. That is, add a quantity w after x, y, z. Assuming that the point matrix is P, the transformation matrix is M, the transformed point matrix is Q. The value of w is 1, and the formula of describing the point by homogeneous coordinates is as follows [22]: P = ( Px , Py , Pz , 1 ) T(1)

The basic transformation matrix M is as follows: M = [ m 11 m 12 m 13 m 14 m 21 m 22 m 23 m 24 m 31 m 32 m 33 m 34 0 0 0 1 ](2)

The calculation formula of point basic transformation is as follows: [ Qx Qy Qz 1 ] = [ m 11 m 12 m 13 m 14 m 21 m 22 m 23 m 24 m 31 m 32 m 33 m 34 0 0 0 1 ] [ Px Py Pz 1 ](3)

Different matrix values lead to different transformation methods. The matrix M for translation, scaling and rotation are as follow: M = [ 1 0 0 mx 0 1 0 my 0 0 1 mz 0 0 0 1 ](4) M = [ s x 0 0 0 0 s y 0 0 0 0 s z 0 0 0 0 1 ](5)

M = [ cos θ + ( 1 - cos θ ) u x 2 ( 1 - cos θ ) u y u x - sin θ u z ( 1 - cos θ ) u z u x + sin θ u y 0 ( 1 - cos θ ) u x u y + sin θ u z cos θ + ( 1 - cos θ ) u y 2 ( 1 - cos θ ) u z u y - sin θ u x 0 ( 1 - cos θ ) u x u z - sin θ u y ( 1 - cos θ ) u y u z + sin θ u x cos θ + ( 1 - cos θ ) u z 2 0 0 0 0 1 ](6)

In practice, the above transformation formula is used to perform translation, rotation, and zoom operations on the model to realize the model processing based on the actual demand of the model deviation.

An interactive design is added to the Web-BIM system to improve user experience. Interaction design mainly includes three functions: roaming, components information display, and monitoring nodes information display. The roaming mode is designed and implemented by the WebGL control Orbitcontrols.js, which mainly includes the first-person roaming mode and the trackball roaming mode. The parameter information of the component is stored in the database and bound to the components through the nodes ID. When a user clicks on a component in the bridge 3D model, its information will be displayed on the Web front-end. The information from detection nodes is stored in the data table, and Ajax technology is used to query and update data in real-time.

3.7 Background service

The background service is responsible for Web service support. The system background applied Java as the development language, integrated the SpringBoot and MyBatis framework, encapsulated the query service as the microservice, applied the Model-View-Controller(MVC) design pattern, put the complex processing logic in the controller, and view refers to the front-end interface. The framework decoupled the front and back programs, allowing for greater code scalability. Background service module in the system performed the following functions:

Real-time data acquisition: collecting real-time environmental data from IoT nodes and storing it in the Mysql database.

The system uses MyBatis as a data persistence layer, integrated Java Database Connectivity(JDBC) code development, and manually setting parameters and obtained result sets, optimizing development mode and reducing the difficulty of development and later maintenance. The interface and Java POJOs have mapped database records, and the database configuration is integrated into Extensible Markup Language(XML) files. For security and data integrity, the background service in the system interacts with the terminal node via the TCP/IP communication protocol.

4.1 Model compression experiment

Draco algorithm is different from other model topology transformation algorithms. It does not change the topological structure of the model but reduces its volume by encoding the triangular patches. The model volume has been significantly reduced by applying the Draco algorithm to compress the obj format 3D model. To verify the compression effect, this paper chose five groups of different volumes of obj 3D model files and run the compiled code. The volumes of the five groups of obj 3D models are 64kb, 104kb, 2247kb, 12658kb, and 622108kb. The running environment is windows 8.1 operating system, CPU i5-5200u, NVIDIA GeForce 840M, and 4G Memory. The compression effect is evaluated based on the compression rate value. The method for calculating compression rate is as follows: C R = C A C B(7) where C _R is the compression rate, C _A is the volume of the after compressed model, C _B is the volume of the before compressed model, C _T is the compression time. Table 1 shows the experimental results.

From the analysis in Table 1, it can be concluded that:

For models 2, 3, 4, and 5, the compression rate increases with the increase of the model’s volume;

There are three commonly used methods for 3D model lightweight: Geometric vertex deletion, geometric edge folding [23]. However, these methods will change the topology of the model and affect the model’s integrity. In this paper, the obj model with a volume of 26009kb is lightweight through the “vertex deletion algorithm,” “edge folding algorithm,” “vertex reuse+edge folding algorithm,” and “Draco algorithm” Table 2 shows the experimental results:

According to Table 2, it can draw a clear conclusion that:

Among the four algorithms, the compression effect of the algorithm used in this paper is the most obvious.

Theoretically, as the volume of the model shrinks, the rendering time is also decreased. To verify whether the rendering time of the 3D model has been reduced, three groups of Obj 3D model files with different volumes in section 4.1 are selected and combined with Three.js to run the rendering experiment in the browser before and after the lightweight model treatment. The experiment runs in the same environment as section 4.1, with Chrome browser used for model rendering and JavaScript as the development language. The rendering time of the 3D model before and after compression is calculated during the rendering process. The rendering acceleration effect is validated by the speedup ratio. The formula for calculating the speedup ratio is as follows: S r = C b C a(8) where S _r is the speedup ratio, C _b is the rendering time before model compression, C _a is the rendering time after model compression. Table 3 shows the experimental results of the three model groups.

After the 3D model is compressed, the amount of data and computation needed for rendering have reduced, and the rendering speed has increased. It can be seen from Table 2 the rendering time of the three model groups after compression has been reduced to less than 15% of that before compression, and the rendering speed of the after compression model has been greatly improved.