A lightweight 3D visualization engine system based on GIS and BIM

Abstract

This invention relates to the field of computer software technology for BIM 3D models, specifically a lightweight 3D visualization engine system based on GIS and BIM, comprising: lightweight engine data parsing and lightweight engine model rendering. This invention optimizes the data structure of 3D models during data storage by eliminating unnecessary data nodes, reducing the size of data files, and saving storage space for 3D model files. Due to the reduced size of 3D model files, data transmission costs are significantly lowered, reducing waste of system resources. It also improves the rendering capacity of 3D models in browsers, enabling web applications to load large scene models, reducing browser crashes caused by loading large scene models, and making the system more stable. The engine provides standard API interfaces, allowing for code-level calls and empowering BIM model-related business for information deepening.

Description

Technical Field

[0001] This invention belongs to the field of BIM three-dimensional modeling, and more specifically, it relates to a three-dimensional visual lightweight engine system based on GIS and BIM. Background Technology

[0002] WebGL: OpenGL ES is an embedded, stripped-down version of OpenGL, commonly used in mobile devices like Android. To allow modern web applications to directly utilize graphics cards, 3D rendering, and other technologies, WebGL was developed in HTML5 based on OpenGL ES. WebGL enables 2D and 3D rendering on canvases in browsers that support HTML canvas tags without requiring any plugins, using APIs based on OpenES 2.0. When loading 3D models, WebGL typically uses its API to directly load .glTF files. This method is simple and fast, but as the size of the 3D model file increases, its rendering efficiency decreases, eventually causing browser crashes and rendering failures.

[0003] This problem occurs because a single GLTF file contains too much 3D model information, and this file contains unnecessary structural data for rendering the 3D model in the browser. This causes the 3D model to consume excessive CPU, GPU, and memory resources during rendering, ultimately leading to browser crashes.

[0004] The gltf file format is as follows:

[0005] {

[0006] "asset": {

[0007] "generator": "CL",

[0008] "version": "2.0"

[0009] },

[0010] "scene": 0,

[0011] "scenes": [

[0012] {

[0013] "nodes": [ 0 ]

[0016] }

[0017] ],

[0018] "nodes": [

[0019] {

[0020] "mesh": 0

[0021] }

[0022] ],

[0023] "meshes": [

[0024] {

[0025] "primitives": [

[0026] {

[0027] "attributes": {

[0028] "POSITION": 1,

[0029] "TEXCOORD_0": 2

[0030] },

[0031] "indices": 0,

[0032] "material": 0

[0033] } ]

[0035] }

[0036] ],

[0037] "materials": [

[0038] {

[0039] "pbrMetallicRoughness": {

[0040] "baseColorTexture": {

[0041] "index": 0

[0042] }

[0043] }

[0044] }

[0045] ],

[0046] "textures": [

[0047] {

[0048] "sampler": 0,

[0049] "source": 0

[0050] }

[0051] ],

[0052] "images": [

[0053] {

[0054] "uri": "tex.jpg"

[0055] }

[0056] ],

[0057] "samplers": [

[0058] {

[0059] "magFilter": 9729,

[0060] "minFilter": 9987,

[0061] "wrapS": 33648,

[0062] "wrapT": 33648

[0063] }

[0064] ],

[0065] "buffers": [

[0066] {

[0067] "uri": "new.bin",

[0068] "byteLength": 595236

[0069] }

[0070] ],

[0071] "bufferViews": [

[0072] {

[0073] "buffer": 0,

[0074] "byteOffset": 374400,

[0075] "byteLength": 220836,

[0076] "target": 34963

[0077] },

[0078] {

[0079] "buffer": 0,

[0080] "byteStride": 20,

[0081] "byteOffset": 0,

[0082] "byteLength": 374400,

[0083] "target": 34962

[0084] }

[0085] ],

[0086] "accessors": [

[0087] {

[0088] "bufferView": 0,

[0089] "byteOffset": 0,

[0090] "componentType": 5123,

[0091] "count": 110418,

[0092] "type": "SCALAR",

[0093] "max": [ 18719

[0095] ],

[0096] "min": [ 0 ]

[0099] },

[0100] {

[0101] "bufferView": 1,

[0102] "byteOffset": 0,

[0103] "componentType": 5126,

[0104] "count": 18720,

[0105] "type": "VEC3",

[0106] "max": [

[0107] 770,

[0108] 0.0, 1261.151611328125

[0110] ],

[0111] "min": [

[0112] 0.0,

[0113] -2390, 733.5555419921875 ]

[0116] },

[0117] {

[0118] "bufferView": 1,

[0119] "byteOffset": 12,

[0120] "componentType": 5126,

[0121] "count": 18720,

[0122] "type": "VEC2",

[0123] "max": [

[0124] 1, 1

[0126] ],

[0127] "min": [

[0128] 0, 0 ]

[0131] } ]

[0133] }

[0134] As can be seen from the above format, the data architecture describing the model has too many nodes and contains unnecessary node descriptions. When rendering a 3D model using WebGL, the necessary information is vertices, vertex indices, UV coordinates, and material paths. Summary of the Invention

[0135] The purpose of this invention is to provide a lightweight 3D visualization engine system based on GIS and BIM to solve the problems mentioned in the background art.

[0136] To achieve the above objectives, the present invention provides the following technical solution: a lightweight 3D visualization engine system based on GIS and BIM, comprising:

[0137] Step 1: Lightweight engine data parsing;

[0138] When parsing .rvt format files, only the necessary data for 3D model rendering is extracted, thereby reducing the file size. This necessary data includes: vertex data, vertex index data, UV coordinate data, and material path data. The vertex data is organized into a more concise form through parsing the .rvt file. The vertex index data is extracted sequentially from the vertices forming the triangles, grouping three numbers into a single array. The UV coordinate data is separated from the UV coordinates of the triangles during parsing. The material path data is used to fully reproduce the B-plane. The original color and display format of the IM model are also separated by separating the texture data. During data parsing and extraction, data is extracted by material type and four types of data files are generated. Then, each individual model in the .rvt file is broken down into smaller units, and the vertex information coordinates are stored in text data, which is called fragmentation. At the same time, the concept of "weight" is added to distinguish between "inside" and "outside" model data files, and the relative loading order of these data files, such as vertex data, vertex index data, UV coordinate data, and material path data, is specified. This allows for asynchronous loading during the engine's rendering stage, effectively shortening the user's waiting time. Finally, the ECC asymmetric encryption algorithm is used to encrypt the data files to ensure data security.

[0139] Step 2, Lightweight Engine Model Rendering Process:

[0140] The data file of the 3D model to be rendered is obtained and decrypted to obtain the real data file required by the engine for rendering;

[0141] The data file is then rendered using the rendering pipeline, which mainly includes two functions: first, to transform the 3D coordinates of the object into 2D coordinates in screen space; and second, to shade each pixel on the screen. The rendering pipeline consists of: vertex processing, clipping and primitive assembly, and rasterization.

[0142] ① Vertex processing involves operating on each input vertex stored in the vertex buffer using a vertex data file. This stage is programmable. The main operation is coordinate transformation of the vertices, converting the object from its defined coordinate system to the camera's coordinate system.

[0143] ② Combining the vertex index data file, the vertices are grouped into units, which are called primitives. This step is assembly, which combines the vertices into triangular faces.

[0144] ③ Using UV coordinate data and material data, the primitives are rasterized. Rasterization is the process of converting geometric primitives into images. It determines which integer grid areas in the window coordinates are occupied by basic primitives and assigns color and depth values ​​to the corresponding areas. The main purpose of rasterization is to convert the primitive data after assembly and cropping into pixels in the frame buffer. However, after rasterization, pixels are not directly obtained, but fragments are obtained instead.

[0145] ④ Fragment processing: The fragment shader calculates the final color and depth of the fragment. Since multiple fragments may compete for a single pixel, depth and stencil tests are used to determine if the current fragment is visible and whether it should be drawn to the frame buffer. After selecting suitable fragments and removing unimportant information such as normals and texture coordinates, the pixel is generated.

[0146] In the engine's 3D model rendering, 3D models are rendered on a per-material basis. The rendering pipeline engine's data organization method rapidly generates pixel frames; simultaneously, because pixel frames of the same material are generated in the same rendering process, frequent switching between CPU and GPU is reduced, further lowering system overhead and significantly improving rendering speed.

[0147] At the same time, by judging the "weight", the order of asynchronous loading is determined, so that the engine prioritizes rendering the relatively outer model, and then continues to render the relatively inner model or omits it through asynchronous loading, thereby improving the speed required for users to view 3D models.

[0148] Preferably, the vertex data is [-52.33, -0.33, -346.46, -52.33, -0.33, -344.82, -50.69, -0.33, -344.82, -50.69, -0.33, -346.46……], where every three numbers in this array represent the relative position coordinates of a vertex.

[0149] Preferably, the vertex index data [2, 3, 0, 0, 1, 2, 5, 7, 8, 7, 5, 6……] is such that every three numbers in the array represent a triangle face. During subsequent 3D model rendering, the indices in the array are sequentially retrieved to form triangle faces.

[0150] Preferably, the UV coordinate data is [0.82, -0.82, 0.82, 0.82, -0.82, 0.82, -0.82, 0.82, -0.82, 0.82, 13.78……]. In this array, every two numbers locate the coordinates of a UV map, and their order is also specified. They are written and read sequentially to ensure the accuracy of the UV map.

[0151] Preferably, the material path data is oint_sealant.png, which is a texture file.

[0152] Preferably, the ECC (Elliptic Curve Cryptography) asymmetric encryption algorithm can be an elliptic cryptography algorithm.

[0153] Compared with the prior art, the beneficial effects of the present invention are:

[0154] ① In the parsing and rendering of 3D models, this engine optimizes the data structure of 3D models during data storage, eliminates unnecessary data nodes, reduces the size of data files, and saves storage space for 3D model files.

[0155] ②By reducing the size of 3D model files, the cost of data transmission is reduced, thus reducing the waste of system resources.

[0156] ③ It improves the rendering capacity of 3D models in the browser, enabling web applications to load large scene models, reducing browser crashes and other problems caused by loading large scene models, and making the system more stable.

[0157] ④ The engine provides a standard API interface, which can provide code-level calls and enable BIM model-related businesses to deepen their information. Attached Figure Description

[0158] Figure 1 Lightweight Engine Data Parsing Flowchart;

[0159] Figure 2 Lightweight engine model rendering flowchart. Detailed Implementation

[0160] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0161] Please see Figure 1-2 One embodiment provided by the present invention:

[0162] To improve the rendering speed and capacity of 3D models, the lightweight engine divides the 3D model processing and rendering process into two steps: model data parsing and model rendering.

[0163] Lightweight Engine Data Parsing Process:

[0164] When parsing .rvt format files, only the necessary data for 3D model rendering is extracted, thereby reducing the file size. This significantly reduces the time required for model data file transfer under the same network or data transmission conditions. The necessary information for rendering a 3D model includes: vertices, vertex indices, UV coordinates, and material paths. The following describes the four extracted data formats: ① Vertex data: Through parsing the .rvt format file, the vertex data is organized into a more concise form, as follows: [-52.33, -0.33, -346.46, -52.33, -0.33, -344.82, -50.69, -0.33, -344.82, -50.69, -0.33, -346.46……], In this array, every three numbers represent the relative position coordinates of a vertex. ② Vertex index data: By parsing the .rvt format file, the vertices that make up the triangle are extracted sequentially, and every three numbers are grouped into the same array as follows: [2, 3, 0, 0, 1, 2, 5, 7, 8, 7, 5, 6……]. In this array, every three numbers represent a triangle. During subsequent 3D model rendering, the indices in this array are extracted sequentially to form the triangles.

[0165] ③ UV coordinate data: When parsing the .rvt format file, the UV coordinates corresponding to the triangular faces are separated simultaneously. As follows: [0.82, -0.82, 0.82, 0.82, -0.82, 0.82, -0.82, -0.82, 0.82, 13.78……] In this array, every two numbers locate the coordinates of a UV map, and their order is also specified. They are written and read sequentially to ensure the accuracy of the UV map.

[0166] ④ Material path data: When parsing .rvt format files, in order to fully restore the original colors and display format of the BIM model, the texture data is also separated as follows: joint_sealant.png, which is a texture file.

[0167] When parsing and extracting data, the data is extracted by material type and four data files are generated. This is because the rendering pipeline used later can generate pixel frames more quickly with this data organization method; at the same time, because pixel frames of one material are generated in the same rendering process, the frequent switching between CPU and GPU is reduced, thereby further reducing system overhead and significantly improving rendering speed.

[0168] Furthermore, the vertex information coordinates of each individual model in the .rvt file are broken down into smaller units (such as a building, a floor, or an office desk) and stored in text data, which is called fragmentation. At the same time, the concept of "weight" is added to distinguish between the "inside" and "outside" of the model data file and to specify the relative loading order of these data files. This allows for asynchronous loading during the engine's rendering phase, effectively shortening the user's waiting time (which will be explained in detail in the subsequent engine rendering section).

[0169] Finally, the ECC (Elliptic Curve Cryptography) asymmetric encryption algorithm is used to encrypt the data file, ensuring data security. ECC is a public-key encryption algorithm whose mathematical basis lies in the computational difficulty of constructing the elliptic discrete logarithm over the Abelian additive group using rational points on an elliptic curve. Public-key cryptosystems are generally classified into three categories based on the problems they are based on: large integer factorization, discrete logarithm problems, and elliptic curve problems. Sometimes, elliptic curve cryptosystems are also classified under discrete logarithm cryptosystems.

[0170] The main advantage of ECC (Elliptic Curve Cryptography) is that in some cases it provides a comparable or higher level of security than other methods (such as RSA) using smaller keys. Another advantage of ECC is that it can define bilinear mappings between groups, based on Weil pairs or Tate pairs; bilinear mappings have been found to have many applications in cryptography, such as identity-based encryption.

[0171] The core code of the algorithm is as follows:

[0172] ① Generate ECC key

[0173] The `generateECCKeyPair` method generates the key pair needed for encryption. Since the BouncyCastle library has specified keysize requirements, refer to the `KeyPairGeneratorSpi` class in the BouncyCastle library, which shows supported keysizes of 192, 239, 256, 224, 384, and 521. The Provider needs to be initialized using a static initialization block with constants `EC_ALGORITHM = "EC"` and `EC_PROVIDER = "BC"`. Finally, a random key pair is generated for encryption and decryption.

[0174] / **

[0175] Generate key pairs

[0176] * @param keysize Key length

[0177] * @return key pair

[0178] /

[0179] public static KeyPair generateECCKeyPair(int keysize) {

[0180] try {

[0181] / / Get key pair generator for specified algorithm

[0182] KeyPairGenerator generator =

[0183] KeyPairGenerator.getInstance(EC_ALGORITHM, EC_PROVIDER);

[0184] / / Initialize the key pair generator (specify key length, use the default secure random number source)

[0185] generator.initialize(keysize);

[0186] / / Randomly generate a key pair (containing a public key and a private key)

[0187] return generator.generateKeyPair();

[0188] } catch (Exception e) {

[0189] e.printStackTrace();

[0190] }

[0191] return null;

[0192] }

[0193] ② Encryption

[0194] The `eccEncrypt` method uses the public key generated in the `generateECCKeyPair` method to encrypt the original text passed to the method. The constants `ECIES_ALGORITHM = "ECIES"` and `EC_PROVIDER = "BC"` are used. The final output is the encrypted ciphertext.

[0195] / **

[0196] * ECC Encryption

[0197] * @param publicKey Public Key

[0198] * @param plain Original text

[0199] * @return Ciphertext

[0200] /

[0201] public static byte[] eccEncrypt(PublicKey publicKey, byte[] plain) {

[0202] try {

[0203] Cipher cipher = Cipher.getInstance(ECIES_ALGORITHM, EC_PROVIDER);

[0204] cipher.init(Cipher.ENCRYPT_MODE, publicKey);

[0205] return cipher.doFinal(plain);

[0206] } catch (Exception e) {

[0207] e.printStackTrace();

[0208] }

[0209] return null;

[0210] }

[0211] ③ Decryption

[0212] The `eccEncrypt` method uses the private key generated in the `generateECCKeyPair` method to decrypt the ciphertext passed to the method, where the constants `ECIES_ALGORITHM = "ECIES"` and `EC_PROVIDER = "BC"` are used. The final output is the decrypted plaintext.

[0213] / **

[0214] * ECC Decryption

[0215] * @param privateKey private key

[0216] * @param encrypted ciphertext

[0217] * @return Original text

[0218] /

[0219] public static byte[] eccDecrypt(PrivateKey privateKey, byte[]encrypted) {

[0220] try {

[0221] Cipher cipher = Cipher.getInstance(ECIES_ALGORITHM, EC_PROVIDER);

[0222] cipher.init(Cipher.DECRYPT_MODE, privateKey);

[0223] return cipher.doFinal(encrypted);

[0224] } catch (Exception e) {

[0225] e.printStackTrace();

[0226] }

[0227] return null;

[0228] }

[0229] Lightweight engine model rendering workflow:

[0230] First, the data file of the 3D model to be rendered is obtained and decrypted to get the real data file required by the engine for rendering.

[0231] Next, the data file is rendered using the rendering pipeline. The rendering pipeline mainly includes two functions: first, transforming the 3D coordinates of the object into 2D coordinates in screen space; and second, shading each pixel on the screen. The general flow of the rendering pipeline is shown in the figure below, which includes: vertex processing, clipping and primitive assembly, and rasterization.

[0232] ① Vertex processing involves operating on each input vertex stored in the vertex buffer using the vertex data file. This stage is programmable. The main operation is coordinate transformation, converting the object from its defined coordinate system to the camera's coordinate system.

[0233] ② Combining the vertex index data file, the vertices are grouped into individual units, which are called primitives. This step is assembly, combining the vertices into triangular faces.

[0234] ③ Using UV coordinate data and material data, the primitives are rasterized. Rasterization is the process of converting geometric primitives into images. It determines which integer raster areas in the window coordinates are occupied by basic primitives and assigns color and depth values ​​to the corresponding areas. The main purpose of rasterization is to convert the primitive data after assembly and cropping into pixels in the frame buffer. However, after rasterization, pixels are not directly obtained, but fragments are obtained instead.

[0235] ④ Fragment processing mainly involves calculating the final color and depth of fragments using the fragment shader. Since multiple fragments may compete for a single pixel, depth and stencil tests are used to determine the visibility of the current fragment and whether it should be drawn to the frame buffer. After selecting suitable fragments and removing less important information such as normals and texture coordinates, the pixel is generated.

[0236] In the engine's rendering of 3D models, the 3D models are rendered in units of material type. Under the data organization method of the rendering pipeline engine, pixel frames are generated quickly. At the same time, because pixel frames of one material are generated in the same rendering process, the frequent switching between CPU and GPU is reduced, thereby further reducing system overhead and significantly improving rendering speed.

[0237] At the same time, by judging the "weight", the order of asynchronous loading is determined, so that the engine prioritizes rendering the relatively outer model, and then continues to render the relatively inner model or omits it through asynchronous loading, thereby improving the speed required for users to view 3D models.

[0238] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A lightweight 3D visualization engine system based on GIS and BIM, characterized in that, include: Step 1: Lightweight Engine Data Analysis; When parsing .rvt format files, only the necessary data for 3D model rendering is extracted, thereby reducing the size of the data file. The necessary data includes vertex data, vertex index data, UV coordinate data, and material path data. The vertex data is obtained by parsing the .rvt format file and organizing the vertex data into a more concise form. The vertex data is [-52.33, -0.33, -346.46, -52.33, -0.33, -344.82, -50.69, -0.33, -344.82, -50.69, -0.33, -346.46]. In this array, every three numbers represent the relative position coordinates of a vertex. The vertex index data is obtained by parsing the .rvt format file, extracting the vertices that make up the triangle face in sequence, and grouping them into an array of three numbers each. The UV coordinate data is obtained by separating the UV coordinates of the triangular faces simultaneously when parsing the .rvt format file; The material path data is generated when parsing the .rvt format file, separating the texture data. During the parsing and extraction of data, four types of data files are generated: ① vertex data ② vertex index data ③ UV coordinate data ④ material path data. The individual models in the .rvt file are then broken down into smaller units, and the vertex information coordinates are stored in text data, a process known as fragmentation. At the same time, the "inside" and "outside" of the model data files are distinguished, and the relative loading order of these data files is specified. During the engine's rendering phase, asynchronous loading is used to effectively shorten the user's waiting time. Finally, the ECC asymmetric encryption algorithm is used to encrypt the data files. Step 2: Lightweight Engine Model Rendering: The data file of the 3D model to be rendered is obtained and decrypted to obtain the real data file required by the engine for rendering; The data file is then rendered using the rendering pipeline. The rendering pipeline mainly includes two functions: first, to transform the 3D coordinates of the object into 2D coordinates in screen space; and second, to shade each pixel on the screen. The rendering pipeline consists of vertex processing, clipping and primitive assembly, and rasterization. ① Vertex processing uses the vertex data file to operate on each input vertex stored in the vertex buffer. This stage is programmable. The main operation is to perform coordinate transformation on the vertices, converting the object from its defined coordinate system to the camera's coordinate system. ② Combining the vertex index data file, the vertices are grouped into units, which are the primitives. This step is assembly, which combines the vertices into triangles. ③ Using UV coordinate data and material data, the primitives are rasterized. Rasterization is the process of converting geometric primitives into images. It determines which integer grid areas in the window coordinates are occupied by basic primitives and assigns color and depth values ​​to the corresponding areas. The main purpose of rasterization is to convert the primitive data after assembly and cropping into pixels in the frame buffer. After rasterization, fragments are obtained. ④ Fragment processing: The fragment shader calculates the final color and depth of fragments. Since multiple fragments may compete for a single pixel, depth and stencil tests are used to determine the visibility of the current fragment and whether it should be drawn to the frame buffer. After selecting suitable fragments and removing unimportant information such as normals and texture coordinates, pixels are generated. In the engine's rendering of 3D models, 3D models are rendered in units of material type. Under the data organization method of the rendering pipeline engine, pixel frames are generated quickly, reducing frequent switching between CPU and GPU, thereby further reducing system overhead. At the same time, by judging "weights," the engine prioritizes rendering relatively outer models, and then continues to render relatively inner models or omit them through asynchronous loading, thereby improving the speed required for users to view 3D models.

2. The lightweight 3D visualization engine system based on GIS and BIM according to claim 1, characterized in that: The vertex index data is [2, 3, 0, 0, 1, 2, 5, 7, 8, 7, 5, 6]. In this array, every three numbers represent a triangle. During the subsequent 3D model rendering, the indices in this array are taken out in sequence to form triangles.

3. The lightweight 3D visualization engine system based on GIS and BIM according to claim 1, characterized in that: The UV coordinate data is [0.82, -0.82, 0.82, 0.82, -0.82, 0.82, -0.82, -0.82, 0.82, 13.78]. In this array, every two numbers locate the coordinates of a UV map. The order of the UV coordinate data is also specified, and they are written and read sequentially to ensure the accuracy of the UV map.

4. The lightweight 3D visualization engine system based on GIS and BIM according to claim 1, characterized in that: The material path data is joint_sealant.png, which is a texture file.

5. A lightweight 3D visualization engine system based on GIS and BIM according to claim 1, characterized in that: The ECC asymmetric encryption algorithm is an elliptic cryptography algorithm.

Images