Disclosure of Invention
Technical problem to be solved
In view of the above disadvantages and shortcomings of the prior art, the invention provides an extended storage method of a BIM model, which solves the technical problems of huge volume of BIM files of large buildings, slow analysis speed, long rendering time consumption, difficult loading and transmission and difficult extension.
(II) technical scheme
In order to achieve the above object, an embodiment of the present invention provides an extended storage method for a BIM model:
processing the BIM model scene according to a pre-constructed Json format and/or a database, acquiring and classifying the scene, the scene overall attribute, the material and the BIM attribute information data of the BIM model, and storing the classified data in the form of an independent Json file or database;
processing a BIM model scene according to a pre-constructed binary format, acquiring and classifying camera definition, camera instance, light definition, light instance, fragment instance, geometric metadata and geometric data of the BIM model, and storing the classified data in the form of an independent binary file;
processing a BIM model scene according to a pre-constructed texture mapping list, acquiring and classifying texture mapping data of the BIM model, and storing the classified data in the form of an independent mapping file;
storing file names, file types and file sizes corresponding to the independent Json file or database, the independent binary file and the independent map file according to a pre-constructed asset file list and generating an independent Json file;
performing unidirectional reference between independent files according to a pre-constructed unidirectional reference relationship;
the independent file includes: a standalone Json file or database, a standalone binary file, and a standalone map file.
Optionally, the independent file specifically includes:
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 segment instance list file, a geometric metadata list file, a geometric definition list file, a material list file, a texture map list file, and a BIM attribute list file;
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.
Optionally, the one-way reference between the independent files includes:
the fragment instance list file carries out unidirectional reference on data stored in the BIM attribute list file, the geometric metadata list file and the material list file;
the geometric metadata list file performs one-way reference on data stored in the geometric definition list file;
the texture map list file is used for carrying out one-way reference on data stored in the texture map list file;
the camera instance list file performs one-way reference on data stored in the camera definition list file;
the light instance list file performs one-way reference on data stored in the light definition list file;
the scene integral attribute file carries out one-way reference on data stored in the camera instance list file and the light instance list file;
the scene file carries out unidirectional reference on data stored in an asset file list file, a scene integral attribute file list file and a fragment instance list file;
the attribute class-value pair offset list file performs one-way reference on data stored in the object ID list file;
and the attribute category-value pair list file carries out unidirectional reference on the data stored in the attribute category list file, the value list file and the attribute category-value pair offset list file.
Optionally, the scene overall attribute data stored in the scene overall attribute file includes one or more of the following items:
file version, rendering state, 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.
Optionally, the specific content stored in the asset file list file includes:
the file name, the file type, the original size of the file and the compressed size of the file of the asset file are related;
the file type comprises a format type and a service type.
Optionally, the camera definition list file stores camera definition data including one or more of:
projection mode, position, target, up direction, aspect ratio, field angle, clipping plane and parallel projection scaling factor;
the camera instance data stored by the camera instance list file comprises one or more of the following data:
visibility, camera definition number, pose transformation, instance node path ID;
the light definition data stored in the light definition list file comprises one or more of the following items:
the light example data stored in the light example list file comprises one or more of the following items of position, direction, RGB components of light color, intensity, spotlight angle, size and type:
visibility, light definition number, pose transformation, instance node path ID;
the fragment instance data stored by the fragment instance list file includes one or more of:
visibility, material ID, geometry ID, object ID, pose transformation, bounding box;
the geometry metadata stored by the geometry metadata list file comprises one or more of the following items:
fragment type, primitive number, packID, EntityID;
the geometry data stored by the geometry definition list file comprises one or more of the following items:
geometry type, vertex attributes, patch index, line index.
Optionally, the binary format includes:
organizing the binary file content in a manner of entry type and entry offset;
the entry type includes:
combining the data of the basic data types according to the objects stored in the entries to generate specific entry types;
the basic data types include at least:
unsigned integer unt 8, integer int32, unsigned integer unt 32, variable length integer varint, string, and single precision floating point float 32;
the entry offset comprising:
the offset value of the location of the entry in the binary file relative to the start of the file.
Optionally, the combining the data of the basic data types according to the object stored in the entry to generate a specific entry type specifically includes:
combining data of one or more basic data types to generate a specific item type of an object;
nesting the specific item types of the plurality of objects to generate the specific item type of the complex object.
Optionally, the material object data stored in the material list file includes one or more of the following items:
material object type, diffuse reflection, highlight, ambient light, self-luminescence, gloss, reflectance, opacity, metallization, diffuse reflection mapping, highlight mapping, normal mapping, bump mapping, and transparency mapping.
Optionally, the picture format of the texture map stored in the texture map list file at least includes:
jpg, jpeg, webp, bmp, tif, tiff, hdr, gif, tga and/or png.
(III) advantageous effects
The invention provides an extended storage method of a BIM (building information modeling) model, which is characterized in that data in the BIM model are extracted and classified, the classified data are stored in independent files, and the independent files are subjected to unidirectional reference to realize the integral description of a BIM model scene.
(1) The geometric model is represented by a discrete grid, is stored in a binary format and is split into a plurality of small files, so that asynchronous transmission and loading are facilitated, the geometric model can be directly mapped to a GPU (graphics processing unit) memory, and the geometry, a camera and light all use instantiation technology, so that the data volume is greatly reduced, the transmission and drawing efficiency is improved, and the light-weight use requirement is met;
(2) the geometric objects support triangular meshes, line sets and point cloud types, the BIM attributes support json file storage and database storage, the flexibility is high, the attribute categories can be dynamically added, and the expandability is high;
(3) all files support a compression format, the files have independent version fields, compatibility among different versions is supported, and the files are free to use.
Detailed Description
For the purpose of better explaining the present invention and to facilitate understanding, the present invention will be described in detail by way of specific embodiments with reference to the accompanying drawings. It is to be understood that the following specific examples are illustrative of the invention only and are not to be construed as limiting the invention. In addition, it should be noted that, in the case of no conflict, the embodiments and features in the embodiments in the present application may be combined with each other; for convenience of description, only portions related to the invention are shown in the drawings.
As shown in fig. 1, the present embodiment provides an extended storage method of a BIM model, and the BIM storage method of the present embodiment is named as a3d format, which includes:
processing the BIM model scene according to a pre-constructed Json format and/or a database, acquiring and classifying the scene, the scene overall attribute, the material, the BIM attribute information data and the like of the BIM model, and storing the classified data in the form of an independent Json file or database;
the Json format may be a common JavaScript Object Notification lightweight data exchange format.
Processing a BIM model scene according to a pre-constructed binary format, acquiring and classifying camera definition, camera instance, light definition, light instance, fragment instance, geometric metadata, geometric data and the like of the BIM model, and storing the classified data in the form of an independent binary file;
processing a BIM model scene according to a pre-constructed texture mapping list, acquiring texture mapping data and the like of the BIM model, classifying the texture mapping data and the like, and storing the classified data in the form of an independent mapping file;
and storing the file names, file types and file sizes corresponding to the independent Json file or database, the independent binary file and the independent map file according to a pre-constructed asset file list, and generating the independent Json file.
And performing unidirectional reference between the independent files according to a pre-constructed unidirectional reference relationship.
The independent file includes: an independent Json file or database, an independent binary file, an independent map file, and the like.
And the independent files are referred in a single direction to form the integral description of the BIM scene.
In some specific embodiments, the plurality of independent files form a file set, and the BIM model is stored by the file set.
According to the extended storage method of the BIM, the BIM model scene is processed according to various pre-constructed formats and lists, data is extracted and classified, and the data is stored in an independent file mode, and a unidirectional reference relation exists between independent files, so that integral description of complete BIM is formed. The storage method provided by the invention has the advantages of small file volume, high storage speed, good transmission performance, high drawing efficiency, strong expansibility and the like, and meets the use requirements of a BIM model lightweight system.
As shown in fig. 1 and fig. 2, in the present embodiment, the independent files at least include a scene file, a scene whole 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 geometric metadata list file, a geometric definition list file, a material list file, a texture map list file, a BIM attribute list file, and the like;
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.
One or more independent files can be set according to specific requirements, and the setting is not limited herein.
And the independent files are referred to in a single direction to form a complete BIM model scene.
In some other embodiments, the one-way reference between the plurality of independent files is embodied as:
the fragment instance list file performs unidirectional reference on data stored in a BIM attribute list file, a geometric metadata list file and/or a material list file;
the geometry metadata list file makes unidirectional reference to data stored in the geometry definition list file;
the texture map list file carries out one-way reference on data stored in the texture map list file;
the camera instance list file makes unidirectional reference to data stored in a camera definition list file;
the light instance list file performs one-way reference on data stored in the light definition list file;
the scene integral attribute file carries out one-way reference on data stored in the camera instance list file and/or the light instance list file;
the scene file carries out unidirectional reference on data stored in an asset file list file, a scene integral attribute file list file and/or a fragment instance list file;
the attribute class-value pair offset list file makes unidirectional reference to the data stored in the object ID list file;
the attribute class-value pair list file unidirectionally references data stored in the attribute class list file, the value list file, and/or the attribute class-value pair offset list file.
In practical application, the one-way reference is realized by a reference mode with identification number reference, name reference and the like, instantiation is realized by reference, the size of a file is reduced, the classified management of data is realized, and chaos is avoided.
Specifically, in this embodiment, the scene overall attribute data stored in the scene overall attribute file at least includes the following data: file version, rendering state, 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, and the like.
The rendering state includes whether it is a double-sided rendering geometry.
Of course, in some other embodiments, the scene whole attribute data may further include a self-defined value, which is determined according to the requirement, and is not limited herein.
Specifically, the specific content stored in the asset file list file includes a file name, a file type, a file original size, and a file compressed size of the asset file;
in this embodiment, the file type includes a format type and a service type, and a file parsing processing mode may be determined according to the file type.
The format types are related to file formats, including binary package formats, attribute category formats, ID formats, value formats, attribute category-value pair offset formats, geometric metadata list formats, fragment list formats, and the like.
The service type may include a geometric type, a light definition type, an instance data type, a camera definition type, a geometric metadata type, a fragment data type, and the like, and further include a service type directly determined by a file format, for example, an attribute format is a service type directly determined by a file format.
All the geometry, light and camera types are also regarded as entity types, and are organized in a form of definition + instantiation, where the definition is where the entity is actually stored, and the instantiation is to instantiate the defined entity.
The binary format is a custom format, and comprises the following steps: organizing the binary file content in a manner of entry type and entry offset;
the entry type includes: combining the data of the basic data types according to the objects stored in the entries to generate specific entry types;
the base data types may include one or more of:
unsigned integer unt 8, integer int32, unsigned integer unt 32, variable length integer varint, string, and single precision floating point float 32;
the entry offset comprising:
the offset value of the location of the entry in the binary file relative to the start of the file.
The combining the data of the basic data types according to the objects stored in the entries to generate a specific entry type specifically includes: combining data of one or more basic data types to generate a specific item type of an object; nesting the specific item types of the plurality of objects to generate the specific item type of the complex object.
Specifically, the camera definition list file, each entry representing one camera definition, stores camera definition data including at least the following data: projection mode, position, target, upward direction, aspect ratio, field angle, clipping plane, parallel projection scaling factor, etc.;
the camera instance list file, each entry representing a camera instance, stores camera instance data including at least the following data: visibility, camera definition number, pose transformation, instance node path ID, etc.;
each item of the light definition list file represents a light definition, and the stored light definition data at least comprises the following data: position, direction, RGB components of light color, intensity, spotlight angle, size and type, etc.;
each item of the light instance list file represents a light instance, and the stored light instance data at least comprises the following data: visibility, light definition number, pose transformation, instance node path ID, etc.;
each entry of the fragment instance list file represents a fragment instance, and the stored fragment instance data at least comprises the following data: visibility, material ID, geometry ID, object ID, pose transformation, bounding box, etc.;
the geometry metadata list file, each entry representing a geometry element, stores geometry metadata including at least the following data: fragment type, primitive number, packID, EntityID, etc.;
the geometric definition list file, each item representing a geometric object, stores geometric data including at least the following data: geometry type, vertex attributes, patch index, line index, etc.
Specifically, in this embodiment, there are a plurality of geometric definition list files, which can be read and written in parallel, read and written asynchronously, transmitted in parallel, and transmitted asynchronously. In other embodiments, there may be one or more geometric definition list files, and the geometric definition list files are not limited herein.
In this embodiment, the generating the basic data type of the specific entry type includes:
unsigned integer unt 8, integer int32, unsigned integer unt 32, variable length integer varint, string, single precision floating point 32, and the like. And the data of the one or more basic data types are combined into a specific item type of one object, and the specific item types of the one or more objects are nested and combined to generate a specific item type of the complex object.
In other embodiments, other basic types of data may be added or deleted as desired.
The material object data stored in the material list file at least comprises the following data: material object type, diffuse reflection, highlight, ambient light, self-luminescence, glossiness, reflectance, opacity, metallization, diffuse reflection mapping, highlight mapping, normal mapping, bump mapping, transparency mapping, and the like.
And the diffuse reflection map, the highlight map, the normal map, the concave-convex map and the transparency map are texture data. In other embodiments, other texture data is included, as determined by a specific BIM model, and is not limited herein.
The picture formats of the texture maps stored in the texture map list file comprise jpg, jpeg, webp, bmp, tif, tiff, hdr, gif, tga and/or png and the like.
In practical applications, the texture map is determined by a specific BIM model, which is not limited herein.
Of course, in practical applications, there are other data and picture formats that are not listed, and are determined according to specific requirements, and are not required or limited herein.
In this embodiment, the independent file includes: json type and/or database, binary type and generic picture type, i.e. a stand-alone Json file and/or database, a stand-alone binary file and a stand-alone map file, etc.
In other embodiments, other file types may exist, and are not limited herein.
As shown in fig. 2, fig. 2 shows a related structure of the BIM attribute list file in the embodiment of fig. 1, and in an alternative implementation, the independent files include a scene file, a scene whole 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 geometric metadata list file, a geometric definition list file, a material list file, a texture map list file, and a BIM attribute list file.
The BIM attribute list file comprises 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.
The above independent files may be stored as a file set, and specifically, the files of the file set may exist in a form of single file compression or multiple file combination compression, where the texture map file may be placed in a separate directory, and the entire file set may also be compressed into a compressed file as a whole.
The scene file, the scene integral attribute file, the asset file list file and the material list file are independent Json files in a Json format, and the camera definition list file, the camera instance list file, the light instance list file, the fragment instance list file, the geometric metadata list and the geometric definition list file are self-defined independent binary files.
The storage modes of the object ID list file, the attribute category list file, the value list file, the attribute category-value pair list file and the attribute category-value pair offset list file can be independent json file forms or database forms, and can be selected according to practical application, and the storage modes are not limited here. The object ID list file, the attribute category list file, the value list file, the attribute category-value pair list file, and the attribute category-value pair offset list file are referenced to one another.
In practical application, a plurality of different attribute categories exist, and a user can expand the attribute categories according to requirements.
In this embodiment, the customized binary format includes: the content included in the binary file is organized by the type of the items and the offset of the items, the number of the items is selected according to actual requirements, and the size of each item is independent. The customized binary file can freely contain entries according to requirements, and high expandability is achieved.
The entry type refers to the type of the object stored in the entry, such as a camera type, a light type, a geometric type, and the like.
The entry offset refers to an offset value of the location of the entry in the binary file relative to the start location of the file.
Of course, custom binaries refer to basic data types including: unsigned integer unt 8, integer int32, unsigned integer unt 32, variable length integer varint, string, and single precision floating point float 32. In practical applications, data of one or more basic data types are combined to form a specific entry type according to the characteristics of a specific stored object.
The objects in the binary file are each composed of one or more combinations of data of a basic data type.
For example, in other embodiments, a vertex coordinate data object consists of three single precision floating point numbers float32, although in actual practice there may be a particular entry type where the object is represented by a single datum.
The specific data combination method of the basic data type needs to be determined according to actual needs, and is not limited here.
In a specific application, the combination mode of the objects in the binary file supports nesting, that is, data combination of one or more basic data types generates a specific entry type of one object, and nested combination of specific entry types of a plurality of objects generates more complex object specific entry types.
In this embodiment, the binary file is composed of a file header, entry summary information, an entry type, and entry data.
The file header at least comprises: file type, version number, entry summary information offset.
The item summary information at least comprises: an entry data offset, an entry type list offset.
The entry types at least include: type total, class name list, type number list.
The entry data at least includes: total number of entries, and contents of entries.
In the camera definition list file, each entry represents a camera definition; in the camera instance list file, each entry represents one camera instance; in the light definition list file, each item represents a light definition; in the light instance list file, each item 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; in the geometry definition list file, each entry represents a geometry object.
In practical application, the geometric definition list file can be one or more, and when the geometric definition list file is large, the geometric definition list file can be split into a plurality of Pack files, and the Pack files are named according to the unique Pack ID.
In some embodiments, the geometric elements and geometric objects include triangular meshes, lines, and point types, and triangular mesh geometric objects contain vertex attributes, patch indices, and the like; the line geometric object comprises data such as vertex attribute, line index and the like; the point geometric object contains data such as vertex attributes.
The material list file comprises a material object list, the material object type comprises a Phong material and a PBR material, the Phong material object comprises data such as diffuse reflection, highlight, ambient light, self-luminescence, glossiness, reflectivity, opacity, metallescence and the like, and meanwhile, the material object list file can comprise texture data such as a diffuse reflection map, a highlight map, a normal map, a concave-convex map, a transparency map and the like.
According to the extended storage method of the BIM model, the BIM model is processed, the geometric model is represented by adopting a discrete grid, is stored by using a binary format and is split into a plurality of small files, asynchronous transmission and loading are facilitated, the small files can be directly mapped to a GPU (graphics processing unit) video memory, and the geometry, the camera and the light all use instantiation technology, so that the data volume is greatly reduced, the transmission and drawing efficiency is improved, and the light-weight use requirement is met; the geometric objects support triangular meshes, line sets and point cloud types, the BIM attributes support json file storage and database storage, the flexibility is high, the attribute categories can be dynamically added, and the expandability is high; all files support a compression format, the files have independent version fields, compatibility among different versions is supported, and the files are free to use. Solves the technical problems of huge BIM file volume, slow resolving speed, long rendering time consumption, difficult loading and transmission and difficult expansion of large buildings
As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may 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, and the like) having computer-usable program code embodied therein.
The present 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 flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions.
It should be noted that in the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the claims enumerating several means, several of these means may be embodied by one and the same item of hardware. The use of the terms first, second, third and the like are for convenience only and do not denote any order. These words are to be understood as part of the name of the component.
Furthermore, it should be noted that in the description of the present specification, the description of the term "one embodiment", "some embodiments", "examples", "specific examples" or "some examples", etc., means that a specific feature, structure, material or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.
While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, the claims should be construed to include preferred embodiments and all changes and modifications that fall within the scope of the invention.
It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention should also include such modifications and variations.