Method, device, program product and medium for realizing lightweight storage of a model

Abstract

This application provides a method, device, program product, and medium for achieving lightweight model storage. By simplifying components, separating the storage of entity tables and type tables, and implementing structured description of file headers, it generates a small-volume lightweight model, which will significantly reduce the storage size of the model. It can also ensure the integrity of the information related to the model and the rationality of the storage structure, thereby greatly satisfying the needs of efficient storage, fast parsing, and flexible transmission.

Description

Technical Field

[0001] This application relates to the field of geometric modeling technology, specifically to a method for achieving lightweight model storage, computer equipment and computer program products, and computer-readable storage media. Background Technology

[0002] Geometric modeling technology has been widely used in fields such as architectural design and industrial manufacturing. Geometric models describe the geometry, component properties, and spatial location of objects to meet the needs of real-world scenarios. However, the complexity and data volume of geometric models increase exponentially with project scale, resulting in massive data volumes that pose a significant challenge to the necessary model storage.

[0003] In existing geometric model storage, all components are usually recorded directly into a single file. This storage structure leads to data redundancy and repeated storage of data, resulting in a large storage volume for geometric models. Summary of the Invention

[0004] One objective of this application is to address the technical problem of the large storage volume of geometric models, and to provide a method, computer device and computer program product, and computer-readable storage medium for achieving lightweight model storage, thereby significantly reducing the storage volume of the model.

[0005] According to one aspect of the embodiments of this application, a method for implementing lightweight model storage is disclosed, the method comprising:

[0006] A lightweight geometric model is obtained by simplifying the components of the geometric model. The lightweight geometric model is a small-volume model of the geometric model.

[0007] By extracting component entity and component type data from the lightweight geometric model, an entity table and a type table corresponding to each component entity type are generated. The entity table is used to record the geometric data of each component entity under the entity type, and the type table is used to record each component type under the instance type.

[0008] A file header is constructed based on the component entity types distributed in the lightweight geometric model and the component types under the component entity types. The entity table and type table are merged and stored through the file header to obtain the geometric model storage file.

[0009] According to one aspect of the embodiments of this application, the step of simplifying the components of the geometric model to obtain a lightweight geometric model includes:

[0010] Classify the component entities in the geometric model to determine the component entities belonging to linear components and the component entities belonging to point components in the geometric model;

[0011] Component simplification is performed on component entities belonging to linear components and point components respectively.

[0012] According to one aspect of the embodiments of this application, classifying the component entities in the geometric model and determining the component entities belonging to linear components and the component entities belonging to point components in the geometric model includes:

[0013] Geometric features are extracted from the component entities in the geometric model, and the geometric features are used to describe the geometric elements contained in the component entities;

[0014] Obtain the corresponding geometric dimensions of the component entity based on its geometric features;

[0015] By matching the dimensions of the geometric bodies, the component entities belonging to linear components and the component entities belonging to point components in the geometric model are determined.

[0016] According to one aspect of the embodiments of this application, the component simplification for component entities belonging to linear components and point components respectively includes:

[0017] For the component entities belonging to linear components in the geometric model, take the outer box to construct a quadtree;

[0018] By checking for collinearity among linear components on the quadtree, collinear linear components with a spacing less than a specified precision are merged.

[0019] According to one aspect of the embodiments of this application, the component simplification for component entities belonging to linear components and point components respectively includes:

[0020] Construct a KD tree for the component entities belonging to point components in the geometric model;

[0021] The KD tree is used to detect overlap of point components, and point components that are adjacent to each other and whose spacing is less than a specified precision are uniquely removed.

[0022] According to one aspect of the embodiments of this application, the extraction of component entity and component type data through a lightweight geometric model to generate an entity table and a type table corresponding to each component entity type includes:

[0023] For each component entity belonging to the same component entity type on the geometric model, extract the component identifier, type identifier, and geometric data of the component entity to generate an entity table.

[0024] According to one aspect of the embodiments of this application, the extraction of component entity and component type data through a lightweight geometric model to generate an entity table and a type table corresponding to each component entity type includes:

[0025] For the type distribution of each component entity under each component entity type on the geometric model, extract the type identifier and type description data corresponding to the distributed type;

[0026] Generate a type table corresponding to the component entity type based on the type identifier and type description data.

[0027] According to one aspect of the embodiments of this application, a computer device is disclosed, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method as described in any of the preceding claims.

[0028] According to one aspect of the embodiments of this application, a computer program product is disclosed, including a computer program that, when executed by a processor, implements the steps of the method as described in any of the preceding claims.

[0029] According to one aspect of the embodiments of this application, a computer-readable storage medium is disclosed having a computer program stored thereon that, when executed by a processor, implements the steps of the method as described in any of the preceding claims.

[0030] This application's embodiments generate a lightweight model with a small size by simplifying components, separating the storage of entity tables and type tables, and implementing structured descriptions of file headers. This significantly reduces the model's storage size and ensures the integrity of all information related to the model and the rationality of the storage structure, thereby greatly satisfying the needs for efficient storage, fast parsing, and flexible transmission.

[0031] Specifically, in this application embodiment, for a given geometric model that needs to be stored, the components are first simplified to obtain a small-volume geometric model. On this basis, the component entities and component type data in the lightweight geometric model are separated to generate entity tables and type tables respectively, realizing modular management and storage of data, thereby effectively reducing data redundancy. Finally, the file header is obtained by using the component entity types and component types of the lightweight geometric model to perform a structured description of the file header. The entity table and type table are then merged and stored to obtain a geometric model storage file with a significantly reduced volume, thereby significantly reducing the storage volume of the model.

[0032] Furthermore, the simplification of geometric model components will ensure that the lightweight geometric model retains the necessary geometric features while minimizing redundancy in details. Compared with existing implementations, this reduces storage volume while avoiding the loss of critical information.

[0033] In lightweight geometric models, the separation of component entity data from component type data, i.e., the separate generation of entity tables and type tables, effectively eliminates data redundancy while also improving storage efficiency and model parsing speed.

[0034] The file header is constructed using the types of component entities distributed on the lightweight geometric model and the component types under those component entities. In other words, the file header includes the types of component entities of the lightweight geometric model and the structural tilt information under those component entities. This allows subsequent file parsing and model reconstruction to quickly locate the components of the model and extract relevant information without traversing the entire file, thereby significantly improving the efficiency of model loading and parsing.

[0035] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0036] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0037] The above and other objectives, features and advantages of this application will become more apparent from a detailed description of exemplary embodiments thereof with reference to the accompanying drawings.

[0038] Figure 1 A flowchart illustrating a method for implementing lightweight storage according to an embodiment of this application is shown.

[0039] Figure 2 It is based on Figure 1 The flowchart shown in the corresponding embodiment describes the steps of simplifying the components of the geometric model to obtain a lightweight geometric model.

[0040] Figure 3 It is based on Figure 2 The flowchart shown in the corresponding embodiment describes the steps of classifying component entities in a geometric model and determining component entities belonging to linear components and component entities belonging to point components in the geometric model.

[0041] Figure 4 It is based on Figure 2 The flowchart shown in the corresponding embodiment describes the steps of simplifying component entities belonging to linear components and point components respectively.

[0042] Figure 5 It is based on Figure 2 The flowchart shown in the corresponding embodiment describes the steps of simplifying component entities belonging to linear components and point components respectively.

[0043] Figure 6 It is based on Figure 1The flowchart shown in the corresponding embodiment describes the steps of extracting component entity and component type data through a lightweight geometric model and generating entity tables and type tables corresponding to each component entity type.

[0044] Figure 7 This is a schematic diagram illustrating the execution process of the simplified model and the stored model derived from an application example.

[0045] Figure 8 It is based on Figure 7 The corresponding embodiment shows a schematic diagram of the process of removing overlapping components and merging adjacent collinear components.

[0046] Figure 9 It is based on Figure 8 A schematic diagram of the overlapping point component shown in the corresponding embodiment.

[0047] Figure 10 It is based on Figure 7 A schematic diagram illustrating the fragment removal process on the geometric model in the corresponding embodiment.

[0048] Figure 11 This is a schematic diagram illustrating the file header structure and the mapping of the file header to the entity table and type table according to an exemplary embodiment.

[0049] Figure 12 This is a schematic diagram of the entity table corresponding to the wall entity according to an exemplary embodiment.

[0050] Figure 13 This is a schematic diagram of the entity table corresponding to a gate entity according to an exemplary embodiment.

[0051] Figure 14 This is a schematic diagram illustrating the BIM model that needs to be stored, according to an exemplary embodiment.

[0052] Figure 15 This is a schematic diagram illustrating the attributes of a geometric model storage file according to an exemplary embodiment. Detailed Implementation

[0053] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided to make the description of this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art. The drawings are merely illustrative of this application and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0054] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more exemplary embodiments. Numerous specific details are provided in the following description to give a full understanding of exemplary embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced with one or more of the specific details omitted, or other methods, components, steps, etc., can be employed. In other instances, well-known structures, methods, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0055] Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0056] This application embodiment is used to obtain a geometric model storage file from the constructed geometric model, so as to persist it on the disk, and thus facilitate parsing and reconstruction based on the persisted geometric model storage file. Therefore, the data volume, that is, the size of the storage volume, determines the storage efficiency and the storage space occupied, and also determines the efficiency of retrieving the geometric model. Therefore, significantly reducing the storage volume of the model is the basis for storage and reuse.

[0057] See Figure 1 , Figure 1 A flowchart illustrating a method for implementing lightweight model storage according to an embodiment of this application is shown. This application provides a method for implementing lightweight model storage, the method comprising:

[0058] Step S110: Simplify the components of the geometric model to obtain a lightweight geometric model, which is a small-volume model of the geometric model.

[0059] Step S120: By extracting component entity and component type data from the lightweight geometric model, an entity table and a type table corresponding to each component entity type are generated. The entity table is used to record the geometric data of each component entity under the entity type, and the type table is used to record each component type under the instance type.

[0060] Step S130: Construct a file header based on the component entity types and component types of the lightweight geometric model distribution, and obtain the geometric model storage file by merging the storage entity table and type table through the file header.

[0061] This step will be explained in detail below.

[0062] First, it should be noted that all geometric models that need to be stored will be obtained through a lightweight model storage implementation to create geometric model storage files. In other words, lightweight geometric models are written to disk through geometric model storage files for later retrieval.

[0063] In step S110, a component simplification operation will be performed on the constructed or imported geometric model if storage is required. The component simplification operation is a process of lightweighting the geometric model. During this process, the complexity, file size, and / or data volume of the model are reduced, making it easier to load, browse, share, and process on different devices or platforms. Especially for BIM (Building Information Modeling) models, the execution of step S110 will effectively improve model performance, particularly in the processing of large-scale models, significantly enhancing their usability and operability.

[0064] Component simplification is performed on all component entities in the geometric model. Specifically, it adapts to both linear and point components, performing simplification on each. This operation includes merging and removing component entities, as well as removing edge fragments from all component entities distributed throughout the geometric model. This effectively merges numerous but similar small component entities into larger, single objects, reducing processing complexity. It also removes unimportant or unnecessary component entities from the model to avoid consuming computational and storage resources.

[0065] For example, component simplification includes classifying component entities in the geometric model, and performing component simplification operations on component entities belonging to each category based on the classification. The component simplification operations include merging and eliminating component entities, and the geometric model has classifications of linear components and point components.

[0066] In summary, component simplification can be categorized, including the classification of component entities and the execution of merging or elimination operations based on the classification.

[0067] Furthermore, for the classification of component entities, the geometric dimensions of each component entity are obtained by extracting geometric features. Then, the category to which the component entity belongs is determined by matching the geometric dimensions of the component entities, clarifying whether the component entity belongs to a linear component or a point component.

[0068] By identifying the category to which a component entity belongs, the storage of the geometric model can be better adapted to different types of component entities, so as to simplify the geometric model with high reliability and efficiency.

[0069] The process of identifying component entities and classifying them into linear or point components involves analyzing, extracting, and categorizing their geometry based on geometric features. This process includes extracting geometric features, calculating the corresponding geometric dimensions based on these features, and finally classifying the component entities into linear or point components by matching the geometric dimensions.

[0070] For details, please refer to [link / reference]. Figure 2 , Figure 2 It is based on Figure 1 The flowchart shown in the corresponding embodiment describes the steps of simplifying the components of the geometric model to obtain a lightweight geometric model.

[0071] The step S110 of the embodiment of this application for obtaining a lightweight geometric model by simplifying the components of the geometric model includes:

[0072] Step S111: Classify the component entities in the geometric model to determine the component entities belonging to linear components and the component entities belonging to point components in the geometric model.

[0073] Step S112: Perform component simplification on the component entities belonging to linear components and point components respectively.

[0074] The following is a detailed explanation of these two steps.

[0075] In step S111, each component entity on the geometric model is reclassified to determine its category. Linear components are component entities with a certain length, direction, and geometric extension. For example, beams, pipes, cables, and tracks in buildings are all linear components. Point components are component entities without significant extension; for example, lighting fixtures, equipment connection points, and support points in buildings are all point components.

[0076] See Figure 3 of, Figure 3 It is based on Figure 2 The flowchart shown in the corresponding embodiment describes the steps of classifying component entities in a geometric model and determining component entities belonging to linear components and component entities belonging to point components in the geometric model.

[0077] The step S111 of classifying component entities in a geometric model and determining component entities belonging to linear components and point components in the geometric model, provided in this embodiment of the application, includes:

[0078] Step S1111: Extract geometric features from the component entities in the geometric model. The geometric features are used to describe the geometric elements contained in the component entities.

[0079] Step S1112: Obtain the corresponding geometric dimensions of the geometric features of the several component entities;

[0080] Step S1113: By matching the geometric dimensions, determine the component entities belonging to linear components and the component entities belonging to point components in the geometric model.

[0081] These steps are explained in detail below.

[0082] First, it should be noted that geometric features are used to describe the geometric elements on a component entity. Geometric elements include, but are not limited to, basic units such as points, lines, and surfaces. Geometric features are key features for calculating component entities, such as the boundary frame, center point, start point, and end point of the component entity, which are not limited here.

[0083] The extracted geometric features are adapted to the desired classification of linear and point components, and corresponding geometric dimensions are obtained. For example, geometric dimensions include at least one of size, position, shape, orientation, length, and area. The obtained geometric dimensions can clearly determine whether a component entity belongs to a linear or point component.

[0084] For example, if the obtained geometric dimension has a clear start and end position and a length, it can be matched that the geometric dimension describes a linear component, and the corresponding component entity should be classified as a linear component.

[0085] If the obtained geometric dimension has only one position, then the geometric dimension described is a point component, and the corresponding component entity should be classified as a point component.

[0086] To facilitate rapid matching of geometric dimensions, thresholds can be set for each geometric dimension. The set thresholds include a minimum length threshold corresponding to the length in the geometric dimension and a positional precision corresponding to the location. Thus, component entities below the minimum length threshold can be classified as point components, and the positional precision can be used to determine whether a component entity is a point or a small area, ensuring the speed and accuracy of component entity classification.

[0087] After classifying the component entities, component simplification can be performed according to the classification, as in step S112. The component simplification process for component entities belonging to linear components and point components is as described above, including merging and culling operations.

[0088] See Figure 4 , Figure 4 It is based on Figure 2The flowchart shown in the corresponding embodiment describes the steps of simplifying component entities belonging to linear components and point components respectively.

[0089] The step S112 provided in this application embodiment for simplifying component entities belonging to linear components and point components respectively includes:

[0090] Step S1121a: Take the outer box of the component entities belonging to linear components in the geometric model and construct a quadtree;

[0091] Step S1122a: Merge linear components with collinear adjacent spacing less than a specified precision by checking for collinearity between linear components on the quadtree.

[0092] The following is a detailed explanation of these two steps.

[0093] Based on the quadtree, all linear components in the geometric model, such as walls and beams, are checked for collinearity. If consecutive collinear adjacent component entities are detected with a spacing less than a specified precision, they are merged.

[0094] A bounding box is the smallest cuboid that covers the spatial extent of a linear component. For example, the bounding box completely encloses all vertices of the linear component. A quadtree is used to store the corresponding bounding box of a linear component in three-dimensional space in a tree-like structure.

[0095] By constructing a quadtree, all linear components of the geometric model exist in the quadtree through the existence of outer boxes, thus enabling collinearity checks between linear components on the quadtree.

[0096] The execution process of constructing a quadtree based on bounding boxes for linear components includes: initializing the quadtree based on all linear components, and allocating bounding boxes for each linear component in the initialized quadtree.

[0097] It should be understood that a root node is created for each linear component of the geometric model. The area of ​​the root node will encompass the space occupied by the outer boxes of all linear components on the geometric model. For example, this space can be a sufficiently large cuboid. After adapting the quadtree to the geometric model, nodes are assigned to the outer boxes of each linear component on the geometric model to obtain a quadtree that separates the outer boxes of all linear components.

[0098] Thus, by using the quadtree to perform proximity collinearity checks on linear components in the geometric model, the comprehensiveness of the proximity collinearity checks is ensured, i.e., efficient and reliable coverage of all linear components in the geometric model. On the other hand, the efficiency of the proximity collinearity checks is also guaranteed.

[0099] The collinearity check refers to checking whether linear components in the geometric model are spatially collinear and whether the distance between them is less than a specified precision. If linear components are spatially collinear and the distance between them is less than the specified precision, they are considered to be collinear and a merging operation will be initiated.

[0100] By analogy, a collinearity check can be performed on all linear components, thereby merging collinear and adjacent linear components.

[0101] For component entities belonging to point components, overlap detection will be used to determine whether there are overlapping point components, and then the overlapping point components will be uniquely removed.

[0102] Please also see Figure 5 , Figure 5 It is based on Figure 2 The flowchart shown in the corresponding embodiment describes the steps of simplifying component entities belonging to linear components and point components respectively.

[0103] The step S112 provided in this application embodiment for simplifying component entities belonging to linear components and point components respectively includes:

[0104] Step S1121b: Construct a KD tree for the component entities belonging to point components in the geometric model;

[0105] Step S1122b: Overlap detection of point components is performed using a KD tree. Point components that are adjacent to each other and have a spacing less than a specified precision are uniquely removed.

[0106] The following is a detailed explanation of these two steps.

[0107] First, it should be noted that KD (k-dimensional tree) is used to store and organize point data in multidimensional space, that is, the geometric data corresponding to point components, so that the overlap detection performed on point components on the geometric model can achieve efficient query and search.

[0108] For component entities belonging to point components in the geometric model, a KD-tree is constructed to detect overlapping point components. Overlapping can also be understood as duplicate point components. Duplicate point components are removed, retaining only the unique point component, thereby eliminating redundant data in the geometric model. This approach avoids redundancy and duplication while ensuring data integrity, accuracy, and efficiency.

[0109] In another implementation embodiment, in addition to simplifying the geometric model based on the category to which the component entity belongs, i.e., based on linear components and point components, edge fragment models distributed on the geometric model will also be identified and then eliminated.

[0110] Specifically, the execution process of step S110 also includes: obtaining the corresponding three-dimensional cube outer box for each component entity of the geometric model, forming a point set of the component entity from the three-dimensional cube outer box; performing density clustering of the component entities based on the point set, locating the component entities outside the cluster as edge fragment models; and removing the edge fragment models distributed on the geometric model.

[0111] Edge fragmentation models refer to irregular, fragmented, and inaccurate representations of certain parts of a geometric model, mostly external edges or boundaries. These parts often affect the accuracy and usability of the geometric model. Therefore, identifying and eliminating edge fragmentation models can effectively reduce the data volume while also improving the quality of the geometric model.

[0112] Specifically, all component entities in the geometric model will be traversed, and the 3D cube bounding box of each component entity will be calculated. For example, the 3D cube bounding box calculated for the component entity is defined by the maximum and minimum values ​​of the point coordinates, which constitutes the point set of the component entity.

[0113] For each component entity's point set, a density-based clustering algorithm is used to cluster them to obtain the clustering results. For example, the clustering structure will assign a cluster label to each component entity. Component entities with the same cluster label belong to the same cluster, and component entities that are not in any cluster are considered edge fragments and need to be removed.

[0114] This enables rapid localization of edge fragment models on the geometric model, which is applicable to the batch processing of fragmented components in large-scale geometric models without manual intervention, while preserving the main component entities, improving the data integrity of the geometric model, and avoiding excessive culling.

[0115] For example, remove fragmented components that do not affect the core functionality of the model, such as isolated walls at the edges and pipeline remnants.

[0116] After removing edge fragments from the model, the overall storage capacity of the model is significantly reduced, making it particularly suitable for lightweight storage requirements. This reduces the number of irrelevant components, lowers the computational complexity of the optimized model, and improves rendering speed and simulation efficiency.

[0117] With the simplification of components on the geometric model completed, step S120 will generate entity tables and type tables for the simplified lightweight geometric model, realizing the separate storage of geometric data of each component entity and the type of each component. This effectively eliminates data redundancy and also improves storage efficiency and model parsing speed.

[0118] In step 120, on the one hand, an entity table is generated for the component entities distributed on the lightweight geometric model, and on the other hand, a type table is generated for all component types.

[0119] Understandably, for each component entity type existing in the lightweight geometric model, geometric data of the component entities under that component entity type is extracted to generate an entity table. For each component entity under each category, its type description data is extracted to generate a type table.

[0120] Each component entity type has its own entity table, which records the geometric data of each component entity under that component entity type. That is, each data entry corresponds to a component entity under that component entity type. In other words, the component identifier, the type identifier, and the geometric data of the component entity constitute a data entry. By analogy, all data entries under that component entity type form an entity table.

[0121] The solid surface faces all component entities under a component entity type, records the geometric data of each component entity, as well as the component type to which the component entity belongs under this component entity type, without needing to store the type description data of the component type, thereby avoiding the repeated storage of type description data and avoiding the resulting redundancy.

[0122] The component type also corresponds to a component entity type. That is, a component entity type has at least one component type. Therefore, a type table will be generated for each component entity type to record the component types contained in that component entity type, as well as the type description data of each component type.

[0123] By constructing entity tables and type tables separately, different data are stored in an orderly manner. For a component entity type, the entity table specifically stores the geometric data related to the component entity, while the type table specifically stores the data of each component type. This allows for quick location of the geometric data of a specific entity and the type description data of a specific type during operation, thereby improving processing efficiency.

[0124] Furthermore, as mentioned above, separating the geometric data associated with the component entity from the type description data and storing them separately can avoid repeatedly storing the type description data in the data entry of each component entity in the entity table. By centrally managing the component type through the type table, it is only necessary to store the type identifier in the entity table to map it to the corresponding type description data in the type table. There is no need to repeatedly describe the component type of each component entity, which helps to reduce storage space and redundant data.

[0125] On the other hand, with the lightweighting and reuse of geometric models, changes in component types are often involved. At this point, expansion and adjustment can be easily and quickly made by maintaining a separate type table, adding new component types without modifying the data of each component entity.

[0126] Based on this, in an exemplary embodiment, the execution process of step S120 includes: extracting the component identifier, the type identifier, and the geometric data of each component entity belonging to the same component entity type on the geometric model to generate an entity table.

[0127] Furthermore, an index is first constructed for the distribution of each component entity of the corresponding component entity type. The component identifier, type identifier, and geometric data of the corresponding component entity are linearly stored using the index of each component entity to obtain the data entries of each component entity. The data entries of all component entities of the same component entity type form an entity table.

[0128] Each component entity type corresponds to a set of stored data, which consists of various parameters from the geometric data. For example, in a wall entity table, each wall entity stores various parameters from the geometric data, such as the start and end coordinates, wall width, and wall type identifier; in a door entity table, each door entity also stores various parameters from the geometric data, such as the midpoint coordinates, door width and height, and door type identifier.

[0129] In another exemplary embodiment, see also Figure 6 , Figure 6 It is based on Figure 1 The flowchart shown in the corresponding embodiment describes the steps of extracting component entity and component type data through a lightweight geometric model and generating entity tables and type tables corresponding to each component entity type.

[0130] The step S120 of extracting component entity and component type data through a lightweight geometric model and generating entity tables and type tables corresponding to each component entity type provided in this embodiment includes:

[0131] Step S121: Extract the type identifier and type description data corresponding to the distributed types of each component entity under each component entity type on the geometric model.

[0132] Step S122: Generate a type table corresponding to the component entity type based on the type identifier and type description data.

[0133] The following is a detailed explanation of these two steps.

[0134] In step S121, as described above, each component entity type has at least one component type, and each component type is uniquely identified by a type identifier and defined by the corresponding type description data. For example, the type description data can be the attributes of the component type. For instance, for a wall entity, its type description data includes attributes in several dimensions such as fire resistance rating, material, and purpose.

[0135] In step S122, each component type of a component entity type is represented by a data entry for that component type through its corresponding type identifier and type description data. By analogy, the data entries for all component types of a component entity type can form the type table corresponding to that component entity type.

[0136] In summary, the execution process of step S122 includes: constructing indexes for each component type based on the type distribution of component entity types; obtaining data entries for each component type by linearly storing the corresponding type identifiers and type description data using the indexes of each component type; and forming a type table by storing the data entries of all component types of the same component entity type.

[0137] As step S120 proceeds, an entity table and a type table are generated for the lightweight geometric model. Then, step S130 is executed to construct a file header. The entity table and type table are merged and stored through the mapping of the file header to the entity table and type table to obtain the geometric model storage file.

[0138] In step S130, the file header marks the lightweight geometric model with structured table segments. Specifically, it marks the entity table field and type table field corresponding to the types of component entities on the lightweight geometric model, and then maps the entity table field to the entity table and the type table field to the type table. Finally, the entity table and type table are merged and stored.

[0139] The entity table fields constitute the field table segment of the file header, and the type table fields constitute the type table segment of the file header, thus obtaining the structure of the file header.

[0140] In an exemplary embodiment, the execution process of step S130 includes: configuring type table segments and entity table segments according to the distribution of component entity types on the lightweight model; using type table segments and entity table segments as file headers, and merging and storing entity tables and type tables to obtain a geometric model storage file by mapping type table segments to type tables and entity table segments to entity tables.

[0141] In the file header, the type table segment includes type table fields corresponding to several component entity types, and the entity table segment includes entity table fields corresponding to several component entity types. Each type table field points to the corresponding type table, and each entity table field points to the corresponding entity table, thus enabling the merging and storage of type tables and entity tables under this architecture.

[0142] By adopting the distribution of component entity types on the lightweight geometric model, configuring type table segments and entity table segments, and mapping type table segments to type tables and entity table segments to entity tables through file headers, the entity tables and type tables are merged and stored to obtain the geometric model storage file. This greatly reduces the storage of duplicate data, avoids redundant information caused by scattered storage, and saves storage space.

[0143] The mapping of the file header table segment provides a clear index structure, which enables the target data in the type table and entity table to be quickly located during file parsing, reducing traversal and search time and speeding up model loading and operation.

[0144] The configuration table segment and merged storage method are highly consistent with the goal of lightweight storage, which reduces the size of stored files while preserving the integrity and hierarchical structure of model data, realizing lightweight storage of geometric models and providing support for low-performance devices (such as mobile devices).

[0145] Furthermore, the execution process of configuring type table segments and entity table segments based on the distribution of component entity types on the lightweight model includes:

[0146] Generate entity table fields for each component entity type and type table fields for each component entity type based on the distribution of component entity types in the lightweight model.

[0147] All entity table fields are formed into the entity table segment in the file header, and type table fields are formed into the type table segment in the file header.

[0148] By separating the storage of entity table fields and type table fields, the model data is clearly divided into two parts: component entities and component types, forming a structured data storage method. The entity table fields only store the geometric data of the component entities, while the type table fields store shared attributes, extracting duplicate attribute information into the type table to avoid redundant storage.

[0149] For model loading and parsing, the entity table segment and type table segment in the file header provide clear indexes, which enable the target data to be quickly located during model parsing. The structured storage also accelerates the model loading and parsing process.

[0150] In another exemplary embodiment, upon obtaining the geometric model storage file, the method as described above further includes:

[0151] The compressed geometric model storage file is persistently saved on disk. The geometric model storage file that has been persistently saved on disk is used for the reconstruction of the geometric model.

[0152] At this point, the storage of the geometric model is complete, that is, it is stored on the disk in the form of a compressed geometric model storage file. If the model needs to be restored, the geometric model storage file that has been persistently stored on the disk is decompressed to obtain the parsable data content.

[0153] Based on the byte order of the parsed data, obtain the geometric data of each component entity under each component entity type and the type description data of the corresponding component type;

[0154] The corresponding component model is reconstructed based on the geometric data and type description data, and the reconstructed component model forms the geometric model.

[0155] In summary, by parsing and reconstructing, the model can be quickly restored, and parsing and reconstruction are only performed when needed, reducing long-term disk space occupation. In cross-platform or remote collaborative work, the transfer of lightweight files is faster, and the model can be directly restored on the target device after decompression.

[0156] Decompression and parsing are performed byte-by-byte, allowing for the gradual loading of necessary data and avoiding the need for parsing and loading the entire dataset, thus improving efficiency. Geometric data and type description data are stored separately in the storage file and read according to byte order, resulting in a clear data structure and reducing the risk of data confusion during the reconstruction process. The relationship between geometric data and type description data can accurately locate the types and attributes of entity components, ensuring the accuracy of the reconstructed model.

[0157] The method described above will be illustrated below with a specific example.

[0158] Taking BIM models as an example, they are characterized by their large size, numerous components, and many triangular faces. As a result, the file size of a BIM model can reach hundreds of megabytes, which will result in significant economic and time costs for storage and transmission. Therefore, the method of this application is needed to achieve lightweight BIM model storage, which can greatly reduce the file size while retaining all model information and details.

[0159] See Figure 7 , Figure 7 This is a schematic diagram illustrating the execution process of the simplified model and the storage model based on an application example.

[0160] In this process, in order to simplify the model, the topological information and triangular face data of the geometric model will not be retained, and the project data and geometric data will be separated in a fundamental way to significantly reduce the amount of storage.

[0161] exist Figure 7 The execution process shown involves sequentially performing several steps, including automatic removal of redundant components, component grouping, table storage merging, and compression. The resulting entity table does not store the complex topological structure and rich geometric details of the 3D geometric topology; only the geometric data, i.e., the coordinates of geometric points, is retained.

[0162] exist Figure 7 The component collection process involves collecting the component entities contained in the geometric model of the scene to obtain the component entities existing in the geometric model and their respective component entity types.

[0163] Based on this, overlapping components are removed, adjacent collinear components are merged, and redundant fragment components are removed to obtain a lightweight geometric model.

[0164] The execution process of removing overlapping components and merging adjacent collinear components is as follows: Figure 8 As shown, Figure 8 It is based on Figure 7 The corresponding embodiment shows a schematic diagram of the process of removing overlapping components and merging adjacent collinear components.

[0165] It should be understood that overlapping component removal can be achieved by constructing a KD tree for point components to perform duplicate checks. For example, overlapping checks can be performed on all point components such as doors and windows. If overlapping components are detected to be adjacent to each other and the distance between them is less than a specified precision, they can be uniquely removed. Figure 9 As shown.

[0166] In addition to point components, overlap checks can also be performed on linear components. For example, all walls will be scanned, and walls that overlap will be identified and invalid walls will be removed.

[0167] For the collinearity check of linear components, a quadtree is used to quickly check all linear components in the geometric model, such as all walls and beams, for collinearity. If continuous collinearity is detected and the spacing is less than the specified precision, they are merged.

[0168] In addition to removing overlapping components and merging adjacent collinear components, fragment removal will also be performed on the geometric model. Figure 10 It is based on Figure 7 A schematic diagram illustrating the fragment removal process on the geometric model in the corresponding embodiment.

[0169] In this process, firstly, the three-dimensional cube outer box of all components is obtained on the geometric model. Then, the eight vertices of each of the three-dimensional cube outer boxes are taken to form a three-dimensional point set. The DBSCAN clustering algorithm is used to perform density clustering on the point set to form N clusters. Components outside the clusters are regarded as edge fragment models and need to be removed.

[0170] This is used to obtain a lightweight geometric model. The component types under all entity component categories are collected for this lightweight geometric model to generate a type table and an entity table.

[0171] The component file header, consisting of a type table section and an entity table section, such as... Figure 11 As shown, the section between the start and end markers of the type table is the type table segment, and the section between the start and end markers of the entity table is the entity table segment. Entity table segments are mapped to various entity tables, such as the wall entity table, and type table segments are mapped to various type tables, such as the wall type table.

[0172] The file header stores basic model information such as model version and time, and maps the data through the pointers of entity table fields and type table fields.

[0173] The mapped entity table is used to store the corresponding component entities, such as... Figure 12 The wall entity shown is stored as follows. The wall entity will only retain geometric data, namely the start and end coordinates, width, and wall type identifier (ID), and will be mapped to the corresponding wall type through the wall type identifier.

[0174] like Figure 12 The stored content is "0, 0, 0, 0, 1000, 0, 200, 1001", occupying only 23 bytes of space.

[0175] like Figure 13 The storage of the door entity shown only stores the midpoint coordinates, door width and height, and door type ID.

[0176] Based on this, the geometric model storage files obtained by merging and storing are... Figure 14 The constructed BIM model is stored, and the resulting file size is as follows: Figure 15 The result is only 938,528 bytes, a significant reduction of 30% compared to existing implementations.

[0177] In one exemplary embodiment, this application also provides a computer device including a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to implement the steps of the method as described above.

[0178] In one exemplary embodiment, this application also provides a computer program product including a computer program that, when executed by a processor, implements the steps of the method as described above.

[0179] In one exemplary embodiment, this application also provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of the method as described above.

[0180] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the method according to the embodiments of this application.

[0181] In an exemplary embodiment of this application, a computer program medium is also provided, on which computer-readable instructions are stored, which, when executed by a computer's processor, cause the computer to perform the methods described in the above method embodiments.

[0182] According to one embodiment of this application, a program product for implementing the methods in the above-described method embodiments is also provided. This product may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of this invention is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0183] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0184] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0185] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0186] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0187] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0188] Furthermore, although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0189] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0190] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the appended claims.

Claims

1. A method for achieving lightweight model storage, characterized in that, The method includes: A lightweight geometric model is obtained by simplifying the components of the geometric model. The lightweight geometric model is a small-volume model of the geometric model. The process of simplifying the geometric model to obtain a lightweight geometric model includes: classifying the component entities in the geometric model to determine the component entities belonging to linear components and the component entities belonging to point components; simplifying the component entities belonging to linear components and point components respectively; constructing a quadtree by taking the outer boxes of the component entities belonging to linear components in the geometric model; merging collinear linear components with a spacing less than a specified precision by checking for proximity collinearity between linear components in the quadtree; performing an overlap check on the linear components, scanning all walls, judging the overlapping walls, and removing invalid walls; constructing a KD tree for the component entities belonging to point components in the geometric model; performing overlap detection on point components through the KD tree, and uniquely removing point components that are adjacent to each other and have a spacing less than a specified precision; wherein the overlap is a duplicate point component, the duplicate point components will be removed, and only one point component will be retained. It also includes: obtaining the corresponding three-dimensional cube outer box for each component entity of the geometric model, forming a point set of the component entity from the three-dimensional cube outer box; performing density clustering of the component entities based on the point set, locating the component entities outside the cluster as edge fragment models; removing edge fragment models distributed on the geometric model; and not retaining the topological information and triangular face data of the geometric model. By extracting component entity and component type data from the lightweight geometric model, an entity table and a type table are generated for each component entity type. The entity table records the geometric data of each component entity under its entity type, and the type table records each component type under the entity type. Each component entity type has at least one component type, and each component type is uniquely identified by a type identifier and defined by the corresponding type description data. The wall entities in the entity table only retain geometric data, including the start and end coordinates, width, and wall type identifier. The type description data in the type table includes fire resistance rating, material, and purpose. A file header is constructed based on the component entity types distributed in the lightweight geometric model and the component types under the component entity types. The entity table and type table are merged and stored through the file header to obtain the geometric model storage file.

2. The method according to claim 1, characterized in that, The step of classifying the component entities in the geometric model, and determining the component entities belonging to linear components and the component entities belonging to point components in the geometric model, includes: Geometric features are extracted from the component entities in the geometric model, and the geometric features are used to describe the geometric elements contained in the component entities; Obtain the corresponding geometric dimensions of the component entity based on its geometric features; By matching the dimensions of the geometric bodies, the component entities belonging to linear components and the component entities belonging to point components in the geometric model are determined.

3. The method according to claim 1, characterized in that, The step of extracting component entity and component type data from the lightweight geometric model to generate entity tables and type tables corresponding to each component entity type includes: For each component entity belonging to the same component entity type on the geometric model, extract the component identifier, type identifier, and geometric data of the component entity to generate an entity table.

4. The method according to claim 1, characterized in that, The step of extracting component entity and component type data from the lightweight geometric model to generate entity tables and type tables corresponding to each component entity type includes: For the type distribution of each component entity under each component entity type on the geometric model, extract the type identifier and type description data corresponding to the distributed type; Generate a type table corresponding to the component entity type based on the type identifier and type description data.

5. A computer device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-4.

6. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1-4.

7. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1-4.

Images