A data management method and system based on a gridded three-dimensional scene

Abstract

This invention provides a data management method and system for a mesh-based 3D scene. The method relies on a three-tiered storage system consisting of in-memory caching, a local database, and static storage. It includes: receiving target mesh data requests from a front-end module; global scheduling and routing by a top-level management layer; routing to a parent management layer for processing and scheduling of child management layers; the child management layers scheduling a lower-level data proxy layer, which acts as a persistent data container to manage the original data, obtains the corresponding target mesh data through the data proxy layer, and manages the state of interactive objects contained within the data according to a preset lifecycle; and returning the target mesh data to the front-end module along the original path. This invention achieves complete decoupling of data and business logic, avoids frequent low-level input / output operations, and significantly improves system throughput, operating efficiency, and system stability.

Description

Technical Field

[0001] This invention relates to the field of data management, and in particular to a data management method and system based on a gridded 3D scene. Background Technology

[0002] In large-scale 3D scenarios (such as open-world video games, virtual reality, and digital twins), dynamic data management is the fundamental lifeline supporting the smooth operation of the entire system. As the scale and complexity of scenarios increase, the amount of data contained within them rises exponentially. Efficient data scheduling and management not only handle the flow of massive resources between underlying persistent data containers and memory, but also directly determine whether related front-end modules (such as terrain rendering and object interaction) can obtain real-time and accurate data support. It is a core element in ensuring the continuity of scene exploration and the smoothness of interaction.

[0003] However, existing data management methods often tightly couple data management logic with business application logic, typically with each front-end module responsible for loading, caching, and releasing its required data independently. This multi-headed management model prevents the system from optimizing memory and storage access from a global perspective, easily leading to duplicate readings of underlying data, memory fragmentation, and severe system resource consumption. Furthermore, when facing high-frequency scenario exploration and multi-target concurrent interactions, existing technologies often lack unified and intelligent cache allocation and dynamic eviction mechanisms. The serial data loading and unloading process not only results in high data access latency and significant performance stalls but also fails to fully utilize the parallel computing capabilities of the underlying hardware. In addition, due to the high degree of intertwining between scheduling management and business logic, the system's lifecycle isolation and state control for data are extremely weak. This not only makes the code difficult to maintain and extend but also easily harbors hidden dangers such as data contention and memory leaks, posing a significant challenge to the long-term stable operation of the system.

[0004] In summary, current data management methods have not fundamentally solved the problem of deep decoupling between management scheduling and business logic, making it difficult to achieve unified optimization of global resources and systematic assurance of stability in complex dynamic interaction scenarios. How to solve the above problems has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] In order to overcome the above-mentioned technical defects, the purpose of this invention is to provide a data management method and system based on gridded three-dimensional scenes.

[0006] This invention discloses a data management method for a mesh-based 3D scene. The data management method relies on a three-level storage system consisting of a memory-based cache, a local database, and static storage, including: It receives target grid data requests from the front-end module, and the top-level management layer performs global scheduling and routing of target grid data requests; The target grid data request is routed to the corresponding parent management layer, which then processes the request based on its type and schedules the corresponding child management layer. The underlying data proxy layer is scheduled by the sub-level management layer, where the data proxy layer acts as a persistent data container to manage the raw data of interactive objects; The data proxy layer obtains the target grid data corresponding to the target grid data request and manages the state of the interactive objects associated with the target grid data according to the preset lifecycle. The target grid data is returned to the front-end module along the original path.

[0007] Preferably, the state management of interactive objects associated with the target grid data according to a preset lifecycle includes: The raw data of the interaction object is read asynchronously from the data proxy layer for centralized processing of input and output operations; Perform serial internal calculations and state initialization on the raw data to put the data in a ready state for access by the front-end module; Undo the impact of the original data on the front-end module and prepare to release resources; Dirty data is re-encoded and asynchronously written back to the persistent data container, and the corresponding memory object is set to null.

[0008] Preferably, the interactive objects contained within the target grid data exist in a data hosting format; the data hosting format includes: Point cloud data: records the basic type, unique ID, and spatial location of interactive objects; Decorative data: Used to override or extend component properties and behaviors of interactive objects; When the front-end module interacts with the interactive object, the system dynamically creates a complete interactive object entity based on the point cloud data and decoration data for the front-end module to use.

[0009] Preferably, the data management method further includes a grid elimination step, specifically including: When the preset triggering conditions are met, grid data that meets the preset elimination rules is selected from the memory-state cache as elimination candidates; Each candidate for elimination is assessed for importance, and grid data that belongs to the system's critical data is skipped; Elimination candidates that pass the importance assessment will be removed from the memory cache.

[0010] Preferably, the preset triggering conditions include: Execute periodically with a fixed or adaptive threshold time period; And / or, execute when the usage of the memory-state cache is detected to exceed a set threshold.

[0011] Preferably, removing eviction candidates that have passed importance assessment from the in-memory cache includes: Removed elimination candidates are serialized and downgraded and stored in the local database as warm data for quick reloading. Alternatively, the memory space corresponding to the removed candidate can be released directly, retaining only its original backup in static storage as cold data.

[0012] Preferably, when there is only one active object in the 3D scene, the target mesh data requested through the data proxy layer includes: Determine an active region comprising nine grids, centered on the grid where the single active object is currently located; Allocate at least 7 grids of cache space for a single active object in the memory-state cache to cover its current position and all adjacent positions that can be reached in one step.

[0013] Preferably, when there are N active objects in the 3D scene, obtaining the target mesh data corresponding to the target mesh data request through the data proxy layer further includes: Allocate 7 grids of cache space in the in-memory cache for the first active object; Starting from the second active object, calculate the spatial overlap between the active region of each newly added active object and the cache region of existing active objects; Based on spatial overlap, only an additional 4 grids of incremental cache space are allocated for each newly added active object to ensure that adjacent active objects do not trigger new loading when the boundary is active.

[0014] Preferably, returning the target grid data to the front-end module along the original path includes: The unified external interface layer of the data proxy layer outputs to the front-end module. The unified external interface layer only exposes basic operations for the target grid data. The interactive objects within the target grid data are encapsulated and output through a unified interactive object interface. The unified interactive object interface only provides limited read and write capabilities for the unique ID, location, and basic configuration attributes of the interactive objects.

[0015] A second aspect of this application provides a management system for meshed 3D scene data, including: The front-end module is used to send target mesh data requests and receive the returned target mesh data for scene rendering or interactive processing. The data management module is connected to the front-end module. The data management module includes four levels: top-level management layer, parent management layer, child management layer, and data proxy layer. It is used to execute any of the aforementioned data management methods based on a gridded 3D scene. The data storage module, connected to the data management module, is used for backend persistent storage of raw binary data in the 3D scene.

[0016] Compared with existing technologies, the above technical solution has the following advantages: 1. This application proposes a data management method for gridded 3D scenes. This method constructs a three-tiered storage system based on in-memory caching, a local database, and static storage, distributing grid data across different storage media in a tiered manner according to access requirements, thereby balancing data read latency with the overall system storage capacity. Based on this, the system introduces a layered architecture of a top-level management layer, parent management layer, child management layer, and data proxy layer, completely isolating the reception, routing, and processing of target grid data requests from the front-end module from underlying operations. Through sequential scheduling at each management level, the underlying data proxy layer centrally manages the original data of the interactive objects, and finally returns the acquired target grid data to the front-end module along the original path. This design achieves complete decoupling of data flow logic and business logic, eliminating the need for the front-end module to intervene in the underlying persistence process. Simultaneously, the system manages the state of interactive objects associated with the target grid data based on a preset lifecycle, strictly regulating the state change rules of interactive objects during loading, access, and unloading phases. Overall, the combination of the three-level storage system and the hierarchical routing architecture significantly improves the response efficiency and system throughput of concurrent data requests, while the structured lifecycle state management eliminates the risk of resource conflicts during multi-threaded concurrent access, effectively ensuring the stability of data flow in complex 3D scenes. 2. To address the massive number of interactive objects in a 3D scene, this application introduces a data hosting and structured lifecycle management mechanism. Most of the time, interactive objects in the scene reside only as lightweight point cloud data and decoration data. Only when the front-end module triggers an actual interaction will the system extract this recipe data and dynamically instantiate complete entity objects, thus avoiding the ineffective occupation of memory space by massive static elements. Simultaneously, the data flow of interactive objects is strictly divided into four ordered stages: acquisition, loading, unloading, and release. This separates time-consuming asynchronous reading from the serial changes of core states, fundamentally eliminating the risk of contention during concurrent access. Combined with a unified external interface for strict encapsulation and isolation, the system black-boxes the underlying coding mechanism and flow details, ensuring data security throughout the lifecycle and enhancing the maintainability of the entire system. 3. Given limited memory, this application also constructs an intelligent grid eviction process and a tiered cache scheduling system. Through a dual triggering mechanism combining time periods and memory usage preferences, the system can periodically clean up idle data to maintain operational activity, while also responding quickly to data surges. During memory cleanup, the system proactively intercepts and skips critical scenario data based on importance assessment, preventing operational anomalies due to accidental deletion. Furthermore, data removed from memory is downgraded and stored in a local database as warm data, or only cold data backups in static storage are retained, depending on the strategy. This tiered scheduling design balances the inherent contradiction between data access latency and storage media capacity, enabling evicted data to be quickly reloaded at a lower cost when accessed again in the future, ensuring long-term healthy and stable memory usage. 4. Finally, to ensure smooth viewpoint movement in large-scale, complex scenes, this solution further proposes an intelligent cache allocation strategy based on spatial behavior prediction. The system pre-allocates a basic cache space in memory, covering surrounding locations that can be reached in one step, with active front-end objects as the core. This completely eliminates the lag caused by triggering new loading when crossing boundaries. When multiple active objects exist in the scene, the system accurately calculates the spatial overlap of their activity areas, removes the overlapping parts, and allocates incremental cache space only for newly added objects. This shared boundary cache mechanism breaks the bottleneck of linearly increasing memory demand with the number of objects, significantly reducing server load pressure in high-density scenes while maintaining a smooth, loading-free experience. All of the above mechanisms ultimately rely on a management system with clearly defined modules to ensure smooth operation, providing solid support for the engineering implementation of the entire data solution. Attached Figure Description

[0017] Figure 1 A flowchart illustrating the management method for gridded 3D scene data provided in this application; Figure 2 A schematic diagram of a single active object cache allocation in the gridded 3D scene data management method provided in this application. Detailed Implementation

[0018] The advantages of the present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments.

[0019] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0020] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0021] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0022] In the description of this invention, it should be understood that the terms "longitudinal", "lateral", "up", "down", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0023] In the description of this invention, unless otherwise specified and limited, it should be noted that the terms "installation", "connection" and "linking" should be interpreted broadly. For example, they can refer to mechanical or electrical connections, or internal connections between two components. They can be direct connections or indirect connections through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0024] In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the convenience of the description of the invention and have no specific meaning in themselves. Therefore, "module" and "part" can be used interchangeably.

[0025] Please see Figure 1 , Figure 1 A flowchart illustrating the management method for gridded 3D scene data provided in this application.

[0026] like Figure 1 As shown, this invention discloses a data management method for a gridded 3D scene. The data management method relies on a three-tier storage system consisting of in-memory cache, local database, and static storage, including: It receives target grid data requests from the front-end module, and the top-level management layer performs global scheduling and routing of target grid data requests; The target grid data request is routed to the corresponding parent management layer, which then processes the request based on its type and schedules the corresponding child management layer. The underlying data proxy layer is scheduled by the sub-level management layer, where the data proxy layer acts as a persistent data container to manage the raw data of interactive objects; The data proxy layer obtains the target grid data corresponding to the target grid data request and manages the state of the interactive objects associated with the target grid data according to the preset lifecycle. The target grid data is returned to the front-end module along the original path.

[0027] This can be understood as follows: This application proposes a data management method for 3D scenes based on a gridded architecture. This method constructs a three-tiered storage system relying on in-memory caching, a local database, and static storage. Grid data is distributed across different storage media in a tiered manner according to access requirements, thereby balancing data read latency with the overall storage capacity of the system. Based on this, the system introduces a layered architecture of a top-level management layer, parent management layer, child management layer, and data proxy layer, completely isolating the reception, routing, and processing of target grid data requests from the front-end module from underlying operations. Through sequential scheduling at each management level, the underlying data proxy layer centrally manages the original data of the interactive objects, and finally returns the acquired target grid data to the front-end module along the original path. This design achieves complete decoupling of data flow logic and business logic, allowing the front-end module to operate without interfering with the underlying persistence process. Simultaneously, the system manages the state of interactive objects associated with the target grid data based on a preset lifecycle, strictly regulating the state change rules of interactive objects during loading, access, and unloading phases. Overall, the combination of the three-tier storage system and the hierarchical routing architecture significantly improves the response efficiency and system throughput of concurrent data requests, while the structured lifecycle state management eliminates the risk of resource conflicts during multi-threaded concurrent access, effectively ensuring the stability of data flow in complex 3D scenes.

[0028] The above is an explanation of the basic concept of this application. The specific implementation methods of each step will be explained below.

[0029] First, there are no restrictions on the state management method for the target grid data.

[0030] In one possible implementation, state management of interactive objects associated with the target grid data according to a preset lifecycle includes: The raw data of the interaction object is read asynchronously from the data proxy layer for centralized processing of input and output operations; Perform serial internal calculations and state initialization on the raw data to put the data in a ready state for access by the front-end module (or, as can be understood, the external business module that makes the data request); Undo the impact of the original data on the front-end module and prepare to release resources; Dirty data is re-encoded and asynchronously written back to the persistent data container, and the corresponding memory object is set to null.

[0031] This application designs a structured lifecycle state management mechanism for the interactive objects contained within the target grid data. This mechanism divides the data flow of interactive objects into four independent and ordered stages: acquisition, loading, unloading, and release. In the acquisition and release stages, the system uses asynchronous methods to read raw data and write back dirty data, maximizing the input / output performance of the underlying storage. In the loading and unloading stages, internal calculations are performed serially, and the impact on the aforementioned front-end modules is undone, ensuring absolute consistency in the state of data when it is accessed and removed from the front-end modules. This principle of separating time-consuming asynchronous operations from serial changes in core states fundamentally eliminates the potential for contention and conflict during concurrent data access, ensuring the robustness of the system.

[0032] Furthermore, in one possible implementation, the interactive objects contained within the target grid data exist in a data-hosted form; the data-hosted form includes: Point cloud data: records the basic type, unique ID, and spatial location of interactive objects; Decorative data: Used to override or extend component properties and behaviors of interactive objects; When the front-end module interacts with the interactive object, the system dynamically creates a complete interactive object entity based on the point cloud data and decoration data for the front-end module to use.

[0033] By adopting a data-hosted approach, the way interactive objects exist in a scene has been completely transformed. Most of the time, interactive objects reside in memory as lightweight point cloud and decoration data, used to record basic type, location, and component attribute information. Only when a front-end module actually interacts with an interactive object will the system extract this lightweight data and dynamically instantiate a complete interactive object entity. Through this on-demand construction principle, the system avoids the inefficient use of memory space by massive static interactive object entities, substantially optimizing memory resource utilization in complex 3D scenes containing a large number of interactive elements.

[0034] Given limited memory, it is also necessary to clean up the grid data in order to free up memory in a timely manner.

[0035] Therefore, in one possible implementation, the data management method also includes a grid replacement step, specifically including: When the preset triggering conditions are met, grid data that meets the preset elimination rules is selected from the memory-state cache as elimination candidates; Each candidate for elimination is assessed for importance, and grid data that belongs to the system's critical data is skipped; Elimination candidates that pass the importance assessment will be removed from the memory cache.

[0036] Specific eviction rules are defined here: during cache cleanup, not only are eviction candidates selected, but an additional interception step based on importance assessment is added. By identifying and proactively skipping grid data that belongs to critical system data, the system ensures that while freeing up available memory space, core and necessary scenario data remains safely stored in the in-memory cache. This mechanism can effectively prevent system crashes or malfunctions caused by the accidental deletion of critical data, while controlling the overall memory usage.

[0037] Of course, those skilled in the art will understand that the specific triggering conditions for memory release are not limited.

[0038] In one possible implementation, the preset triggering conditions include: Execute periodically with a fixed or adaptive threshold time period; And / or, execute when the usage of the memory-state cache is detected to exceed a set threshold.

[0039] This can be understood as follows: by combining periodic execution over a time period with execution based on memory cache usage exceeding a set threshold, a dual triggering mechanism of proactive prevention and reactive response is constructed. On the one hand, regular inspections and cleanup of long-term idle data maintain the vitality of memory space circulation; on the other hand, when encountering a sudden surge in data causing a spike in memory usage, it can respond immediately and forcibly execute cleanup actions. This flexible triggering strategy ensures that the system's memory level remains within a safe and healthy operating range for a long time.

[0040] Secondly, it is understandable that the specific method of removing the grid from the memory cache is also not limited.

[0041] In one possible implementation, removing eviction candidates that have passed importance evaluation from the in-memory cache includes: Removed elimination candidates are serialized and downgraded and stored in the local database as warm data for quick reloading. Alternatively, the memory space corresponding to the removed candidate can be released directly, retaining only its original backup in static storage as cold data.

[0042] On the one hand, the three-tiered caching system, consisting of in-memory cache, local database, and static storage, effectively balances read speed and capacity. On the other hand, when grid data is removed from the in-memory cache, the system does not simply destroy it. Instead, it serializes it according to a strategy and stores it in a local database with access speeds between memory and the underlying disk as warm data, or directly releases the memory while retaining only cold data backups in static storage. This hierarchical scheduling principle ingeniously balances the inherent contradiction between data access latency and storage medium capacity, enabling obsolete data to be quickly reloaded at a relatively low cost when accessed again in the future, thus improving the overall flexibility of data scheduling.

[0043] Furthermore, there are no restrictions on the specific method used to request the corresponding target grid data.

[0044] Please see Figure 2 , Figure 2 A schematic diagram of a single active object cache allocation in the gridded 3D scene data management method provided in this application.

[0045] like Figure 2 As shown, in one possible implementation, when there is only one active object in the 3D scene, the target mesh data request obtained through the data proxy layer includes: Determine an active region comprising nine grids, centered on the grid where the single active object is currently located; Allocate at least 7 grids of cache space for a single active object in the memory-state cache to cover its current position and all adjacent positions that can be reached in one step.

[0046] For single active objects, a smart cache allocation strategy based on spatial behavior prediction is proposed. The system breaks away from the traditional approach of only loading the currently located grid. Instead, it pre-allocates cache space in memory, covering at least seven grids that can be reached in one step from the current location and surrounding adjacent locations, using the grid where the single active object is currently located as the core. Through this spatial preloading principle, regardless of which direction the active object jumps or moves a short distance within its nine-grid activity area, the required target grid data is already silently resident in memory. This completely eliminates the lag caused by the loading of new data when the object crosses grid boundaries, ensuring a continuous and smooth scene interaction experience.

[0047] Of course, when there are multiple active objects in a 3D scene, the specific methods for requesting the corresponding target mesh data will differ.

[0048] In one possible implementation, when there are N active objects in the 3D scene, obtaining the target mesh data through the data proxy layer also includes: Allocate 7 grids of cache space in the in-memory cache for the first active object; Starting from the second active object, calculate the spatial overlap between the active region of each newly added active object and the cache region of existing active objects; Based on spatial overlap, only an additional 4 grids of incremental cache space are allocated for each newly added active object to ensure that adjacent active objects do not trigger new loading when the boundary is active.

[0049] Considering that different active objects often overlap in viewport space, this scheme allocates a basic 7-grid cache for the first active object and then uses an algorithm to calculate the spatial overlap between the activity areas of each subsequent newly added active object and existing objects. By eliminating the overlapping portions, the system allocates an additional 4 grids of incremental cache space only for newly added active objects. This shared boundary cache mechanism breaks the inherent bottleneck of the linear increase in memory demand with the number of objects in the traditional independent caching mode. While maintaining a seamless experience of moving all adjacent active objects, it significantly reduces the memory load on the server in dense scenarios.

[0050] Finally, the final data output method of the gridded 3D scene data management method provided in this application is not limited.

[0051] In one possible implementation, returning the target mesh data to the front-end module along the original path includes: The unified external interface layer of the data proxy layer outputs to the front-end module. The unified external interface layer only exposes basic operations for the target grid data. The interactive objects within the target grid data are encapsulated and output through a unified interactive object interface. The unified interactive object interface only provides limited read and write capabilities for the unique ID, location, and basic configuration attributes of the interactive objects.

[0052] By unifying the external interface layer and the unified interaction object interface, the data output to the front end is strictly encapsulated and isolated. The method exposes only the most basic data operation commands and limited read / write capabilities to the front end module, completely black-boxing the underlying grid data storage structure, lazy coding mechanism, and state transition details. This encapsulated output principle cuts off the direct path for the front end module to tamper with the underlying core data, not only improving data security throughout its lifecycle but also making future code refactoring and structural optimization at the data management level completely transparent to the front end module, greatly enhancing the maintainability and functional scalability of the entire software system.

[0053] The above is a complete description of the management method for gridded 3D scene data provided in this application.

[0054] Correspondingly, a second aspect of this application provides a management system for meshed 3D scene data, comprising: The front-end module is used to send target mesh data requests and receive the returned target mesh data for scene rendering or interactive processing. The data management module is connected to the front-end module. The data management module includes four levels: top-level management layer, parent management layer, child management layer, and data proxy layer. It is used to execute any of the aforementioned data management methods based on a gridded 3D scene. The static storage module, connected to the data management module, is used for backend persistent storage of raw binary data in the 3D scene.

[0055] By defining the overall connection relationships between the front-end module, data management module, and data storage module, a grid-based 3D scene data management system with clear logical boundaries is provided. This system architecture ensures the physical or logical carriers of each node in the data flow, enabling abstract methods and steps such as data loading, multi-level caching, and lifecycle management to be effectively executed and transferred through specific module components. This provides system-level underlying support for the engineering deployment and practical application of the entire data management solution.

[0056] It should be noted that the embodiments of the present invention have better implementability and are not intended to limit the present invention in any way. Any person skilled in the art may use the above-disclosed technical content to change or modify it into equivalent effective embodiments. However, any modifications or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.

Claims

1. A data management method for a gridded 3D scene, characterized in that, The data management method relies on a three-tier storage system consisting of in-memory cache, local database, and static storage, including: The system receives target grid data requests from the front-end module, and the top-level management layer performs global scheduling and routing of these requests. The target grid data request is routed to the corresponding parent management layer, which processes the request according to the request type and schedules the corresponding child management layer. The underlying data proxy layer is scheduled by the sub-level management layer, wherein the data proxy layer serves as a persistent data container to manage the original data of the interactive objects; The data proxy layer obtains the target grid data corresponding to the target grid data request, and performs state management on the interactive objects associated with the target grid data according to a preset lifecycle. The target grid data is returned to the front-end module along the original path.

2. The data management method for a gridded 3D scene as described in claim 1, characterized in that, The state management of the interactive objects associated with the target grid data according to the preset lifecycle includes: The raw data of the interactive object is read asynchronously from the data proxy layer for centralized processing of input and output operations; The original data is subjected to serial internal calculations and state initialization to put the data into a ready state for access by the front-end module. Undo the impact of the original data on the front-end module and prepare to release resources; Dirty data is re-encoded and asynchronously written back to the persistent data container, and the corresponding memory object is set to null.

3. The data management method for a gridded 3D scene as described in claim 2, characterized in that, The interactive objects contained within the target grid data exist in a data hosting format; the data hosting format includes: Point cloud data: records the basic type, unique ID, and spatial location of interactive objects; Decorative data: Used to override or extend component properties and behaviors of interactive objects; When the front-end module interacts with the interactive object, the system dynamically creates a complete interactive object entity based on the point cloud data and the decoration data for the front-end module to use.

4. The data management method for a gridded 3D scene as described in claim 1, characterized in that, The data management method also includes a grid elimination step, specifically including: When the preset triggering conditions are met, grid data that meets the preset elimination rules is selected from the memory-state cache as elimination candidate data; The importance of each elimination candidate is evaluated, and grid data that belongs to the system's critical data is skipped; Elimination candidates that pass the importance assessment are removed from the memory-state cache.

5. The data management method for a gridded 3D scene as described in claim 4, characterized in that, The preset triggering conditions include: Execute periodically with a fixed or adaptive threshold time period; And / or, execute when the usage rate of the memory-state cache is detected to exceed a set threshold.

6. The data management method for a gridded 3D scene as described in claim 4, characterized in that, The step of removing the elimination candidates that have passed the importance assessment from the memory cache includes: The removed elimination candidates are serialized and downgraded before being stored in the local database as warm data for quick reloading. Alternatively, the memory space corresponding to the removed candidate can be released directly, retaining only its original backup in the static storage as cold data.

7. The data management method for a gridded 3D scene as described in claim 1, characterized in that, When there is only one active object in the 3D scene, obtaining the target mesh data corresponding to the target mesh data request through the data proxy layer includes: Centered on the grid where the single active object is currently located, an active area comprising nine grids is determined; In the memory-state cache, at least 7 grids of cache space are allocated for the single active object to cover its current position and all adjacent positions that can be reached in one step.

8. The data management method for a gridded 3D scene as described in claim 1, characterized in that, When there are N active objects in a 3D scene, the step of obtaining the target mesh data corresponding to the target mesh data request through the data proxy layer further includes: Allocate 7 grids of cache space in the memory-state cache for the first active object; Starting from the second active object, calculate the spatial overlap between the active region of each newly added active object and the cache region of existing active objects; Based on the aforementioned spatial overlap, only an additional 4 grids of incremental cache space are allocated for each newly added active object to ensure that adjacent active objects do not trigger new loading when the boundary is active.

9. The data management method for a gridded 3D scene as described in claim 1, characterized in that, The step of returning the target grid data to the front-end module along the original path includes: The data proxy layer outputs to the front-end module through a unified external interface layer, which only exposes basic operations for the target grid data. The interactive objects within the target grid data are encapsulated and output through a unified interactive object interface. The unified interactive object interface only provides limited read and write capabilities for the unique ID, location, and basic configuration attributes of the interactive objects.

10. A management system for gridded 3D scene data, characterized in that, include: The front-end module is used to send target mesh data requests and receive the returned target mesh data for scene rendering or interactive processing. A data management module, connected to the front-end module, includes four layers: a top-level management layer, a parent management layer, a child management layer, and a data proxy layer, and is used to execute the data management method for a mesh-based 3D scene as described in any one of claims 1-9. A static storage module, connected to the data management module, is used for backend persistent storage of raw binary data in the 3D scene.

Images