BIM lightweight engine component management method based on texture mapping

Abstract

The invention provides a BIM lightweight engine component management method based on texture mapping, belongs to the technical field of BIM visualization and computer graphics, and realizes efficient state management of components by introducing a state mapping technology. According to the method, the limitation of a traditional BIM rendering engine in the aspect of component state management is broken through, and the problems of performance bottleneck caused by multiple times of rendering, too large CPU calculation overhead and the like are solved. According to the method, the component state information is coded and stored in the texture, so that the visual state presentation of all components can be completed through single drawing, the rendering efficiency is remarkably improved at the cost of occupying extremely small video memory and memory, and the occupation of the video memory and the memory is reduced.

Description

Technical Field

[0001] This invention belongs to the field of Building Information Modeling (BIM) visualization and computer graphics technology, specifically relating to a method for managing components in a BIM lightweight engine based on texture mapping, and more particularly to a component visual state management technology in a BIM lightweight engine based on the WebGL platform. More specifically, this invention proposes a method for uniformly managing the visual states of components in a BIM model, such as highlighting, shading, showing, and hiding, using GPU textures within a BIM lightweight engine. Background Art

[0002] As mentioned in the prior art patent publication number "CN114662200B", the application of BIM lightweight engine is becoming more and more common. BIM lightweight engine refers to a technology that uses various model conversion, simplification and reduction technologies to reduce the volume of BIM models (Building Information Models) while meeting the requirements of information losslessness, model accuracy and usage functions, and converts the models into data organizations that are more friendly to rendering, and then displays them quickly and efficiently on computers through visualization technologies such as WebGL.

[0003] Component status management in the BIM lightweight engine is as follows: Components are BIM components, standardized three-dimensional elements with specific functions and parameter information, and are the basic units that make up a building model, such as a window or a wall. Component status management refers to setting various states for components in the BIM lightweight engine, such as color (shading), display, and hiding. These states distinguish components and represent production progress, equipment online or offline status, and other information. Component status management is a critical function in the BIM lightweight engine and requires very high frequency operation.

[0004] Traditional BIM component status management methods primarily rely on the CPU for status marking and updates, which presents numerous performance challenges when processing large BIM models. When components need to be displayed in different states, such as highlighted, shaded, or hidden, traditional methods require multiple rendering cycles, each targeting only the component in a specific state. This results in duplicate GPU resources and reduced performance. For example, when rendering BIM models on mobile devices, due to hardware performance limitations, multiple rendering cycles can cause noticeable lag, severely degrading the user experience.

[0005] Another approach encodes component state into vertex attributes, assigning a state code to each vertex. This approach frequently modifies vertex attributes or recalculates rendering parameters when the state changes. Vertex attributes also significantly increase memory and graphics memory usage, increasing the burden on the CPU and bandwidth. Furthermore, when a model contains hundreds of millions of vertices, each state update triggers a large amount of data transfer from the CPU to the GPU, causing a sharp drop in overall rendering performance.

[0006] Specifically, a complex BIM model may contain tens of thousands of components. Using the first method mentioned above for state management will cause a large amount of repeated rendering, greatly reducing rendering efficiency.

[0007] The second method of state management requires maintaining a separate state flag or property array for each component on the CPU, which consumes a large amount of memory resources. This directly limits the lightweightness and operational efficiency of the BIM model, especially in mobile applications.

[0008] In summary, existing technologies are difficult to meet the needs of efficiently managing the visual status of a large number of BIM components under the WebGL platform. A new method is urgently needed to improve rendering efficiency and save memory and video memory. Summary of the Invention

[0009] To address the defects in the existing technology, the present invention provides a BIM lightweight engine component management method based on texture mapping. This method can significantly improve rendering efficiency, reduce drawing times, and save GPU memory usage on the WebGL platform, thereby achieving unified and efficient management of all component states.

[0010] The present invention utilizes the following technical solutions.

[0011] A BIM lightweight engine component management method based on texture mapping, comprising:

[0012] Step 1: The process of encoding the state into the texture:

[0013] Step 2: GPU-side rendering sampling in real-time rendering: Only one draw call is required to render all components.

[0014] Furthermore, step 1 specifically includes:

[0015] Step 1-1: Assign a unique index to each component;

[0016] Step 1-2: Dynamically calculate texture size;

[0017] Step 1-3: Create state texture;

[0018] Steps 1-4: Pixel and component mapping;

[0019] Step 1-5: Perform status encoding;

[0020] Step 1-6: CPU updates the status.

[0021] Furthermore, in step 1-1, a unique integer index value is assigned to each component in the BIM model.

[0022] Furthermore, in step 1-2, the size of the required state texture is calculated based on the number of components N in the BIM model A: first, the required number of pixels M = ceil(N / 4) is calculated, that is, the number of components is divided by 4 and then rounded up. ceil(N / 4) is N / 4 rounded up.

[0023] Further calculate the texture width and height imageWidth and imageHeight, and select the smallest width imageWidth and height imageHeight that satisfy imageWidth×imageHeight≥M to ensure that the texture area is as small as possible and imageWidth and imageHeight must be powers of 2, imageWidth is the texture width, and imageHeight is the texture height.

[0024] Furthermore, in step 1-2, the algorithm for calculating texture width and height imageWidth and imageHeight is as follows:

[0025] Input: the required number of pixels M;

[0026] Constraints:

[0027] Texture width imageWidth and height imageHeight must both be ;

[0028] Total pixels imageWidth×imageHeight≥M;

[0029] The area imageWidth×imageHeight should be as small as possible;

[0030] Calculation steps:

[0031] Determine the upper bound of the power EMax, that is, take the logarithm of 2 of M and round it up. The specific formula is as follows:

[0032]

[0033] in, For Round up;

[0034] Initialize the optimal area bestArea=infinite and the optimal dimension bestW=bestH=0, where infinite means infinite, bestW means the optimal dimension for width, and bestH means the optimal dimension for height;

[0035] Perform a double loop for each i and j:

[0036] 1. Set width = 2i , let height2 j ,

[0037] 2. If width * height < ceil(N / 4), skip it; otherwise, calculate area = width * height;

[0038] 3. If area < bestArea, update bestArea = area, bestW = width, bestH = height;

[0039] If area == bestArea, it can be further compared by |i - j| to obtain a shape closer to a square;

[0040] After the loop ends, bestW and bestH are the optimal solutions, that is, imageWidth = bestW, imageHeight = bestH.

[0041] Furthermore, in steps 1 - 3, after obtaining the texture sizes imageWidth and imageHeight, call the WebGL interface to create a status texture of the above dimensions. Create a two-dimensional RGBA status texture on the GPU side, that is, the status texture, and the internal format of the texture is an unsigned integer type.

[0042] Furthermore, in steps 1 - 4, in this status texture, every 4 components share one pixel. The specific mapping method is as follows: the R, G, B, and A channels of the same pixel store the status values of 4 different components respectively;

[0043] Let the index of the component be index, then the pixel number pixelIndex is the floor of the component index divided by 4, which is expressed by the formula as follows:

[0044] ;

[0045] Among them, represents the floor of ;

[0046] The channel number channelIndex is the remainder of the component index value divided by 4, which is expressed by the formula as follows:

[0047]

[0048] Among them, mod is the remainder operation;

[0049] Next, the state representation is carried out, that is, each state contains four pieces of information, namely r, g, and b, which are three numerical values ​​representing the shading color information of the component, and their values ​​are color values ​​0-255; a is used to control the transparency and visibility of the component, where 0 means that the component is hidden (not displayed), non-zero values ​​represent semi-transparent values, and 1 represents completely opaque.

[0050] Furthermore, in steps 1-5, the values ​​of r, g, b, and a are combined into a 32-bit unsigned integer by placing the binary value of a into bits 0 to 8 of the unsigned integer, the value of b into bits 9 to 16 of the unsigned integer, the value of g into bits 17 to 24, and the value of r into bits 25 to 32.

[0051] Furthermore, in steps 1-6, the component state change logic is maintained on the CPU side. That is, when the visual state of a component changes, the specific pixel row and column number of its state information is calculated based on the component index value. The row number rowIndex of the pixel is calculated by dividing the pixelIndex calculated in steps 1-4 by the state texture width imageWidth and rounding down. The column number columnIndex is calculated by dividing the pixelIndex by the imageWidth and the remainder. The formula is as follows:

[0052]

[0053] in, Express Round down, mod means remainder operation;

[0054] Then, the state value encoded in steps 1-4 is set to the channelIndex pixel channel of the pixel corresponding to the rowIndex and columnIndex positions. Finally, the updated texture data is uploaded to the GPU by calling the WebGL function to update the state texture in real time.

[0055] Furthermore, in step 2, during the rendering process, the state texture is bound to a texture unit in the fragment shader. The vertex shader of each component receives and passes the component index value. In the fragment shader, the corresponding texture coordinate uv and channel value are calculated based on the passed component index. The u coordinate is essentially equal to the pixel row number divided by the texture width, and the v coordinate is essentially equal to the pixel column number processed by the texture height.

[0056] Furthermore, in step 2, the formula for calculating pixel coordinates is:

[0057]

[0058] in, Express Round down, Express Round down, mod means remainder operation.

[0059] The beneficial effects of the present invention are as follows:

[0060] This invention achieves efficient component state management by introducing state mapping technology. This method overcomes the limitations of traditional BIM rendering engines in component state management, resolving performance bottlenecks and excessive CPU overhead caused by multiple rendering cycles. By encoding and storing component state information in textures, it enables visualization of all components in a single rendering pass, significantly improving rendering efficiency and reducing video memory and main memory usage at the expense of minimal video memory and main memory usage. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Figure 1 It is a flow chart of the BIM lightweight engine component management method based on texture mapping in the present invention. DETAILED DESCRIPTION

[0062] To make the objectives, technical solutions, and advantages of the present invention more clear, the following will be combined with the accompanying drawings in the embodiments of the present invention to clearly and completely express the technical solutions of the present invention. The embodiments expressed in this application are only part of the embodiments of the present invention, not all of the embodiments. Based on the spirit of the present invention, other embodiments obtained by ordinary technicians in this field without making creative work are all within the scope of protection of the present invention.

[0063] like Figure 1 As shown, a BIM lightweight engine component management method based on texture mapping includes:

[0064] Step 1: First, the state should be encoded into the texture:

[0065] In a preferred but non-limiting embodiment of the present invention, step 1 specifically comprises:

[0066] Step 1-1: Assign a unique index to each component;

[0067] In a preferred but non-limiting embodiment of the present invention, in step 1-1, a unique integer index value (e.g., starting from 0 and increasing) is assigned to each component in the BIM model. This index is used to locate the corresponding state storage location of the component in subsequent steps.

[0068] Step 1-2: Dynamically calculate texture size;

[0069] In a preferred but non-limiting embodiment of the present invention, in step 1-2, the size of the required state texture is calculated according to the number N of components in the BIM model A: first, the required number of pixels M=ceil(N / 4) is calculated, that is, the number of components is divided by 4 and then rounded up, ceil(N / 4) is N / 4 rounded up; for example, the number of components in a BIM model is 440001, then the required number of pixels M is 440001 divided by 4 and rounded up to 110001, that is, the texture requires at least M=110001 pixels to completely store the state information of 440001 components.

[0070] The texture width and height imageWidth and imageHeight should be further calculated, and the minimum width imageWidth and height imageHeight should be selected to satisfy imageWidth×imageHeight≥M to ensure that the texture area is as small as possible and imageWidth and imageHeight must be powers of 2, imageWidth is the texture width, and imageHeight is the texture height.

[0071] In a preferred but non-limiting embodiment of the present invention, in step 1-2, the algorithm for calculating texture width and height imageWidth and imageHeight can be briefly described as follows:

[0072] Input: the required number of pixels M;

[0073] Constraints:

[0074] Texture width imageWidth and height imageHeight must both be ;

[0075] Total pixels imageWidth×imageHeight≥M;

[0076] The area imageWidth×imageHeight should be as small as possible;

[0077] Calculation steps:

[0078] Determine the upper bound of the power EMax, that is, take the logarithm of 2 of M and round it up. The specific formula is as follows:

[0079]

[0080] in, For Round up;

[0081] For example, if M=110001, then the logarithm of 2 is taken from 110001 and rounded up to 17, that is, EMax=17.

[0082] Initialize the optimal area bestArea = infinite, the optimal dimensions bestW = bestH = 0, where infinite represents infinity, bestW represents the optimal width dimension, and bestH represents the optimal height dimension;

[0083] Perform a nested loop for each i and j (both from 0 to EMax):

[0084] 1. Set width = 2 i , set height = 2 j ,

[0085] 2. If width * height < ceil(N / 4), skip; otherwise, calculate area = width * height;

[0086] 3. If area < bestArea, update bestArea = area, bestW = width, bestH = height;

[0087] 1. If area == bestArea, further compare according to |i - j| (the smaller the closer to a square) to obtain a shape closer to a square; the method to further compare according to |i - j| (the smaller the closer to a square) when area == bestArea is: if area == bestArea, select i and j with a smaller absolute value |i - j|, so that the texture size obtained is closer to a square texture.

[0088] After the loop ends, bestW and bestH are the optimal solutions, that is, imageWidth = bestW, imageHeight = bestH.

[0089] For example, for the A model with the above component quantity of 440001, at least 110001 pixels are required to completely store its component attribute information. Through the above pixel width and height calculation algorithm, it is easy to obtain imageWidth = 256 and imageHeight = 512, which are the optimal solutions for the component state texture size.

[0090] Steps 1 - 3: Create a state texture;

[0091] In a preferred but non-limiting embodiment of the present invention, in steps 1-3, after obtaining the texture size imageWidth and imageHeight, the WebGL interface is called to create a state texture of the above size. A two-dimensional RGBA state texture (hereinafter referred to as "state texture") is created on the GPU side. The internal format of the state texture is an unsigned integer type (such as RGBA32UI or RGBA8UI in WebGL2), so that each channel can accurately store [0, ] range of unsigned integer values.

[0092] Steps 1-4: Pixel and component mapping;

[0093] In a preferred but non-limiting embodiment of the present invention, in steps 1-4, in the state texture, every four components share one pixel, and the specific mapping method is: the four channels R, G, B, and A of the same pixel respectively store the state values ​​of four different components;

[0094] Let the component index be index, then the pixel number pixelIndex is the component index divided by 4 and rounded down, which can be expressed as follows:

[0095] ;

[0096] in, Express Round down;

[0097] For example, if the index value of a component in model A is 175, the pixel number can be calculated using the above method. 175 is divided by 4 and rounded down to 43, which means that the status information of the component is stored in the 43rd pixel of the texture.

[0098] Specifically, which of the four channels of the pixel is stored can be calculated using the following rules. The channel index channelIndex is the remainder of the component index value divided by 4, which can be expressed as follows:

[0099]

[0100] Among them, mod is the remainder operation;

[0101] For example, the component index is 175. The remainder of 175 divided by 4 is 3. It can be known that the status information of the component is in the pixel channel numbered 3 (i.e., channel A). In summary, the status information of the component with component index 175 should be stored in the pixel channel numbered 43.

[0102] Next, the state is represented, that is, each state contains four pieces of information, namely r, g, and b, which are three numerical values ​​representing the shading color information of the component (such as highlight color or status color), and the value is a color value of 0-255; a is used to control the transparency and visibility of the component, where 0 means that the component is hidden (not displayed), a non-zero value indicates a semi-transparent value, and 1 indicates completely opaque.

[0103] Step 1-5: Perform status encoding;

[0104] In a preferred but non-limiting embodiment of the present invention, in steps 1-5, the above-mentioned r, g, b, and a values ​​are combined into a 32-bit unsigned integer. Specifically, the binary value of a is placed in bits 0 to 8 of the unsigned integer, the b value is placed in bits 9 to 16 of the unsigned integer, the g value is placed in bits 17 to 24, and the r value is placed in bits 25 to 32.

[0105] Step 1-6: CPU updates the status;

[0106] In a preferred but non-limiting embodiment of the present invention, in steps 1-6, the CPU maintains component state change logic. Specifically, when a component's visual state (color or visibility) changes, the specific pixel row and column numbers where its state information resides are calculated based on the component index. The row index (rowIndex) of a pixel is calculated by dividing the pixelIndex calculated in steps 1-4 by the state texture width (imageWidth), rounded down. The column index (columnIndex) is calculated by dividing the pixelIndex by the imageWidth, the remainder, as expressed by the following formula:

[0107]

[0108] in, Express Round down, mod means remainder operation;

[0109] For example, for the component numbered 175 in model A, the texture width imageWidth obtained in the third step is 256, and the pixelIndex calculated in the fourth step is 43. Then the pixel row number rowIndex is 175 divided by 256, rounded down to 0, and the pixel column number columnIndex is 175 divided by 256, with the remainder being 175. In summary, the status information of this component is stored in the first row and 175th column of the texture (starting from 0).

[0110] Then, the state value encoded in steps 1-4 is set to the channelIndex pixel channel of the pixel at the position corresponding to rowIndex and columnIndex (channelIndex has been calculated in steps 1-4). Finally, the updated texture data is uploaded to the GPU by calling the WebGL function, and the state texture is updated in real time. The process of encoding the state to the texture is completed. After the state is encoded to the texture and saved as an image file, it can be used in the subsequent real-time rendering process to sample the state information on the GPU and act on the rendering and shading process.

[0111] Step 2: GPU-side rendering sampling in real-time rendering: Only one draw call is required to render all components.

[0112] In a preferred but non-limiting embodiment of the present invention, in step 2, during the rendering process, the state texture is bound to a texture unit in the fragment shader. Each component's vertex shader receives and passes the component's index value (e.g., via a vertex attribute or instance attribute). In the fragment shader, the corresponding texture coordinate (uv) and channel value are calculated based on the passed component index. The u coordinate is essentially equal to the pixel row number divided by the texture width, and the v coordinate is essentially equal to the pixel column number processed by the texture height (for details on row and column numbers, see steps 1-6 of the state encoding process).

[0113] In a preferred but non-limiting embodiment of the present invention, in step 2, the formula for calculating pixel coordinates is:

[0114]

[0115] in, Express Round down, Express Round down, mod means remainder operation.

[0116] For example, in model A, component number 175 has its row and column numbers calculated to be 0 and 175, respectively, and its texture width and height to be 256 and 512, respectively. Therefore, u is 0 divided by 256, which equals 0, and v is 175 divided by 512, which equals 0.341796875. At this point, we can use the coordinates [0, 0.341796875] to sample the state texture in the fragment shader using WebGL interfaces and retrieve the state value stored in the pixel.

[0117] Channel value: This has been described in detail in steps 1-4 of the state encoding process and will not be repeated here.

[0118] Step 2 specifically includes:

[0119] The first step is to retrieve the pixel's RGBA values ​​from the state texture. The specific state value is obtained based on the channelIndex channel value. For example, if channelIndex is 0, the state value is R; if channelIndex is 1, the state value is G, and so on. The 32-bit unsigned integer state value stored in the corresponding pixel channel is retrieved.

[0120] The second step is to decode the four state values ​​of r, g, b, and a based on the 32-bit unsigned integer state value in accordance with the provisions of the fourth step of the texture encoding to texture process. Each state value is 8 bits (range 0 to 255).

[0121] The third step determines the visual effect based on the extracted state value: if the a state is 0, the fragment is discarded (hiding the fragment); otherwise, the fragment is displayed, and the fragment output color is set to the extracted decoded r, g, and b (which can be superimposed with other lighting or material calculation results or directly used as the final color), with the alpha value being a. The entire rendering process does not require drawing each component separately. Most modern GLSL versions can directly obtain accurate channel values ​​through integer sampling, thus ensuring the accuracy of the state values.

[0122] The advantages of the present invention are as follows:

[0123] Reduced data transmission overhead: The CPU only needs to update the state texture when the state changes, without having to retransmit vertex attribute data every time the state changes, thereby significantly reducing the amount of data communication between the CPU and GPU.

[0124] Reduce the number of drawing times: Traditional methods often require multiple calls to drawing instructions for different states. This invention completes the rendering of all components with a single drawing call, avoiding the overhead caused by multiple drawing calls and improving the rendering performance after the component state changes by more than 50%.

[0125] Unified and efficient rendering: The states of all components are managed uniformly in a single texture, and the fragment shader applies each state at once according to the index, making it possible to quickly achieve visualization effects such as highlighting, transparency, or hiding in complex BIM scenes.

[0126] Save video memory: Dynamically calculate and use the smallest size state texture to avoid allocating a large number of vertices or material buffers for each component, reducing GPU video memory usage and internal memory usage by more than 95%.

[0127] The beneficial effects of the present invention are as follows:

[0128] This invention achieves efficient component state management by introducing state mapping technology. This method overcomes the limitations of traditional BIM rendering engines in component state management, resolving performance bottlenecks and excessive CPU overhead caused by multiple rendering cycles. By encoding and storing component state information in textures, it enables visualization of all components in a single rendering pass, significantly improving rendering efficiency and reducing video memory and main memory usage at the expense of minimal video memory and main memory usage.

[0129] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the relevant field should understand that the specific implementation methods of the present invention can still be modified or replaced by equivalents. Any modification or equivalent replacement that does not deviate from the spirit and scope of the present invention should be covered within the protection space of the claims of the present invention.

Claims

1. A BIM lightweight engine component management method based on texture mapping, characterized in that: It includes: Step 1: Perform the process of state encoding to texture: Step 2: GPU-side rendering sampling in real-time rendering: When rendering all components, only one draw call needs to be executed.

2. The BIM lightweight engine component management method based on texture mapping according to claim 1 is characterized in that: Step 1 specifically includes: Step 1-1: Assign a unique index to each component; Step 1-2: Dynamically calculate the texture size; Step 1-3: Create a state texture; Step 1-4: Pixel-component mapping; Step 1-5: Perform state encoding; Step 1-6: Update the state on the CPU side.

3. The BIM lightweight engine component management method based on texture mapping according to claim 2 is characterized in that: In Step 1-1, assign a unique integer index value to each component in the BIM model.

4. The BIM lightweight engine component management method based on texture mapping according to claim 3 is characterized in that: In Step 1-2, according to the number of components N in the BIM model A, calculate the size of the required state texture: First, calculate the required number of pixels M = ceil(N / 4), that is, divide the number of components by 4 and then round up, and ceil(N / 4) is to round up N / 4; Further calculate the texture width imageWidth and height imageHeight, and select the smallest width imageWidth and height imageHeight that satisfy imageWidth × imageHeight ≥ M to ensure that the texture area is as small as possible and imageWidth and imageHeight must be powers of 2, where imageWidth is the texture width and imageHeight is the texture height; In Step 1-2, the algorithm for calculating the texture width imageWidth and height imageHeight is as follows: Input: The required number of pixels M; Constraints: Texture width imageWidth and height imageHeight must both be ; Total pixels imageWidth × imageHeight ≥ M; Area imageWidth × imageHeight is as small as possible; Calculation steps: Determine the upper bound of the power EMax, that is, take the logarithm of M to the base 2 and round up. The specific formula is as follows: in, For Round up; Initialize the optimal area bestArea = infinite, the optimal dimensions bestW = bestH = 0, where infinite represents infinity, bestW represents the optimal width dimension, and bestH represents the optimal height dimension; Perform a double loop for each i and j: (1) Set width = 2 i , let height2 j , (2) If width * height < ceil(N / 4), skip, otherwise calculate area = width * height; (3) If area < bestArea, update bestArea = area, bestW = width, bestH = height; If area == bestArea, further compare according to |i - j| to obtain a shape closer to a square; After the loop ends, bestW and bestH are the optimal solutions, that is, imageWidth = bestW, imageHeight = bestH.

5. The BIM lightweight engine component management method based on texture mapping according to claim 4 is characterized in that: In steps 1-3, after obtaining the texture sizes imageWidth and imageHeight, the WebGL interface is called to create a state texture of the aforementioned size. A two-dimensional RGBA state texture, also known as a state texture, is created on the GPU. The internal format of the texture is an unsigned integer type.

6. The BIM lightweight engine component management method based on texture mapping according to claim 5 is characterized in that: In steps 1-4, in the state texture, every four components share one pixel. The specific mapping method is: the R, G, B, and A channels of the same pixel store the state values ​​of four different components respectively; Let the component index be index, then the pixel number pixelIndex is the component index divided by 4 and rounded down, which can be expressed as follows: ； in, Express Round down; The channel index channelIndex is the remainder of the component index value divided by 4, and is expressed as follows: Among them, mod is the remainder operation; Next, the state representation is carried out, that is, each state contains four pieces of information, namely r, g, and b, which are three numerical values ​​representing the shading color information of the component, and their values ​​are color values ​​0-255; a is used to control the transparency and visibility of the component, where 0 means that the component is hidden (not displayed), non-zero values ​​represent semi-transparent values, and 1 represents completely opaque.

7. The BIM lightweight engine component management method based on texture mapping according to claim 6 is characterized in that: In steps 1-5, the values ​​of r, g, b, and a are combined into a 32-bit unsigned integer by placing the binary value of a into bits 0 to 8 of the unsigned integer, the value of b into bits 9 to 16, the value of g into bits 17 to 24, and the value of r into bits 25 to 32.

8. The BIM lightweight engine component management method based on texture mapping according to claim 7 is characterized in that: In steps 1-6, the component state change logic is maintained on the CPU side. That is, when the visual state of a component changes, the specific pixel row and column number of its state information is calculated based on the component index value. The row number rowIndex of the pixel is calculated by dividing the pixelIndex calculated in steps 1-4 by the state texture width imageWidth and rounding down. The column number columnIndex is calculated by dividing the pixelIndex by the imageWidth and the remainder. The formula is as follows: in, Express Round down, mod means remainder operation; Then, the state value encoded in steps 1-4 is set to the channelIndex pixel channel of the pixel corresponding to the rowIndex and columnIndex positions. Finally, the updated texture data is uploaded to the GPU by calling the WebGL function to update the state texture in real time.

9. The BIM lightweight engine component management method based on texture mapping according to claim 8, characterized in that: In step 2, during the rendering process, the state texture is bound to a texture unit in the fragment shader. Each component's vertex shader receives and passes the component's index. In the fragment shader, the texture coordinates (uv) and channel values ​​are calculated based on the passed component index. The u coordinate is essentially the pixel row number divided by the texture width, and the v coordinate is essentially the pixel column number divided by the texture height.

10. The BIM lightweight engine component management method based on texture mapping according to claim 9 is characterized in that: In step 2, the formula for calculating pixel coordinates is: in, Express Round down, Express Round down, mod means remainder operation.

Images