Data interaction method and system for webpage three-dimensional scene

Abstract

The application relates to the technical field of webpage three-dimensional data processing, and discloses a webpage three-dimensional scene data interaction method and system, wherein the data interaction method is characterized in that, when a three-dimensional scene is constructed based on Three.js, a model file of a webpage is stored, or a module file of the webpage, a three-dimensional scene file of the webpage are constructed based on the model file of the webpage and are stored; wherein the relationship among data information of the model, the module and the three-dimensional scene is decoupled and stored in categories when the data information is stored. The application solves the problems of long data storage and loading time, large resource consumption, low reliability and easy collapse existing in the prior art.

Description

Technical Field

[0001] This invention relates to the field of web page 3D data processing technology, specifically a data interaction method and system for web page 3D scenes. Background Technology

[0002] With the improvement of terminal device performance, the construction of 3D model scenes in web pages has become widely used. When building 3D scenes based on Three.js, a series of data are required to complete the display of the entire 3D scene, including model files, model parameters, scene background, and non-model construction parameters. How this data is stored and retrieved directly affects the efficiency of 3D scene construction.

[0003] However, existing technologies have the following problems: data storage and loading are very time-consuming, and the resources consumed during storage and loading are too large, resulting in low reliability and easy crashes. Summary of the Invention

[0004] To overcome the shortcomings of existing technologies, this invention provides a data interaction method and system for web page 3D scenes, solving problems such as long data storage and loading time, high resource consumption, low reliability, and easy crashes in existing technologies.

[0005] The technical solution adopted by the present invention to solve the above problems is:

[0006] A data interaction method for web page 3D scenes, based on Three.js, stores the web page model file or constructs and stores the web page module file and 3D scene file based on the web page model file; wherein, during storage, the relationship between the data information of the model, module and 3D scene is decoupled and stored in categories.

[0007] As a preferred technical solution, a web page data interaction system is used for storage. This system includes a data interaction control module, and further includes a relational data storage module, a non-relational data storage module, a shared data control module, a file storage module, and a data operation module, all communicatively connected to the data interaction control module. The data operation module stores the web page model files, and the methods for storing these model files include one or more of model uploading, model sharing, and model loading. Model uploading includes the following steps:

[0008] XS1 allows users to upload model information packages to the data interaction control module via a data terminal. The model information package includes: basic information defined by the user for the model, default parameters of the model, and the model file.

[0009] After receiving the uploaded data, the XS2 data interaction control module decomposes the received data packet into corresponding data information through the parameters defined by the interface, and obtains the basic model information, default model parameters, and model file information.

[0010] As a preferred technical solution, model sharing includes the following steps:

[0011] XG1 allows users to select their uploaded models on the data terminal and define sharing rules; the sharing rule information includes the model's basic information ID, sharing type, sharing user ID, and sharing organization ID.

[0012] XG2, after the sharing rules are defined, submit them to the data interaction control module, and the database interaction module will first verify the sharing rules;

[0013] After verification, XG3 will pass the sharing rules to the shared data control module for storage.

[0014] XG4, the shared data control module receives the shared rules and writes or updates the shared rules for the model based on the shared model ID.

[0015] As a preferred technical solution, during model loading, users load their own uploaded models through the data interaction control module on their terminal devices, while also loading their shared models.

[0016] As a preferred technical solution, a data operation module is used to store the module files of the webpage. The module files of the webpage include one or more of the following: module construction, module sharing, and module loading. Among them, module construction refers to performing module construction operations on the model. Module construction requires two or more models. The model is loaded to the terminal device through the model loading step, and the module construction is completed through the module storage step. The module information is stored through a relational data storage module.

[0017] As a preferred technical solution, module sharing includes the following steps:

[0018] ZG1 allows users to select their own built modules on the data terminal and define sharing rules; the sharing rule information includes the module's basic information ID, sharing type, sharing user ID, and sharing organization ID.

[0019] ZG2, once defined, submits the shared information to the data interaction control module, which then verifies the shared information first. The data interaction control module can call the relational data storage module for verification.

[0020] ZG3, after verification, transmits the sharing rule information to the shared data control module for storage;

[0021] ZG4, the shared data control module receives the shared rule information and writes or updates the shared rules of the module according to the ID of the shared module's basic information.

[0022] As a preferred technical solution, when loading a module, the user loads their own built module through the data interaction control module on the terminal device, while also loading the shared modules they own.

[0023] As a preferred technical solution, a data operation module is used to store the 3D scene file of the webpage. The storage of the 3D scene file of the webpage includes one or more of the following: 3D scene upload, 3D scene sharing, and 3D scene loading. The 3D scene file is constructed in the following way: the 3D coordinates, length, width, height, and custom parameters of the model are saved in JSON format, along with the model file loading path, thereby obtaining a 3D scene file containing 3D scene data.

[0024] As a preferred technical solution, 3D scene sharing includes the following steps:

[0025] SG1: Users select their self-constructed 3D scene scheme information on the data terminal and define sharing rules; the sharing rule information includes the scheme basic information ID, sharing type, sharing person ID, and sharing organization ID;

[0026] SG2, once defined, submits the shared information to the data interaction control module, where the database interaction module first verifies the shared information; the data interaction control module can call the relational data storage module for verification.

[0027] After verification, SG3 transmits the sharing rule information to the shared data control module for storage.

[0028] SG4, the shared data control module receives the shared rule information and writes or updates the shared rules of the model according to the ID of the basic information of the shared scheme.

[0029] A data interaction system for a webpage 3D scene is provided to implement the aforementioned data interaction method for a webpage 3D scene. When the data interaction system for a webpage 3D scene is working, it stores the webpage model file or constructs and stores the webpage module file and the webpage 3D scene file based on the webpage model file during the 3D scene construction based on Three.js. In the storage process, the relationships between the data information of the model, module, and 3D scene are decoupled and classified for storage.

[0030] Compared with the prior art, the present invention has the following advantages:

[0031] (1) When constructing a 3D scene based on Three.js, this invention saves the data of the model, module and scene in a specific way, decouples the relationship between information in the saving, loading and sharing, simplifies the combination, classifies and stores the data, so that the data can be loaded in a multi-threaded and asynchronous manner, the model file data can be reused, and the rendering mechanism can be defined by the 3D scene function of Three.js to make the rendering controllable.

[0032] (2) This invention uses multiple storage types to store different data, giving full play to the advantages of each type of storage, ensuring both data reliability and efficient data reading and writing;

[0033] (3) This invention controls data reading and writing through a unified data interaction control module and controls permissions in conjunction with a shared data control module, which facilitates collaborative work among multiple people;

[0034] (4) The version control mechanism of this invention enables the construction of 3D scenes to be carried out in a controllable iterative manner, which facilitates rollback and historical comparison;

[0035] (5) The historical data of this invention can be freely stored in different data, ensuring data security, and can also provide functions such as traceability and auditing. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of the architecture of the web page data interaction system described in this invention;

[0037] Figure 2 for Figure 1 One of the magnified views of a section;

[0038] Figure 3 for Figure 1 The second enlarged view of a section;

[0039] Figure 4 A diagram illustrating the steps for uploading a model;

[0040] Figure 5 A schematic diagram of the module construction steps;

[0041] Figure 6 A diagram illustrating the model loading process;

[0042] Figure 7 This is a schematic diagram of the module loading process;

[0043] Figure 8 This is a schematic diagram illustrating the steps involved in sharing models / modules / 3D scenes.

[0044] Figure 9 This is a schematic diagram illustrating the steps involved in storing a 3D scene.

[0045] Figure 10A schematic diagram illustrating the steps of loading a 3D scene;

[0046] Figure 11 This is an overall business interaction diagram of the web page data interaction system described in this invention;

[0047] Figure 12 for Figure 11 One of the magnified views of a section;

[0048] Figure 13 for Figure 11 The second enlarged view of a section;

[0049] Figure 14 for Figure 11 The third enlarged view of a section;

[0050] Figure 15 This is a business interface diagram of the web page data interaction system described in this invention. Detailed Implementation

[0051] The present invention will be further described in detail below with reference to the embodiments and accompanying drawings, but the embodiments of the present invention are not limited thereto.

[0052] Example 1

[0053] like Figures 1 to 15 As shown, this invention achieves the storage and fast loading of 3D scene data based on Three.js by classifying and storing data in a structured and unstructured manner, as well as by using scene version information and data sharing, making the construction of 3D scenes based on Three.js simple and easy to use.

[0054] When building a 3D scene based on Three.js, methods for structured and unstructured data storage, fast data loading, data version control, and data sharing are employed. It mainly consists of the following modules: file storage module, relational data storage module, non-relational data storage module, shared data control module, and data interaction control module.

[0055] The modules described above segment and store the data, supporting asynchronous data retrieval during loading to reduce retrieval time. However, in Three.js-based 3D scenes, using the built-in export method results in large files and significant time consumption. For users with poor terminal performance, this export can lead to browser errors and the loss of the constructed 3D scene. Therefore, efficiently and easily saving 3D scenes directly improves user experience and system performance.

[0056] A 3D scene is constructed from various models. These models are built using 3D coordinates, dimensions (length, width, height), and some custom parameters. The model files are unstructured, and based on this, there are no relationships between them; they are simply data needed by Three.js to display the models. What's truly important in a 3D scene is the 3D coordinates, dimensions, height, and some custom parameter information of the models. Saving this relational data in JSON format, along with the model file loading path, allows for complete preservation of the 3D scene data. Scene loading is achieved by retrieving model files in different regions or using multiple threads to recreate the three scenes (the model files themselves are unrelated; multiple threads can retrieve different model files simultaneously, while the same model file only needs to be retrieved once). Therefore, using a custom data protocol for scene storage can significantly reduce the computer resources consumed during storage and improve efficiency. When customizing the data protocol, at least the following should be included: floor information, model information, and path information (optional). The system includes several data structures: floor information (requiring floor height, width, and height, with height distinguishing the first, second, and third floors); model information (requiring model ID, file path, 3D coordinates, dimensions, floor number, and optional parameters such as speed and limitations); and path information (optional, defined within the Three.js 3D scene, primarily storing this type of information, which can be omitted if animation is not required). The non-relational data storage module primarily stores JSON-formatted information. Custom data protocols can be encapsulated in JSON format, defined by the terminal and business functions, with no fixed format, as long as the main information is included). The file storage module uses an interface implementation, supporting local storage, distributed storage, and cloud storage strategies to ensure data security. It primarily stores model files, images, and attachments. The relational data storage module primarily stores basic model file information, module information, and scene information. The non-relational data storage module primarily stores version history information, operation logs, and other key-value, JSON-formatted data. The shared data control module primarily controls data sharing permissions, including public data, personal data, data shared with individuals, and data shared with organizations, as well as permissions for adding, deleting, and modifying data after sharing. The version information storage module primarily stores version information of the 3D scene and the scene's corresponding custom data protocol (including model information, model parameters, model location, scene construction parameters, etc.). The data interaction control module is mainly used to control data interaction, define data interfaces, and control the acquisition of data resources.

[0057] To better understand the above-mentioned objects, features, and advantages of the present invention, the present invention will be further described in detail below. It should be noted that, unless otherwise specified, the embodiments of the present invention and the features thereof can be combined with each other.

[0058] When building a 3D scene, you can follow these steps to complete the scene building.

[0059] First, you need to upload the model file. This step is completed according to the "Model Upload" steps below. After uploading, you can perform other operations on the model. If no operation is required, end the process and repeat the model upload steps. If so, perform the following operations:

[0060] (1) Sharing operations can be performed on the model. This step is completed according to the "Model Sharing" steps below.

[0061] (2) Module building operations can be performed on the model. Module building requires two or more models. The model is loaded to the terminal device through the "Model Loading" step, and the module is built through the "Module Storage" step. After the module is built, you can choose whether to share the module. If not, the process ends. If so, follow the "Module Sharing" step to complete the sharing operation.

[0062] (3) After obtaining the model, a 3D scene can be built. By opening the 3D scene function on the terminal device, a scene can be built and a pre-built scene can be loaded.

[0063] ① Scene Setup: First, load the model and module information. This step follows the "Model Loading" and "Module Loading" steps. After loading, create floor information in the 3D scene. Floor information can be understood as the "ground plane." Create different height ground planes for two or three floors, etc. After creation, place the model or module on the "ground plane" to build the desired 3D scene. After setup, you can choose whether to define animations. If so, define animations; otherwise, this step is unnecessary. Save the scene information after setup, following the "3D Scene Storage" step. After saving, you can share the scene, following the "3D Scene Sharing" step.

[0064] ② Load Scene: Load the already built scene. You can follow the "3D Scene Loading" steps to complete scene loading and rendering. Restore scene information.

[0065] The above process outlines the steps from scratch and briefly describes the dependencies between models, modules, and scenarios. In practical applications, these steps can be freely combined as long as the dependencies are not violated. For example, when a user owns a model, they can skip uploading the model and directly build modules and scenarios.

[0066] The operation process of each function will be briefly described below:

[0067] Model data storage and loading process:

[0068] ① Model Upload: Users upload model information packages to the data interaction control module via the data terminal's upload interface. These packages primarily include: basic information defined by the user (name, type, number, description), default model parameters (optional parameters, such as default model size, animation parameters, etc.), and the model file (FBX model file). Upon receiving the uploaded data, the data interaction control module decomposes the data packet according to the parameters defined in the interface (name, type, number, description, extended parameter set (parameter name, parameter code, parameter type, parameter value), and model file data stream) to obtain the basic model information, default model parameters, and model file information. First, the model file is stored in the file storage module. The file storage module performs a hash algorithm on the file to obtain its hash value. It then searches for existing model files with the same hash value. If a match is found, the stored file information is directly returned to the data interaction control module. Otherwise, the model is stored in the external storage system connected to the file storage module, and the file information is returned to the data interaction control module. Finally, the file storage information, hash value, and model basic information and default parameters generated by the file storage module, along with the model default parameters from the data interaction control module, are stored together in the relational data storage module.

[0069] ② Model Sharing: During business processing, 3D scene construction may involve multiple people working together, or users may want to share their models with other users. In such cases, the model sharing function can be used. Users select their uploaded model in the data terminal and define sharing rules, specifying whether the sharing method is public, shared with individuals, or shared with organizations. The sharing rule information mainly includes the model's basic information ID, the sharing type (public, individual, or organization, where individual and organization can coexist), the sharing user ID, and the sharing organization ID. After definition, the sharing information is submitted to the data interaction control module. The database interaction module first verifies the sharing information, such as whether the shared model was uploaded by the current user. This information is already stored in the relational data storage module when the model is uploaded. The data interaction control module can call the relational data storage module to query and verify. After passing the verification, the sharing rule information is passed to the sharing data control module for storage. Upon receiving the sharing rule information, the sharing data control module writes or updates the sharing rules for that model based on the shared model ID.

[0070] ③ Module Storage: In 3D scene building, some models appear in a fixed or routine combination (this is determined by the user and is not mandatory; it can be a product combination or a user habit). Building these combinations individually each time during scene building is not only cumbersome but also time-consuming. Therefore, building two or more models into a module allows for flexible combination into different storage forms, facilitating direct use in future scene builds and improving efficiency. A module consists of basic module information (module name, type, module number, description) and model information (model ID, relative coordinates of the model, used to identify the model's position within the module). On the user's terminal device, by selecting two or more devices in the Three.js 3D scene, the terminal's module storage function processes the data. Using the selected model IDs and current position information, a calculation formula is used to obtain the center coordinates of several models. These center coordinates are then used to calculate the relative coordinates of each model relative to the center. Multiple model IDs and their corresponding relative coordinates are used as module information. After the user defines the basic information combination of the module, the module information is uploaded to the data interaction control module. After verification by the data interaction module (e.g., verifying the existence of the uploaded model ID, which was generated and stored when the model was uploaded), the module information is stored through the relational data storage module. The calculation formula is as follows:

[0071] The Y-axis is defined as the east-west direction of the plane, the Z-axis as the north-south direction of the plane, and the Y-axis as the height of the plane (vertical direction).

[0072] Assume model A has coordinates (x1, y1, z1), model B has coordinates (x2, y2, z2), and model C has coordinates (x3, y3, z3). Models A, B, and C need to be combined into a module. The coordinates of these models are based on the center point coordinates within the 3D scene. When combined into a module, this can be considered as constructing a new model containing other sub-models. The coordinates of these sub-models need to be modified to relative coordinates with respect to the center point of this new model. These relative coordinates are used to identify the position information of the sub-models within the new model. When the new model is added to the 3D scene as a module (multiple models), it is equivalent to not changing the relative positions of the sub-models, but the position of the model relative to the center point coordinates within the 3D scene needs to be modified. The following will briefly describe the process of calculating the center point of the new model and the coordinate modification of the other sub-models included in this model:

[0073] Use a rectangular box to cover all the models within the module. This rectangular box is regarded as a newly created model, where the covered models are the internal sub-models. Use the sub-models to find the coordinates of the center point of the rectangular box.

[0074] The first step is to calculate the coordinates of the center point in the coordinate system of multiple models.

[0075] The center point's X-coordinate L_x = (max(X1,X2,X3,X4……)+min(X1,X2,X3,X4……)) / 2;

[0076] The center point Z-coordinate L_z = (max(Z1,Z2,Z3,Z4……)+min(Z1,Z2,Z3,Z4……)) / 2;

[0077] The Y-coordinate of the center point is the height coordinate. The height coordinate is used as the identifier of the lowest point of the model when constructing a 3D scene, so this coordinate is taken from the coordinates of the lowest points of several models.

[0078] The center point's Y-coordinate L_y = min(Y1,Y2,Y3,Y4...);

[0079] The center point coordinates L(L_x,L_z,L_y) are the center point coordinates of the module within the 3D scene.

[0080] The second step is to convert the coordinates to relative coordinates. All the coordinates obtained in the above steps are based on the 3D scene. It is necessary to convert the model's coordinates to relative coordinates relative to the new modeling group.

[0081] The center point coordinates are defined as L(0,0,0), and the coordinates L(L_x,L_z,L_y) are the displacement distances along the X, Z, and Y axes. The relative coordinates are obtained by subtracting the displacement distances from the model coordinates. These coordinates are relative to the center point coordinates L(0,0,0).

[0082] For example, if the coordinates of model A are (x1, y1, z1), then the relative coordinates are (x1-L_x, y1-L_y, z1-L_z).

[0083] And so on.

[0084] ④ Module Sharing: Similar to models, modules can also be considered a special type of model. During the construction of 3D scenes, there is a need for sharing. Users select their self-built modules in the data terminal and define sharing rules. The sharing method can be public, shared with individuals, or shared with organizations. The sharing rule information mainly includes the module's basic information ID, the sharing type (public, individual, organization, where individual and organization can coexist), the sharing user ID, and the sharing organization ID. After definition, the sharing information is submitted to the data interaction control module. The database interaction module first verifies the sharing information, such as whether the shared module was uploaded by the current user. This information is already stored in the relational data storage module when the module is stored. The data interaction control module can call the relational data storage module to query and detect. After verification, the sharing rule information is passed to the sharing data control module for storage. Upon receiving the sharing rule information, the sharing data control module writes or updates the sharing rules for that module based on the shared module ID.

[0085] After preparing the models and modules, users can also build 3D scenes in the Three.js 3D scene. This involves how to load 3D models and 3D modules. The following sections explain model loading and module loading respectively.

[0086] ⑤ Model Loading: Users load their own uploaded models and shared models on their terminal devices via the data interaction control module. First, the data interaction control module retrieves the user's uploaded model information from the relational data storage module and the user's shared model information from the shared data control module. These two parts of information can be retrieved separately from different interfaces, or they can be combined and returned together by the data interaction control module. The model information includes basic information, default model parameters, and model file information. The terminal device can first display the model thumbnail, model name, and model type to the user using the basic model information. Simultaneously, it loads the model file using a multi-threaded mode. The loading of the model file runs in the background on the terminal device, without noticeable impact on the user, thus improving the user experience. Furthermore, the multi-threaded loading method shortens the time consumed by the synchronous loading mode.

[0087] ⑥ Module Loading: Users load their personally built modules and shared modules on their terminal devices via the data interaction control module. First, the data interaction control module retrieves the built module information from the relational data storage module and the shared module information owned by the user from the shared data control module. These two parts of information can be retrieved separately from different interfaces, or they can be merged and returned together by the data interaction control module. Module information includes basic module information and model information groups. Since a module consists of a set of custom models, there is no actual corresponding module file. The terminal can obtain the corresponding model file through the model ID in the model information group. Furthermore, since the terminal device has already loaded model information, it can compare the model information set to obtain the non-existent model ID, reducing data interaction.

[0088] Users build 3D scenes in a Three.js-based 3D scene environment on the terminal. Once built, the scene needs to be saved for download, loading, or modification. As mentioned earlier, Three.js's built-in export method produces large files, resulting in significant performance overhead. In a browser, this high performance overhead and long export time can easily crash the browser, causing the unsaved scene to be lost. By using our custom data protocol to save 3D scenes, we can reduce the amount of data saved and add version control. This allows users to create different branches based on version when building the scene, increasing the diversity of version comparison and rollback, thus improving user convenience. The following sections will explain the storage, sharing, and loading of 3D scenes.

[0089] ⑦ 3D Scene Storage: When a user completes the construction of a 3D scene on their terminal device, scene information is saved using a custom data protocol. The custom data protocol includes: floor information (ground plane information), model information, and path information (optional). Floor information requires the length, width, and height of each floor (height is used to identify the floor, distinguishing between the first, second, and third floors, etc.). Model information requires the model's ID, model file path, 3D coordinates, length, width, and height, the floor the model is located on, and model auxiliary parameters (optional parameters, such as model movement speed, model constraint parameters, etc.). Path information is an optional parameter; the model's running path information can be defined in the Three.js 3D scene. This parameter block mainly stores this type of information; if the scene does not require animation, it can be omitted. This information can be encapsulated by the terminal or other system modules as required and saved in JSON format. First, when a user needs to save a 3D scene on their terminal device, they must first check if the current solution already has basic information (including solution name, solution type, solution description, etc.). If not, it needs to be created and saved first. The terminal device sends the solution information to the data interaction control module, which then sends the solution information to the relational data storage module for storage. After storage, the stored solution information is returned to the data interaction control module, which then sends the solution information back to the terminal device. Otherwise, this step is skipped, and the terminal device verifies the information. The saved 3D scene information includes the solution ID, custom data package, version number, version name, version description, and the parent 3D scene information ID (the parent version ID of the top-level node is empty or 0). The terminal device sends 3D scene information to the data interaction control module. After receiving the information, the data interaction control module retrieves the custom data packet using the key value and sends it to the non-relational data storage module for storage. After storage, the non-relational data storage module returns the information ID to the data interaction control module. The data interaction control module then sends the scheme ID, version number, version name, version description, parent 3D scene information ID, and custom data packet information ID to the relational data storage module for storage. After storage is complete, the relational data storage module sends the stored information back to the data interaction control module. Upon receiving the information, the data interaction control module returns a storage success message to the terminal.

[0090] ⑧ 3D Scene Sharing: During business processing, 3D scene construction may involve multiple people working together, or users may want to share their scenes with other users. In such cases, the scene sharing function can be used. Users select their constructed 3D scene scheme information in the data terminal and define sharing rules. The sharing method can be public, shared with individuals, or shared with organizations. The sharing rule information mainly includes the ID of the scheme's basic information, the sharing type (public, individual, organization, where individual and organization can coexist), the sharing user ID, and the sharing organization ID. After definition, the sharing information is submitted to the data interaction control module. The database interaction module first verifies the sharing information, such as whether the shared scheme was created by the current user. This information is already stored in the relational data storage module when the 3D scene is saved. The data interaction control module can call the relational data storage module to query and check. After verification, the sharing rule information is passed to the sharing data control module for storage. Upon receiving the sharing rule information, the sharing data control module writes or updates the sharing rules of the model based on the ID of the shared scheme's basic information.

[0091] ⑨ 3D Scene Loading: Users load their own constructed 3D scene schemes and shared 3D scene schemes via the data interaction control module on their terminal devices. First, the data interaction control module retrieves the constructed 3D scene scheme information from the relational data storage module and the user's shared 3D scene scheme information from the shared data control module. These two parts of information can be retrieved separately from different interfaces, or they can be merged and returned together by the data interaction control module. The scheme information can be initially displayed to the user on the terminal device. When the user selects a scheme, the terminal device sends the scheme ID to the data interaction control module to query the 3D scene information for that scheme. The data interaction control module sends the scheme ID to the relational data storage module to query the 3D scene information group. The relational data storage module returns the retrieved 3D scene information group to the data interaction control module. Upon receiving the message, the data interaction control module returns the 3D scene information group to the terminal device. The terminal device can then construct a tree-structured version branch information based on the 3D scene information ID and the parent 3D scene information ID, displaying it intuitively to the user. The user selects a version of the 3D scene to load. The terminal device sends the custom data package information ID of the 3D scene to the data interaction control module. Upon receiving the information, the data interaction control module queries the non-relational data storage module for the custom data package information using the custom data package information ID. After the query, the non-relational data storage module sends the information back to the data interaction control module, which then returns the information to the terminal device. The terminal device receives the custom data package information, which is in JSON format. Using a custom key value, it retrieves the floor information, model information, and path information. The terminal then uses the 3D scene loading logic based on Three.js to complete the scene rendering. To briefly explain the loading logic: first, the floor information is rendered; second, based on the model information, it checks if the locally loaded model files are insufficient (this step already loads model and module information once when the terminal is opened). If insufficient, it retrieves the corresponding model information based on the model ID through the model loading step. Due to the custom scene information, the protocol developer can add extended fields to this protocol, such as area model domain information and model level information. Scene rendering can be achieved through layer-by-layer, region-by-region, and level-by-level rendering, resulting in a progressive loading effect. The user terminal can render gradually, ensuring low performance consumption while maintaining scene rendering speed. Finally, after the scene's path information is loaded, animation effects can be implemented. At this point, the 3D scene is fully loaded. Users can modify, add, and delete model information within this scene. After completion, the scene can be saved using the 3D scene saving process, creating a new version for easy rollback or further modifications.

[0092] ⑩ Storage of historical data: Historical data is stored using a non-relational data storage module. This module provides a unified interface for storing historical data. Key information for historical data includes: data ID, data type, module to which the data belongs, version number, original data ID, original data content (JSON format), creation time, and creator. Other information can be expanded as needed; the non-relational data storage module does not restrict information fields and content.

[0093] User operation records or deletion / update operations from other modules can be stored as historical information in the non-relational data storage module through this interface. This module also provides query services, allowing users to query historical data by specific data item, type, or time period. The user terminal sends historical data to the data interaction control module, which then forwards the information to the non-relational data storage module. Alternatively, other modules may directly send historical data to the non-relational data storage module. Upon successful storage, the non-relational data storage module returns a success message to the corresponding module, which then handles other related business processes. The existence of historical data is of great significance for system operation auditing, data rollback, and data retrieval.

[0094] This invention has the following characteristics:

[0095] 1. When building a 3D scene based on Three.js, the data of the model, module, and scene are saved in a specific way. The relationship between information is decoupled in terms of saving, loading, and sharing. The combination is simplified and the storage is classified. This makes the data multi-threaded and asynchronous, the model file data can be reused, and the rendering mechanism can be defined by the 3D scene function of Three.js, making the rendering controllable.

[0096] 2. Use multiple storage types to store different data, leveraging the advantages of each type to ensure both data reliability and efficient data reading and writing.

[0097] 3. Data reading and writing are controlled through a unified data interaction control module, and permissions are controlled in conjunction with a shared data control module, which facilitates collaborative work among multiple users.

[0098] 4. The version control mechanism enables a controllable iterative approach to 3D scene construction, facilitating rollback and historical comparison.

[0099] 5. Historical data can be freely stored in different formats to ensure data security, and can also provide functions such as traceability and auditing.

[0100] As described above, the present invention can be implemented well.

[0101] All features disclosed in all embodiments of this specification, or steps in all methods or processes implied in the disclosure, may be combined and / or extended or replaced in any way, except for mutually exclusive features and / or steps.

[0102] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Based on the technical essence of the present invention, any simple modifications, equivalent substitutions, and improvements made to the above embodiments within the spirit and principles of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A data interaction method of a web three-dimensional scene, characterized in that, When building a 3D scene based on Three.js, the model files of the webpage are stored, or module files and 3D scene files of the webpage are built based on the model files of the webpage and then stored. During storage, the relationships between the data information of the model, module, and 3D scene are decoupled and categorized for storage. The data is stored using a webpage data interaction system. This system includes a data interaction control module, and further includes a relational data storage module, a non-relational data storage module, a shared data control module, a file storage module, and a data operation module, all communicatively connected to the data interaction control module. The data operation module stores the webpage model files, and the methods for storing these model files include one or more of model uploading, model sharing, and model loading. Model uploading includes the following steps: XS1 allows users to upload model information packages to the data interaction control module via a data terminal. The uploaded model information includes: basic information defined by the user for the model, default parameters of the model, and model files. After receiving the uploaded data, the XS2 data interaction control module will decompose the received data packet into corresponding data information through the parameters defined by the interface to obtain the basic model information, default model parameters, and model file information. The module for storing web page module files is adopted. The module files for storing web page module files include one or more of the following: module building, module sharing, and module loading. Among them, module building refers to performing module building operations on the model. Module building requires two or more models. The model is loaded to the terminal device through the model loading step, and the module building is completed through the module storage step. The module information is stored through the relational data storage module. The data operation module stores the 3D scene files of the webpage. The storage of the 3D scene files of the webpage includes one or more of the following: 3D scene upload, 3D scene sharing, and 3D scene loading. The 3D scene files are constructed in the following way: the 3D coordinates, length, width, height, and custom parameters of the model are saved in JSON format, along with the model file loading path, so as to obtain a 3D scene file containing 3D scene data. Model sharing includes the following steps: XG1 allows users to select their uploaded models on the data terminal and define sharing rules; the sharing rule information includes the model's basic information ID, sharing type, sharing user ID, and sharing organization ID. XG2, after the sharing rules are defined, submit them to the data interaction control module, and the database interaction module will first verify the sharing rules; After verification, XG3 will pass the sharing rules to the shared data control module for storage. XG4, the shared data control module receives the shared rules and writes or updates the shared rules for the model based on the shared model ID; Module sharing includes the following steps: ZG1 allows users to select their own built modules on the data terminal and define sharing rules; the sharing rule information includes the module's basic information ID, sharing type, sharing user ID, and sharing organization ID. ZG2, once defined, submits the shared information to the data interaction control module, which then verifies the shared information first. The data interaction control module can call the relational data storage module for verification. ZG3, after verification, transmits the sharing rule information to the shared data control module for storage; ZG4, the shared data control module receives the shared rule information and writes or updates the shared rules of the module according to the ID of the shared module's basic information; 3D scene sharing includes the following steps: SG1: Users select their self-constructed 3D scene scheme information on the data terminal and define sharing rules; the sharing rule information includes the scheme basic information ID, sharing type, sharing person ID, and sharing organization ID; SG2, once defined, submits the shared information to the data interaction control module, where the database interaction module first verifies the shared information; the data interaction control module can call the relational data storage module for verification. After verification, SG3 transmits the sharing rule information to the shared data control module for storage. SG4, the shared data control module receives the shared rule information and writes or updates the shared rules of the model according to the ID of the basic information of the shared scheme.

2. The data interaction method of a web page three-dimensional scene according to claim 1, characterized in that, When loading a model, users can load their own uploaded models through the data interaction control module on their terminal devices, while also loading their shared models.

3. The data interaction method for a webpage 3D scene according to claim 1, characterized in that, When a module is loaded, the user loads their own built module through the data interaction control module on the terminal device, and also loads the shared modules they own.

4. A data interaction system for a webpage's three-dimensional scene, characterized in that, To implement the data interaction method for a webpage 3D scene as described in any one of claims 1 to 3, when the webpage 3D scene data interaction system is working, when constructing a 3D scene based on Three.js, it stores the webpage model file, or constructs and stores the webpage module file and the webpage 3D scene file based on the webpage model file; wherein, during storage, the relationship between the data information of the model, module, and 3D scene is decoupled and classified for storage.

Images