An extended storage method of BIM model

Abstract

The application relates to an extended storage method of a BIM model, which comprises processing a BIM model scene, extracting data and storing the data in the form of independent files, wherein the independent files comprise a scene file, a scene overall attribute file, an asset file list file, a camera instance list file, a camera definition list file, a light instance list file, a light definition list file, a fragment instance list file, a geometry metadata list file, a geometry definition list file, a material list file, a texture map list file, an object ID list file, an attribute category list file, a value list file, an attribute category-value pair list file and an attribute category-value pair offset list file. One-way references exist between the independent files, and the one-way references form an overall description of a complete BIM. The storage method provided by the application has the characteristics of small file volume, fast storage speed, good transmission performance, high drawing efficiency and strong expansibility, and meets the use requirements of a BIM model lightweight system.

Description

Technical Field

[0001] This invention relates to the field of BIM model storage, and more particularly to an extended storage method for BIM models. Background Technology

[0002] BIM, short for Building Information Modeling, refers to the digital representation of the physical and functional characteristics of buildings and their facilities in a computer. It provides shared information resources throughout the entire lifecycle of a building project and provides basic information for various decisions. It is widely used in the construction industry.

[0003] Large-scale building BIM models contain tens of thousands of components, resulting in massive model file sizes. These primarily consist of two types of information: geometric model information and BIM attribute information. The geometric model information is extremely large, placing high demands on computer performance and network bandwidth when used directly. Lightweighting is essential for its practical application. BIM attribute information needs to be tailored to different stages of BIM application, encompassing the entire building lifecycle from design and construction to cost accounting and operation and maintenance. Different stages require different attributes, necessitating good scalability to meet diverse attribute needs.

[0004] Existing BIM model storage formats, including .rvt, .dgn, fbx, obj, and step, have drawbacks due to their format characteristics, such as closed methods, information redundancy, slow parsing speed, long rendering time, difficulty in loading and transmission, limited scene selection, and difficulty in expansion, making them inconvenient to use. Summary of the Invention

[0005] (a) Technical problems to be solved

[0006] In view of the above-mentioned shortcomings and deficiencies of the existing technology, the present invention provides an extended storage method for BIM models, which solves the technical problems of large building BIM files being huge in size, slow in parsing speed, long in rendering time, difficult in loading and transmission, and difficult to expand.

[0007] (II) Technical Solution

[0008] To achieve the above objectives, embodiments of the present invention provide an extended storage method for BIM models:

[0009] Based on a pre-built JSON format and / or database, the BIM model scene is processed to obtain and classify the scene, overall scene attributes, materials, and BIM attribute information data of the BIM model. The classified data is then stored in the form of independent JSON files or databases.

[0010] Based on a pre-built binary format, the BIM model scene is processed to obtain and classify the camera definition, camera instance, light definition, light instance, fragment instance, geometric metadata and geometric data of the BIM model. The classified data is then stored in the form of independent binary files.

[0011] Based on a pre-built list of texture maps, the BIM model scene is processed to obtain and classify the texture map data of the BIM model. The classified data is then stored in the form of independent texture files.

[0012] Based on the pre-built list of asset files, the file names, file types, and file sizes corresponding to the independent JSON files or databases, independent binary files, and independent texture files are stored and independent JSON files are generated.

[0013] Based on a pre-built one-way reference relationship, one-way references are made between independent files;

[0014] The independent files include: independent JSON files or databases, independent binary files, and independent texture files.

[0015] Optionally, the independent file specifically includes:

[0016] Scene files, overall scene attribute files, asset file list files, camera instance list files, camera definition list files, light instance list files, light definition list files, fragment instance list files, geometry metadata list files, geometry definition list files, material list files, texture map list files, and BIM attribute list files;

[0017] The BIM attribute list file specifically includes:

[0018] Object ID list file, attribute category list file, value list file, attribute category-value pair list file, attribute category-value pair offset list file.

[0019] Optionally, the one-way reference between the independent files includes:

[0020] The fragment instance list file provides a one-way reference to the data stored in the BIM attribute list file, geometric metadata list file, and material list file.

[0021] The geometry metadata list file provides a one-way reference to the data stored in the geometry definition list file;

[0022] The material list file provides a one-way reference to the data stored in the texture map list file.

[0023] The camera instance list file provides a one-way reference to the data stored in the camera definition list file.

[0024] The light instance list file provides a one-way reference to the data stored in the light definition list file;

[0025] The overall scene attribute file provides a one-way reference to the data stored in the camera instance list file and the light instance list file.

[0026] The scene file provides a one-way reference to the data stored in the asset file list file, the scene overall attribute file list file, and the fragment instance list file.

[0027] The attribute category-value pair offset list file provides a one-way reference to the data stored in the object ID list file;

[0028] The attribute category-value pair list file provides a one-way reference to the data stored in the attribute category list file, the value list file, and the attribute category-value pair offset list file.

[0029] Optionally, the scene-wide attribute data stored in the scene-wide attribute file includes one or more of the following:

[0030] File version, rendering status, navigation method, overall scene bounding box, scene up direction, scene front direction, scene right direction, length unit, default camera number, camera-model transformation, geometric reference.

[0031] Optionally, the specific content stored in the asset file list file includes:

[0032] The file name, file type, original file size, and compressed file size of the asset files are involved.

[0033] The file types include format types and business types.

[0034] Optionally, the camera definition list file stores camera definition data including one or more of the following:

[0035] Projection mode, position, target, upward direction, aspect ratio, field of view, clipping plane, and parallel projection scaling factor;

[0036] The camera instance list file stores camera instance data, including one or more of the following:

[0037] Visibility, camera definition number, pose transformation, instance node path ID;

[0038] The light definition list file stores light definition data, including one or more of the following:

[0039] The light instance list file stores light instance data including one or more of the following: position, orientation, RGB components of light color, intensity, focus angle, size, and type.

[0040] Visibility, light definition number, pose transformation, instance node path ID;

[0041] The fragment instance list file stores fragment instance data, including one or more of the following:

[0042] Visibility, Material ID, Geometric Element ID, Object ID, Pose Transformation, Bounding Box;

[0043] The geometric metadata stored in the geometric metadata list file includes one or more of the following:

[0044] Fragment type, number of primitives, PackID, EntityID;

[0045] The geometric data stored in the geometric definition list file includes one or more of the following:

[0046] Geometry type, vertex attributes, patch index, line index.

[0047] Optionally, the binary format includes:

[0048] Organize the contents of the binary file by entry type and entry offset;

[0049] The entry types include:

[0050] Based on the objects stored in the entries, data of basic data types are combined to generate specific entry types;

[0051] The basic data types include at least:

[0052] Unsigned integer uint8, integer int32, unsigned integer uint32, variable-length integer varint, string, and single-precision floating-point float32;

[0053] The entry offset includes:

[0054] The offset of the entry in the binary file relative to the beginning of the file.

[0055] Optionally, the step of combining basic data types based on the objects stored in the entry to generate a specific entry type specifically includes:

[0056] Combine data of one or more basic data types to generate a specific entry type of an object;

[0057] The specific entry types of the multiple objects are nested to generate a specific entry type of a complex object.

[0058] Optionally, the material list file stores material object data including one or more of the following:

[0059] Material object type, diffuse, specular, ambient light, emissivity, glossiness, reflectivity, opacity, metallicity, diffuse map, specular map, normal map, bump map, and alpha map.

[0060] Optionally, the texture map list file stores texture maps in image formats that include at least:

[0061] jpg, jpeg, webp, bmp, tif, tiff, hdr, gif, tga and / or png.

[0062] (III) Beneficial Effects

[0063] This invention provides an extended storage method for BIM models. It extracts and categorizes data from the BIM model, stores the categorized data in independent files, and allows for one-way referencing between these files to achieve a holistic description of the BIM model scene. This storage method, named in .a3d format, features small file size, fast storage speed, good transmission performance, high drawing efficiency, strong scalability, fast parsing speed, short rendering time, and simple loading and transmission, meeting the requirements of lightweight BIM model systems.

[0064] (1) The geometric model is represented by a discrete mesh, stored in binary format, and split into multiple small files for easy asynchronous transmission and loading. It can be directly mapped to GPU memory. Geometry, camera and light all use instantiation technology, which greatly reduces the amount of data, improves transmission and rendering efficiency, and meets the requirements of lightweight use.

[0065] (2) Geometric objects support triangular mesh, line set and point cloud types. BIM attributes support JSON file storage and database storage, which is highly flexible. Attribute categories can be added dynamically and have strong scalability.

[0066] (3) All files support compression formats and have independent version fields, supporting compatibility between different versions, making them very flexible to use. Attached Figure Description

[0067] Figure 1 This is a schematic diagram of the overall structure of an embodiment of the present invention;

[0068] Figure 2 for Figure 1 A schematic diagram of the relevant structure of the BIM attribute list file in the embodiment. Detailed Implementation

[0069] To better explain and facilitate understanding of the present invention, it is described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described below are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other; for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0070] like Figure 1 As shown, this embodiment provides an extended storage method for BIM models. The BIM storage method in this embodiment is named in .a3d format and includes:

[0071] Based on a pre-built JSON format and / or database, the BIM model scene is processed to obtain and classify the BIM model scene, overall scene attributes, materials, BIM attribute information data, etc., and the classified data is stored in the form of independent JSON files or databases.

[0072] The JSON format can be a general-purpose lightweight data exchange format for JavaScript Object Notation.

[0073] Based on a pre-built binary format, the BIM model scene is processed to obtain and classify camera definitions, camera instances, lighting definitions, lighting instances, fragment instances, geometric metadata, and geometric data of the BIM model. The classified data is then stored in the form of independent binary files.

[0074] Based on a pre-built list of texture maps, the BIM model scene is processed to obtain and classify the texture map data of the BIM model. The classified data is then stored in the form of independent texture files.

[0075] Based on the pre-built list of asset files, the file names, file types, and file sizes corresponding to the independent JSON files or databases, independent binary files, and independent texture files are stored and independent JSON files are generated.

[0076] Based on a pre-built one-way reference relationship, one-way references are made between independent files.

[0077] The independent files include: independent JSON files or databases, independent binary files, and independent texture files, etc.

[0078] The independent files are referenced one-way to form a holistic description of the BIM scene.

[0079] In some specific embodiments, the aforementioned multiple independent files are combined into a file set, which is used to store the BIM model.

[0080] This embodiment provides an extended storage method for BIM models. By processing BIM model scenes according to pre-built multiple formats and lists, data is extracted, categorized, and stored as independent files. These independent files have a one-way referencing relationship, forming a complete overall description of the BIM model. The storage method provided by this invention has advantages such as small file size, fast storage speed, good transmission performance, high drawing efficiency, and strong scalability, meeting the usage requirements of lightweight BIM model systems.

[0081] like Figure 1 and Figure 2 As shown in this embodiment, specifically, the independent files include at least: scene file, scene overall attribute file, asset file list file, camera instance list file, camera definition list file, light instance list file, light definition list file, fragment instance list file, geometry metadata list file, geometry definition list file, material list file, texture map list file, and BIM attribute list file, etc.

[0082] The BIM attribute list file specifically includes an object ID list file, an attribute category list file, a value list file, an attribute category-value pair list file, and an attribute category-value pair offset list file.

[0083] There may be one or more of the aforementioned independent files, depending on specific needs; no restrictions are imposed here.

[0084] The multiple independent files are referenced one-way to form a complete BIM model scene.

[0085] In some other embodiments, the multiple independent files are referenced in a one-way manner, specifically as follows:

[0086] The fragment instance list file provides one-way references to the data stored in the BIM attribute list file, geometric metadata list file, and / or material list file.

[0087] The geometry metadata list file provides a one-way reference to the data stored in the geometry definition list file;

[0088] The material list file provides a one-way reference to the data stored in the texture map list file;

[0089] The camera instance list file provides a one-way reference to the data stored in the camera definition list file;

[0090] The light instance list file provides a one-way reference to the data stored in the light definition list file;

[0091] The overall scene attribute file provides a one-way reference to the data stored in the camera instance list file and / or the light instance list file.

[0092] The scene file provides a one-way reference to the data stored in the asset file list file, the scene overall attribute file list file, and / or the fragment instance list file;

[0093] The attribute category-value pair offset list file provides a one-way reference to the data stored in the object ID list file;

[0094] The attribute category-value pair list file provides a one-way reference to the data stored in the attribute category list file, value list file, and / or attribute category-value pair offset list file.

[0095] In practical applications, the one-way reference is implemented through referencing methods such as identifiable number references and name references. Instantiation is achieved through references, reducing file size, realizing data classification and management, and avoiding confusion.

[0096] Specifically, in this embodiment, the scene overall attribute data stored in the scene overall attribute file includes at least the following data: file version, rendering status, navigation mode, scene overall bounding box, scene up direction, scene front direction, scene right direction, length unit, default camera number, camera-model transformation, geometric reference, etc.

[0097] The rendering state includes whether the geometry is rendered on both sides.

[0098] Of course, in some other embodiments, the overall attribute data of the above-mentioned scenario may also include custom values, which are determined according to the specific requirements and are not limited here.

[0099] Specifically, the asset file list file stores information including the file name, file type, original file size, and compressed file size of the asset files.

[0100] In this embodiment, the file type includes format type and business type, and the file parsing and processing method can be determined based on the file type.

[0101] The format types are related to file formats, including binary package format, attribute category format, ID format, value format, attribute category-value pair format, attribute category-value pair offset format, geometric metadata list format, fragment list format, etc.

[0102] The business types may include geometry types, light definition types, instance data types, camera definition types, geometry metadata types, fragment data types, etc., as well as business types directly determined by the file format. For example, attribute format is a business type directly determined by the file format.

[0103] All geometry, lighting, and camera types are considered entity types and organized in a definition + instantiation format. The definition is where the entity is actually stored, and instantiation is the process of instantiating the defined entity. For example, in this embodiment, the camera definition list is a file that stores camera definitions, and the camera instance list is a file that instantiates cameras.

[0104] The binary format is a custom format, including: organizing the binary file content by entry type and entry offset;

[0105] The entry type includes: combining basic data types based on the objects stored in the entry to generate a specific entry type;

[0106] The basic data type may include one or more of the following:

[0107] Unsigned integer uint8, integer int32, unsigned integer uint32, variable-length integer varint, string, and single-precision floating-point float32;

[0108] The entry offset includes:

[0109] The offset of the entry in the binary file relative to the beginning of the file.

[0110] The step of combining basic data types based on the objects stored in the entry to generate a specific entry type specifically includes: combining one or more basic data types to generate a specific entry type for an object; and nesting the specific entry types of multiple objects to generate a specific entry type for a complex object.

[0111] Specifically, the camera definition list file, where each entry represents a camera definition, stores camera definition data including at least the following: projection mode, position, target, up direction, aspect ratio, field of view, clipping plane, and parallel projection scaling factor, etc.

[0112] The camera instance list file, where each entry represents a camera instance, stores camera instance data including at least the following: visibility, camera definition number, pose transformation, instance node path ID, etc.

[0113] The light definition list file, each entry represents a light definition, and the stored light definition data includes at least the following data: position, direction, RGB components of light color, intensity, focusing angle, size and type, etc.

[0114] The light instance list file, where each entry represents a light instance, stores light instance data that includes at least the following: visibility, light definition number, pose transformation, instance node path ID, etc.

[0115] The fragment instance list file, where each entry represents a fragment instance, stores fragment instance data including at least the following: visibility, material ID, geometric element ID, object ID, pose transformation, bounding box, etc.

[0116] The geometric metadata list file, where each entry represents a geometric element, stores geometric metadata including at least the following data: fragment type, number of elements, PackID, EntityID, etc.

[0117] The geometry definition list file contains entries representing a geometry object, and the stored geometry data includes at least the following: geometry type, vertex attributes, patch index, line index, etc.

[0118] Specifically, in this embodiment, there are multiple geometry definition list files, which can be read and written in parallel, asynchronously, or transmitted in parallel. In other embodiments, there may be one or more geometry definition list files; this is not limited here.

[0119] In this embodiment, the basic data types for generating specific entry types include:

[0120] Unsigned integers (uint8), integers (int32), unsigned integers (uint32), variable-length integers (varint), strings (string), and single-precision floating-point numbers (float32), etc. Data from one or more of these basic data types are combined to form a specific entry type for an object. These specific entry types of one or more objects are nested and combined to generate specific entry types for complex objects.

[0121] In some other embodiments, other basic data types may be added or deleted as needed.

[0122] The material list file stores material object data, including at least the following data: material object type, diffuse, specular, ambient light, emissivity, glossiness, reflectivity, opacity, metallicity, diffuse map, specular map, normal map, bump map, and alpha map.

[0123] The diffuse map, specular map, normal map, bump map, and transparency map mentioned herein are all texture data. In some other embodiments, other texture data may also be included, which are determined by the specific BIM model and are not limited here.

[0124] The texture map list file stores texture maps in image formats including jpg, jpeg, webp, bmp, tif, tiff, hdr, gif, tga, and / or png.

[0125] In practical applications, the texture mapping is determined by the specific BIM model, and no restrictions are imposed here.

[0126] Of course, in practical applications, there are other data and image formats not listed, which are determined according to specific needs, and are not required or restricted here.

[0127] In this embodiment, the independent files include: JSON type and / or database, binary type and general image type, i.e., independent JSON files and / or database, independent binary files and independent texture files, etc.

[0128] In some other embodiments, other file types may also exist, which are not limited here.

[0129] like Figure 2 As shown, Figure 2 It shows Figure 1 In one optional implementation of the BIM attribute list file structure in the embodiments, the independent files include a scene file, a scene overall attribute file, an asset file list file, a camera instance list file, a camera definition list file, a light instance list file, a light definition list file, a fragment instance list file, a geometry metadata list file, a geometry definition list file, a material list file, a texture map list file, and a BIM attribute list file.

[0130] The BIM attribute list file includes an object ID list file, an attribute category list file, a value list file, an attribute category-value pair list file, and an attribute category-value pair offset list file.

[0131] The aforementioned independent files can be stored as a file set. Specifically, the files in the file set can exist as a single compressed file or as a combination of multiple compressed files. The texture mapping files can be placed in a separate directory, and the entire file set can also be compressed into a single compressed file.

[0132] The scene file, the overall scene attribute file, the asset file list file, and the material list file are independent JSON files in JSON format, while the camera definition list file, camera instance list file, light instance list file, fragment instance list file, geometry metadata list, and geometry definition list file are custom independent binary files.

[0133] The object ID list file, attribute category list file, value list file, attribute category-value pair list file, and attribute category-value pair offset list file can be stored as independent JSON files or as a database, depending on the actual application; no restrictions are imposed here. The object ID list file, attribute category list file, value list file, attribute category-value pair list file, and attribute category-value pair offset list file can reference each other.

[0134] In practical applications, there are many different attribute categories, and users can expand the attribute categories according to their needs.

[0135] In this embodiment, the custom binary format includes: organizing the content of the binary file by entry type and entry offset, selecting the number of entries according to actual needs, and ensuring that each entry is of independent size. The custom binary file can freely contain entries as needed, achieving high scalability.

[0136] The entry type refers to the type of object stored in the entry, such as camera type, light type, geometry type, etc.

[0137] The entry offset refers to the offset of the entry's position in the binary file relative to the beginning of the file.

[0138] Of course, the basic data types involved in custom binary files include: unsigned integers (uint8), integers (int32), unsigned integers (uint32), variable-length integers (varint), strings, and single-precision floating-point numbers (float32). In practical applications, data from one or more basic data types are combined to form specific entry types based on the characteristics of the objects being stored.

[0139] The objects in the binary file are all composed of data of one or more basic data types.

[0140] For example, in some other embodiments, a vertex coordinate data object consists of three single-precision floating-point numbers (float32). Of course, in practical applications, there are also specific entry types that represent objects with a single data point.

[0141] The specific combination of basic data types needs to be determined based on actual needs, and no restrictions are imposed here.

[0142] In practical applications, the combination of objects in the binary file supports nesting, that is, the combination of one or more basic data types generates a specific entry type of an object, and the nesting combination of multiple specific entry types of objects generates a more complex specific entry type of an object.

[0143] In this embodiment, the binary file consists of a file header, entry summary information, entry type, and entry data.

[0144] The file header includes at least: file type, version number, and entry summary information offset.

[0145] The summary information of the entries includes at least: entry data offset and entry type list offset.

[0146] The entry type includes at least: total number of types, list of class names, list of type names, and list of type numbers.

[0147] The entry data includes at least: the total number of entries and the specific content of each entry.

[0148] In the camera definition list file, each entry represents a camera definition; in the camera instance list file, each entry represents a camera instance; in the light definition list file, each entry represents a light definition; in the light instance list file, each entry represents a light instance; in the fragment instance list file, each entry represents an instance of a renderable object; in the geometry metadata list file, each entry represents a geometry element; and in the geometry definition list file, each entry represents a geometry object.

[0149] In practical applications, the geometry definition list file can be one or more. When the geometry definition list file is large, it can be split into multiple pack files, named according to a unique packID.

[0150] In some embodiments, the geometric elements and geometric objects include triangular meshes, line and point types. Triangular mesh geometric objects contain data such as vertex attributes and patch indices; line geometric objects contain data such as vertex attributes and line indices; and point geometric objects contain data such as vertex attributes.

[0151] The material list file includes a list of material objects. The material object types include Phong material and PBR material. The Phong material object includes data such as diffuse reflection, specular reflection, ambient light, emissivity, glossiness, reflectivity, opacity, and metallicity. It can also include texture data such as diffuse map, specular map, normal map, bump map, and alpha map.

[0152] This invention discloses an extended storage method for BIM models. The BIM model is processed, and the geometric model is represented by a discrete mesh, stored in binary format, and split into multiple small files for asynchronous transmission and loading. It can be directly mapped to GPU memory. Geometry, cameras, and lights all use instantiation technology, significantly reducing data volume and improving transmission and rendering efficiency, meeting lightweight usage requirements. Geometric objects support triangular mesh, line sets, and point cloud types. BIM attributes support JSON file storage and database storage, offering high flexibility. Attribute categories can be dynamically added, providing strong scalability. All files support compression formats and have independent version fields, supporting compatibility between different versions and offering great flexibility. This method solves the technical problems of large building BIM files, such as huge file size, slow parsing speed, long rendering time, difficult loading and transmission, and limited scalability.

[0153] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0154] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions.

[0155] It should be noted that any reference numerals placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In claims that enumerate several means, several of these means may be embodied by the same hardware. The use of the terms first, second, third, etc., is merely for convenience of expression and does not indicate any order. These terms can be understood as part of the component names.

[0156] Furthermore, it should be noted that in the description of this specification, the terms "one embodiment," "some embodiments," "embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0157] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the claims should be interpreted to include both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0158] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, then this invention should also include these modifications and variations.

Claims

1. An extended storage method of a BIM model, characterized in that, according to a pre-constructed Json format and / or database, a BIM model scene is processed to obtain scene, scene overall attribute, material, BIM attribute information data of the BIM model and classify them, and the classified data is stored in the form of independent Json files or databases; according to a pre-constructed binary format, the BIM model scene is processed to obtain camera definition, camera instance, light definition, light instance, fragment instance, geometry metadata and geometry data of the BIM model and classify them, and the classified data is stored in the form of independent binary files; according to a pre-constructed texture map list, the BIM model scene is processed to obtain texture map data of the BIM model and classify them, and the classified data is stored in the form of independent map files; according to a pre-constructed asset file list, the file name, file type and file size corresponding to the independent Json files or databases, independent binary files and independent map files are stored and an independent Json file is generated; according to a pre-constructed one-way reference relationship, one-way reference between independent files is performed. The independent files include: independent JSON files or databases, independent binary files, and independent texture files, specifically including: scene files, overall scene attribute files, asset file list files, camera instance list files, camera definition list files, light instance list files, light definition list files, fragment instance list files, geometry metadata list files, geometry definition list files, material list files, texture map list files, and BIM attribute list files; the overall scene attribute file stores overall scene attribute data, including one or more of the following: file version, rendering status, navigation method, overall scene bounding box, scene up direction, scene front direction, scene right direction, length unit, and default camera number. The asset file list file stores the following specific contents: file name, file type, original file size, and compressed file size; the file type includes format type and business type; the camera definition list file stores camera definition data including one or more of the following: projection mode, position, target, up direction, aspect ratio, field of view, clipping plane, and parallel projection scaling factor; the camera instance list file stores camera instance data including one or more of the following: visibility, camera definition number, pose transformation, and instance node path ID; the lighting definition list file stores lighting definition data including one or more of the following: position... The light instance list file stores light instance data including one or more of the following: visibility, light definition number, pose transformation, and instance node path ID; the fragment instance list file stores fragment instance data including one or more of the following: visibility, material ID, geometric element ID, object ID, pose transformation, and bounding box; the geometric metadata list file stores geometric metadata including one or more of the following: fragment type, number of primitives, PackID, and EntityID; the geometric definition list file stores geometric data including one or more of the following: geometry type, vertex attributes, and facets. The material list file stores material object data, including one or more of the following: material object type, diffuse, specular, ambient light, emissive, glossiness, reflectivity, opacity, metallicity, diffuse map, specular map, normal map, bump map, and transparency map; the texture map list file stores texture maps in image formats including at least: jpg, jpeg, webp, bmp, tif, tiff, hdr, gif, tga, and / or png; the BIM attribute list file specifically includes: object ID list file, attribute category list file, value list file, attribute category-value pair list file, and attribute category-value pair offset list file; The one-way references between the independent files include: the fragment instance list file, which provides a one-way reference to the data stored in the BIM attribute list file, geometry metadata list file, and material list file; the geometry metadata list file, which provides a one-way reference to the data stored in the geometry definition list file; the material list file, which provides a one-way reference to the data stored in the texture map list file; the camera instance list file, which provides a one-way reference to the data stored in the camera definition list file; the light instance list file, which provides a one-way reference to the data stored in the light definition list file; the scene overall attribute file, which provides a one-way reference to the data stored in the camera instance list file and the light instance list file; the scene file, which provides a one-way reference to the data stored in the asset file list file, the scene overall attribute file list file, and the fragment instance list file; the attribute category-value pair offset list file, which provides a one-way reference to the data stored in the object ID list file; and the attribute category-value pair list file, which provides a one-way reference to the data stored in the attribute category list file, the value list file, and the attribute category-value pair offset list file.

2. The extended storage method for BIM models as described in claim 1, characterized in that, The binary format includes: Organize the contents of the binary file by entry type and entry offset; The entry types include: Based on the objects stored in the entries, the data of basic data types are combined to generate the corresponding entry types; The basic data types include at least: Unsigned integer uint8, integer int32, unsigned integer uint32, variable-length integer varint, string, and single-precision floating-point float32; The entry offset includes: The offset of the entry in the binary file relative to the beginning of the file.

3. The extended storage method for BIM models as described in claim 2, characterized in that, The step of combining basic data types based on the objects stored in the entries to generate corresponding entry types specifically includes: Combine data of one or more basic data types to generate the corresponding entry type of an object; The corresponding entry types of the multiple objects are nested to generate the corresponding entry type of a complex object.

Images