Simulation model light map dynamic loading optimization method, device, equipment and medium

Abstract

This invention relates to a method, apparatus, device, and medium for dynamically loading and optimizing lighting and shadow textures in simulation models, belonging to the field of computer graphics technology. This application significantly reduces the size of the application's base package and shortens the initial loading time by decoupling lighting and shadow texture resources from the model and generating lightweight metadata; it improves the rigidity of traditional full loading by enabling on-demand loading of lighting and shadow resources through resource subpackaging and remote addressing; it effectively reduces resource redundancy and memory consumption by sharing texture map sets and repeating lightmaps; it enhances resource loading smoothness and reduces network requests through two-level caching and viewpoint prediction preloading; and it stabilizes memory usage through runtime dynamic binding and automatic resource reclamation, comprehensively improving the loading speed and running smoothness of WebGL 3D applications while ensuring the visual quality of baked lighting and shadows.

Description

Technical Field

[0001] This invention belongs to the field of computer graphics technology, specifically relating to a method, apparatus, device, and medium for dynamically loading and optimizing the light and shadow texture of a simulation model. Background Technology

[0002] With the maturity of WebGL technology, running complex 3D interactive applications in browsers has become a reality for the Unity WebGL export platform. The Unity engine greatly simplifies the development process for such applications through its WebGL export functionality. However, to achieve high-quality static lighting effects on the WebGL platform, developers must rely on light baking techniques. Baked lightmaps typically have high resolution, resulting in large individual map sizes. The traditional approach is to package all models and their associated lightmaps and other resources into the initial asset package of the WebGL application, which directly leads to the following prominent technical problems: The basic package size is bloated: the high-resolution light maps make the initial download size of the application huge, resulting in long waiting times for users on their first visit and a poor user experience.

[0003] Severe resource redundancy: Duplicate models in the scene (such as valves, bolts, etc.) each have independent but identical lightmaps, which are repeatedly stored in the package, resulting in a waste of network transmission and memory space.

[0004] Rigid loading strategy: All lighting and shadow resources are loaded at startup regardless of whether the current viewpoint requires them, and cannot be loaded and unloaded on demand based on user browsing behavior, resulting in low memory utilization.

[0005] WebGL platform limitations: The WebGL environment has certain limitations on access to memory and local storage, and extensive resource management can easily lead to insufficient memory or cache overflow.

[0006] Therefore, there is an urgent need for an innovative resource management solution that can achieve dynamic loading and efficient rendering of high-quality baked lighting effects under the strict constraints of WebGL, and completely resolve the contradiction between package size and visual quality. Summary of the Invention

[0007] This invention provides a method, apparatus, computer device, and storage medium for dynamic loading optimization of lighting and shadow textures in simulation models. The purpose is to solve the technical problems in WebGL applications caused by the full packaging of high-precision baking lighting and shadow resources, such as large basic package size, slow initial loading, high resource redundancy, and coarse runtime memory management.

[0008] To achieve the above objectives, the technical solution of the present invention is as follows: This application provides a method for dynamically loading and optimizing the light and shadow texture of a simulation model, including the following steps: The model in the WebGL simulation scene is traversed, and the lighting and texture resources on which each model depends are analyzed and extracted. The lighting and texture resources include light maps, light probes, and reflection probe resources. A resource dependency graph is constructed based on the corresponding dependency relationship between the model and the lighting and texture resources. The model and the lighting and texture resources are decoupled and serialized into lightweight metadata. The lightweight metadata is associated with and stored with the model prefab. Construct an asynchronous loading engine that supports priority scheduling and error retries, package the light and shadow texture resources into a remotely addressable resource package, and establish an address mapping relationship between the lightweight metadata and the resource package; Using the simulation scene model as input, duplicate models are identified and classified into a shared group. The light maps of the models in the shared group are merged and baked into a shared texture set, so that multiple models in the shared group can reference the same light and shadow texture resource. A two-level caching system of memory and persistent storage is established, wherein the two-level caching system includes a first-level memory cache and a second-level cache. The first-level memory cache is located in memory, and the second-level cache uses the browser's index database interface to achieve persistent storage. The future field of view is predicted based on camera parameters, and the light and shadow texture resources associated with the model that is about to enter the future field of view are preloaded. During WebGL simulation, the asynchronous loading engine loads model prefabs and their associated lightweight metadata and resource packages on demand. The lighting and texture resources corresponding to the resource packages are dynamically bound to the rendering pipeline to restore the lighting and shadow effects of the model. The usage status of the lighting and texture resources is monitored, and inactive lighting and texture resources are unloaded and recycled.

[0009] Furthermore, the step of constructing a resource dependency graph based on the corresponding dependency relationship between the model and the lighting and texture resources, decoupling the model and the lighting and texture resources and serializing them into lightweight metadata, and storing the lightweight metadata in association with the model prefab, includes: A directed acyclic graph is constructed using the model as a node and the light and shadow texture resources that the model depends on as edges, serving as a resource dependency graph; The static binding relationship between the model and the lighting and texture resources is decoupled and serialized into lightweight metadata containing only resource reference indexes and coordinate transformation parameter information. The lightweight metadata is then bound and stored in a custom component on the model prefab.

[0010] Furthermore, the construction of an asynchronous loading engine that supports priority scheduling and error retries, packages the lighting and texture resources into remotely addressable resource packages, and establishes an address mapping relationship between the lightweight metadata and the resource packages, including: Configure the light and shadow texture resources as addressable assets, and logically group and package them into independent resource packages, and establish the address mapping relationship between the lightweight metadata and the resource packages; An asynchronous loading engine is formed by constructing a loading management module that includes priority task scheduling, dependency resolution, concurrency control, and loading error retries based on the resource dependency graph.

[0011] Furthermore, the process of using a simulated scene model as input, identifying duplicate models and classifying them into a shared group, and merging and baking the lightmaps of models within the shared group into a shared texture set, so that multiple models within the shared group reference the same light and shadow texture resource, includes: The number of vertices in the model Triangle topology hash value Triangle index sequence hash value Material instance unique identifier and the hash value of the UV layout features of illumination Combined into multidimensional feature vectors The multidimensional feature vector is serialized and then the globally unique fingerprint code is calculated using the MD5 hash algorithm. Based on fingerprint consistency, models with the same fingerprint are grouped into the same shared group; A blank texture is created for each shared group as a shared baked texture atlas. The MaxRects rectangular binning heuristic algorithm is used to calculate the spatial layout of the UV rectangles of the lightmaps of all models in the shared group to obtain the layout result. Based on the layout results, the UV channel coordinates of each model are dynamically modified to complete UV remapping. Global lighting baking is then performed to ensure that the lighting map information of the shared group is uniformly baked into the shared baked texture atlas. Update the texture coordinate transformation parameters in the lightweight metadata corresponding to each model. The texture coordinate transformation parameters correspond to the position and range of the model in the shared baked texture atlas.

[0012] Furthermore, the step of using the MaxRects rectangular binning heuristic algorithm to perform spatial layout calculations on the UV rectangles of the lightmaps of all models within the shared group to obtain the layout results includes: The MaxRects rectangular boxing heuristic algorithm is used to calculate the spatial layout of the UV rectangles of the lightmaps for all models within a shared group. The formula is as follows: ,in This is a collection of lightmap UV rectangles for all models within the shared group. Each lightmap UV rectangle By its width and height definition, The total width of the shared baking texture atlas, To share the total height of the baking texture atlas, The coordinates of the lightmap UV rectangle within the shared baked texture atlas; The MaxRects rectangular binning heuristic algorithm is used to calculate the spatial layout of the UV rectangles of the lightmaps of all models in the shared group, and maintain a list of available rectangular spaces. Initialize the list of available rectangular spaces This indicates that the shared baking texture atlas is not in use; All lightmap UV rectangles to be arranged are sorted by area ( Sort in descending order; Iterate through the current list of available rectangular spaces to find one that can accommodate each lightmap UV rectangle. The target area is the location with the smallest remaining space after placement. Place the UV rectangle of the light map on the target area and record the coordinates of the target area. ; Remove the target region from the list of available rectangular spaces, and mark the area in the target region where the lightmap UV rectangle is placed as an occupied area; The remaining rectangles generated by dividing the occupied area are added back to the list of available rectangle spaces; Returns the placement coordinates of all lightmap UV rectangles. This results in a layout.

[0013] Furthermore, the establishment of a two-level caching system consisting of memory and persistent storage includes: A two-level cache system is established, consisting of a first-level memory cache located in memory and a second-level cache that utilizes the browser's index database interface for persistent storage. Active lighting and texture resources are stored in the first-level memory cache. When the cache capacity of the first-level memory cache exceeds a set threshold, the resource with the shortest last access time is selected and removed. The second-level cache uses the browser's index database interface to persistently store accessed light and shadow texture resources; Once the lighting and texture resources are successfully loaded over the network, they are stored in the first-level memory cache. At the same time, the binary data of the lighting and texture resources is asynchronously written to the second-level cache, and the version hash value of the lighting and texture resources is recorded. When reading a target lighting and texture resource, check if the target lighting and texture resource exists in the secondary cache. If it exists and matches the version hash value of the target lighting and texture resource, then read the target lighting and texture resource from the secondary cache. If the target lighting and texture resource does not exist or the version hash value does not match, then download the target lighting and texture resource from the remote server.

[0014] Furthermore, the step of predicting the future field of view based on camera parameters and preloading the lighting and texture resources associated with the model that is about to enter the future field of view includes: In each frame update, the camera's current position, forward vector, and current motion velocity vector are obtained, and a cone-shaped prediction region with a preset angle and preset distance is defined in front of the camera. Let the current position of the camera be... The forward vector is The current velocity vector is The prediction time window is The prediction time window is a preset time threshold, representing the prediction of the camera's future... The browsing area within the frame; pass Predicting cameras in the future The endpoint reached after the frame is used as the vertex of the cone-shaped prediction region; the value is taken when the camera is stationary. Then the predicted termination position is taken as , The preset minimum detection distance is defined as the termination position, which is the distance extended along the forward vector. point; The effective detection distance of the cone-shaped prediction region is: ,in For camera motion rate; The cone-shaped prediction region for ,in The half-apex angle of the cone-shaped prediction region; The conical prediction region is converted into an axis-aligned bounding box as the query body. The BVH space index pre-built in the scene is traversed to filter out the models that overlap with the query body. The light and shadow texture resources associated with the models are submitted to the asynchronous loading engine for preloading.

[0015] Furthermore, during WebGL simulation scene runtime, the asynchronous loading engine loads the model prefab and its associated lightweight metadata and resource packages on demand, dynamically binds the lighting and texture resources corresponding to the resource packages to the rendering pipeline to restore the model's lighting and texture effects, monitors the usage status of the lighting and texture resources, and unloads and reclaims inactive lighting and texture resources, including: After loading the model prefab in the WebGL simulation scene, an asynchronous loading request is initiated through the asynchronous loading engine to load the lightweight metadata and lighting and texture resources associated with the model prefab; once the lightweight metadata and lighting and texture resources are loaded, the dynamic binding process is triggered. The loaded lightmap texture is created as a new light data instance, added to the global lightmap array, and the model renderer is traversed to update its lightmap index and texture coordinate transformation parameters according to the lightweight metadata to complete the runtime binding. A reference counter is maintained for each dynamically loaded lighting and texture resource. When the lighting and texture resource is used, the reference count of its corresponding reference counter increases. When the models associated with the lighting and texture resource are destroyed, set to invisible, or determined to be no longer needed, the reference count of its corresponding reference counter decreases. When the reference count of the lighting and texture resource's corresponding reference counter is zero and the idle timeout period has passed, the lighting and texture resource is released and the cache state is updated.

[0016] On the other hand, a dynamic loading and optimization device for lighting and shadow mapping of a simulation model is provided, the device comprising: The resource parsing module is used to traverse the models in the WebGL simulation scene, analyze and extract the lighting and texture resources that each model depends on. The lighting and texture resources include light maps, light probes and reflection probe resources. Based on the corresponding dependency relationship between the model and the lighting and texture resources, a resource dependency relationship graph is constructed. The model and the lighting and texture resources are decoupled and serialized into lightweight metadata. The lightweight metadata is associated with and stored with the model prefab. The loading engine module is used to build an asynchronous loading engine that supports priority scheduling and error retries, package the light and shadow texture resources into remotely addressable resource packages, and establish an address mapping relationship between the lightweight metadata and the resource packages. The resource reuse module is used to take the simulation scene model as input, identify duplicate models and classify them into a shared group, merge and bake the light maps of the models in the shared group into a shared texture set, so that multiple models in the shared group can reference the same light and shadow texture resource. The cache preloading module is used to establish a two-level cache system of memory and persistent storage. The two-level cache system includes a first-level memory cache and a second-level cache. The first-level memory cache is located in memory, and the second-level cache uses the browser's index database interface to achieve persistent storage. It predicts the future field of view based on camera parameters and preloads the light and shadow texture resources associated with the model that will soon enter the future field of view. The rendering management module is used to load model prefabs and their associated lightweight metadata and resource packages on demand through the asynchronous loading engine when the WebGL simulation scene is running. It dynamically binds the lighting and texture resources corresponding to the resource packages to the rendering pipeline to restore the lighting and shadow effects of the model, monitors the usage status of the lighting and texture resources, and unloads and reclaims inactive lighting and texture resources.

[0017] In another aspect, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of a method for dynamically loading and optimizing the light and shadow texture of a simulation model.

[0018] In another aspect, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of a method for dynamically loading and optimizing the light and shadow texture of a simulation model.

[0019] This invention aims to significantly reduce the size of the application's base package and shorten the initial load time by decoupling lighting and texture resources from the model and generating lightweight metadata; it improves the rigidity of traditional full loading by enabling on-demand loading of lighting and texture resources through resource subpackaging and remote addressing; it effectively reduces resource redundancy and memory consumption by sharing texture map sets and repeating lightmaps; it enhances resource loading smoothness and reduces network requests through two-level caching and viewpoint prediction preloading; and it stabilizes memory usage through runtime dynamic binding and automatic resource reclamation. While ensuring the visual quality of baked lighting and shadows, it comprehensively improves the loading speed and running smoothness of WebGL 3D applications. Attached Figure Description

[0020] Figure 1 This is a flowchart of the dynamic loading and optimization method for the light and shadow texture of the simulation model in Embodiment 1 of the present invention; Figure 2 This is a flowchart illustrating the implementation of step S1 of the present invention; Figure 3 This is a schematic diagram of the directed acyclic construction in step S12 of the present invention; Figure 4 This is a flowchart illustrating the implementation of step S2 of the present invention; Figure 5 This is a flowchart illustrating the implementation of step S3 of the present invention; Figure 6This is a flowchart illustrating the implementation of step S4 of the present invention; Figure 7 This is a flowchart of the viewpoint prediction preloading algorithm in step S42 of the present invention; Figure 8 This is a schematic diagram of the viewpoint prediction preloading algorithm in step S42 of the present invention; Figure 9 This is a flowchart illustrating the implementation of step S5 of the present invention; Figure 10 This is a flowchart illustrating the operation of the dynamic loading and optimization method for the light and shadow texture of the simulation model in Embodiment 1 of the present invention. Figure 11 This is a flowchart of the dynamic loading and optimization method for the light and shadow texture of the simulation model in Embodiment 2 of the present invention; Figure 12 This is a structural block diagram of the simulation model light and shadow texture dynamic loading optimization device in an embodiment of the present invention; Figure 13 This is an internal structural diagram of a computer device in an embodiment of the present invention. Detailed Implementation

[0021] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] A method for dynamically loading and optimizing the lighting and shadow mapping of a simulation model, such as Figure 1 As shown, it includes the following steps: Step S1) Scene lighting dependency analysis and metadata extraction Traverse the model nodes in the WebGL simulation scene, analyze and extract the lightmap, light probe and reflection probe resource information that each model depends on, and construct a resource dependency graph; decouple the binding relationship between the model and the lighting resources and serialize it into lightweight configuration metadata, and store it in association with the model prefab.

[0023] This involves traversing the target WebGL simulation scene, analyzing the dependencies of each model on lighting resources, and extracting and serializing lightweight configuration metadata, such as... Figure 2 As shown.

[0024] In this embodiment, the key sub-steps in step S1 are operated as follows: Step S11) Scene traversal and information collection Run a custom editor script in the Unity editor to preprocess the published scene. The script iterates through all model prefab instances in the scene's root directory. For each prefab, it further iterates through all its MeshRenderer components, collecting their lightmapIndex and lightmapScaleOffset properties, and then reverse-searches the LightmapData objects they reference, recording the unique identifiers (GUIDs or Addressables) of texture resources such as lightmapColor and lightmapDir. Simultaneously, it collects the identifiers and key parameters of the LightProbeGroup and ReflectionProbe associated with the model's location.

[0025] Analyze the mesh renderer material of each model in the scene to obtain its referenced lightmap index, associated light probe group identifier, and reflection probe information.

[0026] Step S12) Dependency graph construction and metadata serialization Using the model as a node and the lighting resources it depends on as edges, a directed acyclic graph is constructed to describe the loading dependencies. At the same time, the index, identifier and texture coordinate transformation parameters are serialized into lightweight metadata and stored in a custom component bound to the model prefab.

[0027] Based on the information collected in step S11, a Directed Acyclic Graph (DAG) is constructed in memory, such as... Figure 3 As shown in the diagram, the nodes are divided into two categories: model nodes and resource nodes (textures, probes, etc.). Edges pointing from model nodes to resource nodes represent "dependencies." This diagram is used to analyze and optimize loading order.

[0028] Simultaneously, the model lighting map index, texture coordinate transformation parameters, and associated probe identifiers collected in step S11 are used as metadata content to create a custom C# script component, DynamicLightingMetaData, for each model prefab. The collected, decoupled pure data (resource address, original index, scaling offset value, probe ID, etc.) is serialized and stored in the component's public fields, forming lightweight configuration metadata, as shown in Table 1. This metadata file is extremely small, typically only a few KB.

[0029] Table 1. Example of metadata structure Step S2) Design of asynchronous loading engine for lighting and shadow resources and resource packaging An asynchronous loading engine supporting priority scheduling is designed based on a resource management system; the actual light and shadow texture resources obtained from the analysis are packaged into independent AssetBundle resource packages that can be remotely addressed, and an address mapping relationship is established with the metadata generated in step S1.

[0030] This involves building an asynchronous loading engine based on a resource management system and packaging texture resources into remotely addressable independent packages, such as... Figure 4 As shown.

[0031] In this embodiment, the key sub-steps in step S2 are operated as follows: Step S21) Addressable resource configuration and packaging Resource management is performed using Unity's Addressables system. Lightmaps, reflection probe cubemaps, and other lighting resources are configured as addressable assets and logically grouped and packaged into independent AssetBundles. All textures referenced by LightmapData and baked cubemaps of ReflectionProbes identified in step S1 are marked as "Addressable" in Unity Editor. Subsequently, based on the scene's spatial structure or functional modules, these resources are grouped and packaged into multiple independent AssetBundle files. A unique key is assigned to each resource or resource group.

[0032] Step S22) Implementation of the core logic of the asynchronous loading engine Create a singleton management class, AssetLoadManager. This class will design a load management module that implements priority task scheduling, concurrency control, and a load error retry mechanism based on a dependency graph. Its core responsibilities include: Task queue management: Maintain a priority task queue. Priority is determined by resource type (e.g., resources required by the model in the current viewport are Critical, and preloaded resources are High) and dependency depth.

[0033] Dependency loading: Before loading a model, query the dependency graph generated in step S1 to ensure that all texture and probe resource loading tasks that it depends on have been submitted or completed.

[0034] Concurrency and lifecycle control: Controls the maximum number of concurrent network requests to prevent browser congestion. Manages interactions with the Addressables system, handling resource loading (LoadAssetAsync) and releasing (Release) in a unified manner.

[0035] Step S3) Optimization of Shared Baking Texture Atlas Generation and Reuse Identify duplicate models with the same or similar structure in the scene, merge their independent lightmaps to generate a shared baked texture atlas, and enable multiple model instances to reference the same texture resource package to eliminate storage and memory redundancy.

[0036] This involves identifying duplicate models and merging their lightmaps into a shared baked texture atlas to eliminate redundancy, such as... Figure 5 As shown.

[0037] In this embodiment, the key sub-steps in step S3 are operated as follows: Step S31) Automatic identification of repetitive models Before baking, a tool is used to calculate the mesh fingerprint of all model prefabs in the scene. The number of vertices, triangle topology, triangle index sequence hash value, material instance unique identifier, and lighting UV layout features of the model are combined into a multi-dimensional feature vector. : in: Number of vertices in the model; : Hash value of the triangular topology; The hash value of the triangular index sequence; : A unique identifier for a material instance; : Hash value of the UV layout characteristics of illumination.

[0038] The specific calculation methods for each feature are as follows: Number of vertices : Directly read the length of the mesh vertex array; Hash value of triangular topology Traverse all triangle faces in the mesh, sort the three vertex indices of each triangle and concatenate them into a string. After combining the ordered indices of all triangles into a sequence, use the SHA256 hash algorithm to calculate the topological hash value, ensuring that models with the same topological structure but different vertex orders are still identified as the same model. Hash value of the triangular index sequence : Serialize the grid triangle index array into a binary stream in sequence, perform MD5 hash calculation on the entire index buffer, and obtain the unique feature value of the index layout; Material instance unique identifier : Directly read the InstanceID of the material instance; Hash value of illumination UV layout features Extract all vertex coordinates of the UV lighting in the model, construct a four-dimensional statistical vector based on the minimum, maximum, mean, and variance of the UV coordinates, and serialize the statistical vector into binary and perform MD5 hashing to obtain the feature hash value of the UV lighting layout.

[0039] The components of the feature vector are concatenated into a byte sequence in a fixed order. For example, in a simulation engine, a numeric type can be converted to a byte array using BitConverter.GetBytes(), and a string can be converted to a byte array using Encoding.UTF8.GetBytes(). Then, all byte arrays are merged into a single byte array. The globally unique fingerprint of this byte array is calculated using the MD5 hash algorithm. An MD5 instance is created using MD5.Create(), and the ComputeHash method is called to convert the feature byte array into a 128-bit hash value. ; in This describes the process of serializing the components of the feature vector into byte arrays. Based on the consistency of the generated fingerprints, identical models are automatically grouped into the same "shared group" so that a shared set of texture maps can be baked subsequently.

[0040] Step S32) UV remapping and merging baking Create a large, blank texture (e.g., 2048×2048 pixels) for each "shared group" as a shared baked texture atlas. Before light baking, use the MaxRects rectangular binning heuristic algorithm to calculate the spatial layout of the UV rectangles of the lightmaps for all models within the group. The basic idea of ​​this algorithm is to maintain a list of available rectangular spaces and select the optimal placement position each time, achieving a non-overlapping, high-space-utilization arrangement of all rectangles. ; in: For the first The coordinates of the top-left corner of the UV rectangle of each model in the shared baked texture atlas; This is a collection of UV rectangles for all models within the group, with each rectangle... By its width and height definition; These represent the total width and total height of the shared baking texture atlas, respectively.

[0041] The execution steps of the algorithm are as follows: Initialize the list of available rectangular spaces This indicates that the entire shared baking texture atlas area is not yet occupied; All rectangles to be arranged are sorted by area ( Arrange in descending order, prioritizing the placement of large rectangles to improve space utilization; For each rectangle : Iterate through the list of currently available rectangular spaces to find one that can accommodate the rectangle. And the position with the smallest remaining space after placement; Place the rectangle at that location and record its coordinates. ; Remove the occupied area from the list of available rectangular spaces; Add the remaining rectangles (usually the right and bottom rectangles) resulting from dividing the occupied area back to the list of available rectangle spaces; Returns the placement coordinates of all rectangles. .

[0042] Through the above steps, the algorithm can efficiently arrange all UV rectangles within the limited shared baked texture atlas space. Based on the layout result, the second set of UV channel coordinates for each model instance in the group is dynamically modified to complete UV remapping. Subsequently, global lighting baking is performed to uniformly bake the lighting information of the entire shared group to the shared baked texture atlas. Finally, the lightmapScaleOffset parameter in the DynamicLightingMetaData component of each model is updated to ensure that it accurately corresponds to the position and range of the model in the shared baked texture atlas.

[0043] Step S4) Implementation of multi-level caching and viewpoint prediction preloading strategy Establish a two-level caching mechanism of memory and persistent storage; combine the user's camera position, orientation and movement trend to predict the future field of view, and preload the light and shadow texture resources associated with the model that is about to enter the field of view.

[0044] This includes establishing a two-level caching system and predicting loading needs based on user viewpoint behavior, such as... Figure 6 As shown.

[0045] In this embodiment, the key sub-steps in step S4 are operated as follows: Step S41) Establishing a two-level cache architecture Level 1 memory cache: The AssetLoadManager class uses a dictionary structure to store references to loaded and currently active resource objects. The key is the resource address, and the value is the resource instance. To control memory usage, a cache capacity limit is set, and an LRU (Least Recently Used) strategy is employed for resource eviction.

[0046] The core idea of ​​the LRU (Least Recently Used) strategy is to prioritize evicting resources that have not been accessed for the longest time when cache space is insufficient. In its implementation, each cached resource maintains a last access timestamp. When the total cache capacity exceeds a set threshold... When this happens, the system selects the resource with the shortest last access time from all cached resources for eviction, that is: ; in: The collection of all resources currently in the memory cache; :resource The last access timestamp; This represents the independent variable that minimizes the objective function, i.e., the resource that is removed. .

[0047] The system repeats the above eviction process until the cache capacity falls below the threshold. Through the LRU strategy, frequently accessed resources are retained in memory, while infrequently accessed or long-unused resources are promptly cleaned up, achieving efficient reuse of memory resources.

[0048] Second-level cache (persistent cache): This utilizes the browser's IndexedDB API to achieve local persistent storage of resources. When a resource is successfully loaded over the network, the system not only stores it in the first-level memory cache but also asynchronously writes the resource's binary data to the second-level IndexedDB database, recording the resource's version hash value. The next time the application starts, the loading engine first checks if the required resource exists in IndexedDB: if it exists and the version matches, it is read directly from the local cache, avoiding network requests; if the resource is missing or the version has expired, the latest resource is downloaded from a remote server. This mechanism effectively reduces repeated network loading and improves the loading speed of subsequent accesses.

[0049] Step S42) Preloading based on viewpoint prediction In each frame update, the current position, forward vector, and current velocity vector of the main camera are obtained. Using this data, a fan-shaped or cone-shaped prediction region with a certain angle and distance is defined in front of the camera. Using a pre-built BVH spatial indexing system for the scene, all models that are completely or partially located within this prediction region are quickly retrieved.

[0050] To achieve accurate prediction and efficient spatial querying of the camera's field of view, a core algorithm for viewpoint prediction preloading is designed. The algorithm flowchart is as follows: Figure 7 As shown, this algorithm takes real-time camera motion parameters as input, constructs a prediction region through geometric calculations, and extracts the target model using a spatial indexing algorithm. The specific implementation is as follows: 1. Algorithm Definition Let the real-time motion parameters of the camera be feature parameters in three-dimensional space, specifically including: Current 3D position of the camera: ,in These are the X, Y, and Z coordinates of the camera in the world coordinate system, respectively. Current forward vector of the camera: , is a unit vector representing the camera's viewing direction; Camera current velocity vector: It is calculated from the position difference between two adjacent frames of the camera and represents the direction and speed of camera movement; Forecast time window: , which is a preset time threshold (unit: frames, configurable from 5-15 frames depending on scene complexity), characterizing the prediction of the camera's future... The browsing area within the frame.

[0051] 2. Calculation Formula Based on the above parameters, a cone-shaped prediction region in front of the camera is constructed, balancing accuracy and computational efficiency. The key calculation formulas are as follows: Camera predicts termination position: ; The formula calculates the camera in the future. The possible positions reached after a frame are used as vertices of the prediction region. If the camera is stationary ( If the predicted termination position is taken as... That is, extending a preset distance along the forward vector. point.

[0052] Predicted effective detection range in the region: ; in For camera motion rate, The preset minimum detection distance (e.g., 20 scene units) ensures that there is still a preload range when the camera is stationary.

[0053] Radius of the base of the predicted region cone: ; in The half-apex angle of the cone-shaped region is set to a default value in this embodiment. This characterizes the field of view coverage of the camera.

[0054] 3. Spatial Query Logic Based on the cone-shaped prediction region constructed using the above formula, the BVH spatial indexing algorithm is used to quickly extract the model within the region. The algorithm is illustrated below. Figure 8 As shown. The steps are: BVH indexes are pre-built for all models in the WebGL simulation scene, with each model corresponding to a bounding box node, and the three-dimensional spatial coordinate range of the node is recorded. Transform the cone-shaped prediction region into an AABB as the query body: and Using the line connecting the two points as the central axis, with Given a radius, calculate the minimum AABB that encompasses the entire cone; Traverse the BVH tree and filter out the model nodes that overlap with the query body through bounding box intersection detection. These are the target models within the prediction region. Submit the lighting and shadow resources associated with the target model to the medium-high priority queue of the loading engine.

[0055] Once the model is retrieved, a loading task is immediately submitted to the AssetLoadManager, requesting the lighting resources recorded in the model's metadata (DynamicLightingMetaData) and assigning them high priority. This ensures that the resources begin loading before the user actually sees the model.

[0056] Step S5) Runtime dynamic binding and intelligent resource lifecycle management During WebGL runtime, the model prefab and its metadata are loaded on demand through the loading engine, and the corresponding lighting and texture resources are loaded asynchronously. After loading is complete, the textures are dynamically bound to the rendering pipeline to restore the model's lighting and shadow effects. At the same time, the resource usage status is monitored, and inactive resources are automatically unloaded and recycled.

[0057] In the WebGL runtime environment, after loading lighting and shadow resources, they are dynamically bound to the rendering pipeline to restore high-quality visual effects. The resource usage status is continuously monitored and automatically reclaimed, thus achieving fine-grained memory management and stable operation while ensuring visual quality. The implementation process of this step is as follows: Figure 9 As shown.

[0058] In this embodiment, the key sub-steps in step S5 are operated as follows: Step S51) Resource loading completes, triggering binding initialization. Once the model prefab is instantiated through the asynchronous loading engine, its attached DynamicLightingMetaData metadata component is activated. This component reads its internally serialized resource addressing information and submits an asynchronous loading request to the loading engine. After asynchronously acquiring the specified lightmap texture and reflection probe texture, the loading engine sends a loading completion notification to the requesting metadata component, thereby triggering the subsequent dynamic binding process. This design ensures that resource loading and model instantiation logic are decoupled, and the binding operation only starts after the resources are truly ready.

[0059] After the model instance is loaded, its attached metadata component initiates an asynchronous loading request for the lighting and shadow resources at the specified address; once the resources are loaded, the dynamic binding process is triggered.

[0060] Step S52) Dynamic reconstruction of the lighting system and update of renderer parameters The loaded lightmap texture is created as a new light data instance, added to the global lightmap array, and the model renderer is traversed to update its lightmap index and texture coordinate transformation parameters according to the metadata, thus completing the runtime binding.

[0061] This step is crucial for accurately restoring the baked lighting and shadow effects at runtime. Upon receiving the resource loading completion notification, the metadata component executes the following refactoring logic: Dynamic expansion of the lightmap array: The system wraps newly loaded lightmap textures into new lighting data objects and appends these objects to the end of the rendering engine's global lightmap array. This operation dynamically expands the list of valid lightmaps at runtime.

[0062] Renderer binding parameter remapping: The system iterates through all mesh renderers that require lightmaps for the current model. For each renderer, its original lightmap index values, stored in metadata, are recalculated to map to the correct position of the new texture in the global array. Simultaneously, the original texture coordinate scaling and offset parameters stored in metadata are applied to ensure that UV sampling correctly corresponds to specific areas of the new texture. Through these two steps, the model renderer and the newly loaded physical texture are re-associated at runtime.

[0063] Reflection and Lighting Probe Effect Restoration: For reflection probes, the system assigns the loaded cubemap texture to the baked texture attribute of the corresponding probe component in the scene and restores its intensity, range, and other parameters. For lighting probes, the dynamic lighting effect is restored by passing the spherical harmonic lighting coefficients recorded in the metadata to the model material or custom shader attribute.

[0064] Step S53) Intelligent resource reclamation based on reference and status monitoring Maintain a reference counter for each dynamically loaded resource. When all associated models are destroyed or removed from view and idle timeouts occur, automatically release resource memory and update cache status.

[0065] To maintain the memory health of WebGL applications for long-term operation, the system implements an automated resource reclamation mechanism: Reference Counting and State Tracking: The loading engine maintains a reference counter for each lighting and texture resource loaded through it. Whenever a model successfully binds to a resource through its metadata component and begins using it, the resource's reference count increases; when a model is destroyed, set to invisible, or determined by a strategy to no longer need the resource, the reference count decreases. Simultaneously, the system records the last access timestamp for each resource.

[0066] Reclamation Criteria Determination and Execution: The system periodically scans the status of all loaded resources. When a resource simultaneously meets both conditions—"reference count is zero" and "idle time exceeds a preset threshold"—it is determined to be a reclaimable resource. Subsequently, the system calls the resource management interface to release the memory occupied by the resource, removes it from the first-level cache, and updates its metadata in the second-level cache for possible future fast reloading.

[0067] Lifecycle state closed loop: Through the dual-factor decision-making of reference counting and time thresholds, resources achieve complete lifecycle closed-loop management from "loading", "binding for use", "idle" to "final release", as shown in Table 2. This ensures that only currently and recently necessary resources are retained in memory, effectively avoiding the problem of unlimited memory growth that may be caused by users continuously browsing complex scenarios.

[0068] Table 2. Lifecycle Status Table of Light and Shadow Resources Through the systematic implementation of steps S1 to S5, the method of the present invention constructs a complete technical solution from offline analysis, resource optimization, intelligent preloading to runtime dynamic binding and automated management, enabling WebGL applications to achieve high-fidelity baked lighting and shadow visual effects while significantly improving startup speed, running smoothness and memory efficiency.

[0069] This embodiment discloses a flowchart of an operation method for dynamically loading and optimizing the light and shadow texture of a simulation model, as follows: Figure 10 As shown, taking the Unity engine and Addressables resource management system as an example, the following steps are included to implement the streaming loading and dynamic rendering of model baking lighting and shadows in a ship painting simulation scene: 1) Scene Preprocessing and Metadata Generation Stage: Open the ship painting simulation scene in the Unity editor. Attach a custom LightingMetaData script component to the root node of all painting segment model prefabs. After performing Baked Global Illumination, run the accompanying tools to automatically traverse the scene, extract the lightmap index, scaling offset parameters, and associated probe information of each segment model's MeshRenderer, and serialize and store them in the corresponding LightingMetaData component, forming lightweight metadata.

[0070] 2) Resource Analysis and Addressables Packaging Stage: Use the Unity Addressables system to manage lighting and shadow resources. Mark all lightmap textures and reflection probe cubemaps identified in the previous step as addressable assets. Based on the layout of the painting area, group and package the lighting and shadow resources of different areas (such as the segmented stacking area, painting room, and preprocessing area) into independent resource packages (e.g., Lighting_PaintingShop_01). For multiple "standard segmented" models with the same structure in the scene, enable the shared baked texture atlas function to merge and bake their lighting information into a single 2048x2048 shared baked texture atlas, eliminating duplicate storage.

[0071] 3) WebGL Build and Deployment Phase: The WebGL project is built. The build scheme ensures that only model meshes, materials, scripts, and LightingMetaData metadata are included in the base package (.data files, etc.). All addressable lighting and texture resource packages will be separated and deployed on the cloud or a CDN (Content Delivery Network) server. Ultimately, the size of the WebGL application base package for this ship painting scene is reduced from the traditional 1.5GB to approximately 200MB.

[0072] 4) Runtime Preloading and Caching Phase: When a user accesses the WebGL application through a browser, the application starts after quickly loading the base package. As the user navigates in the virtual shipyard and moves towards the painting area, the system predicts that the user is about to enter the painting area based on the camera position and motion vectors, and asynchronously loads the Lighting_PaintingShop_01 resource package into the memory cache in advance. Simultaneously, resources loaded for the first time by the application are automatically stored in the browser's IndexedDB persistent cache, allowing subsequent access to the same area to be read directly from the local cache, greatly reducing network requests and waiting time.

[0073] 5) Dynamic Binding and Rendering Phase: As the user's viewpoint approaches the area where the ship painting site is located, the prefab of the painting segment model is instantiated. The LightingMetaData component on the prefab is activated, initiating an asynchronous texture request based on its stored metadata address (e.g., "Lightmap_Segment_TypeA_01"). After the texture resources are loaded, the component automatically executes the dynamic binding logic: dynamically inserting the loaded texture into the LightmapSettings.lightmaps array and updating the lightmapIndex and lightmapScaleOffset of all rendered components of the segment model. Rendering and binding are completed when the model enters the user's view. The painting segment model presents high-quality baked lighting effects with delicate shadows, environmental reflections, and global illumination, achieving visual realism indistinguishable from native applications.

[0074] 6) Memory Management and Effect Verification Phase: After the user leaves the painting area and enters the hull assembly area, the system detects that the painting segment model is no longer visible and its lighting resources have been idle for more than a preset idle threshold. It then automatically calls Addressables.Release to release the relevant texture resources. Through browser developer tools, it can be observed that the application's memory usage intelligently fluctuates with the user's browsing path, with no memory leaks or cumulative increases, while maintaining a smooth 60fps interactive frame rate and cinematic visual quality throughout.

[0075] Example 2 Example 2 includes all the technical features of Example 1, such as Figure 11 As shown in Example 2, a method for dynamically loading and optimizing the light and shadow texture of a simulation model includes the following steps: Step S10) Traverse the models in the WebGL simulation scene, analyze and extract the lighting and texture resources that each model depends on. The lighting and texture resources include light maps, light probes and reflection probe resources. Construct a resource dependency graph based on the corresponding dependency relationship between the model and the lighting and texture resources. Decouple the model and the lighting and texture resources and serialize them into lightweight metadata. Associate and store the lightweight metadata with the model prefab. Step S20) Construct an asynchronous loading engine that supports priority scheduling and error retries, package the light and shadow texture resources into a remotely addressable resource package, and establish an address mapping relationship between the lightweight metadata and the resource package; Step S30) Using the simulation scene model as input, identify duplicate models and classify them into a shared group. Merge and bake the light maps of the models in the shared group into a shared texture set so that multiple models in the shared group can reference the same light and shadow texture resource. Step S40) Establish a two-level cache system of memory and persistent storage, wherein the two-level cache system includes a first-level memory cache and a second-level cache. The first-level memory cache is located in memory, and the second-level cache uses the browser's index database interface to achieve persistent storage, predicts the future field of view based on camera parameters, and preloads the light and shadow texture resources associated with the model that is about to enter the future field of view. Step S50) During the WebGL simulation scene runtime, the asynchronous loading engine loads the model prefab and its associated lightweight metadata and resource package on demand, dynamically binds the lighting and texture resources corresponding to the resource package to the rendering pipeline to restore the lighting and shadow effects of the model, monitors the usage status of the lighting and texture resources, and unloads and reclaims inactive lighting and texture resources.

[0076] Specifically, by decoupling lighting and texture resources from the model and generating lightweight metadata, the size of the application's base package can be significantly reduced, shortening the initial loading time; on-demand loading of lighting and texture resources is achieved through resource subpackaging and remote addressing, improving the rigidity of traditional full loading; resource redundancy and memory consumption are effectively reduced by sharing texture map sets and repeating lightmaps; resource loading smoothness is improved and network requests are reduced through two-level caching and viewpoint prediction preloading; runtime dynamic binding and automatic resource reclamation can stabilize memory usage, comprehensively improving the loading speed and running smoothness of WebGL 3D applications while ensuring the visual quality of baked lighting and shadows.

[0077] This invention effectively balances memory usage, loading speed, and visual quality in WebGL applications, achieving refined and intelligent dynamic scheduling of lighting and shadow resources. It can be widely applied in fields such as digital twins, web-based 3D display of industrial products, online virtual simulation, architectural visualization, and high-precision virtual reality. By implementing end-to-end optimization of lighting and shadow resources through "dynamic decoupling, on-demand loading, intelligent caching, and precise binding," it systematically resolves the contradiction between high-quality visual experience and fast loading performance on the WebGL platform, providing an efficient, flexible, and visually realistic lighting and shadow solution for applications such as digital twins, web-based 3D display of industrial products, and online virtual simulation.

[0078] Furthermore, the step of constructing a resource dependency graph based on the corresponding dependency relationship between the model and the lighting and texture resources, decoupling the model and the lighting and texture resources and serializing them into lightweight metadata, and storing the lightweight metadata in association with the model prefab, includes: A directed acyclic graph is constructed using the model as a node and the light and shadow texture resources that the model depends on as edges, serving as a resource dependency graph; The static binding relationship between the model and the lighting and texture resources is decoupled and serialized into lightweight metadata containing only resource reference indexes and coordinate transformation parameter information. The lightweight metadata is then bound and stored in a custom component on the model prefab.

[0079] By constructing a directed acyclic resource dependency graph, the loading order of models and resources can be clearly determined, avoiding loading errors. The decoupled information is serialized into lightweight metadata and bound to the prefab, further reducing the data volume, improving the efficiency of metadata reading and parsing, and providing a reliable basis for subsequent accurate loading.

[0080] Furthermore, the construction of an asynchronous loading engine that supports priority scheduling and error retries, packages the lighting and texture resources into remotely addressable resource packages, and establishes an address mapping relationship between the lightweight metadata and the resource packages, including: Configure the light and shadow texture resources as addressable assets, and logically group and package them into independent resource packages, and establish the address mapping relationship between the lightweight metadata and the resource packages; An asynchronous loading engine is formed by constructing a loading management module that includes priority task scheduling, dependency resolution, concurrency control, and loading error retries based on the resource dependency graph.

[0081] Among these features, modular resource management is achieved through addressable grouping and packaging, which further reduces the size of the basic package and facilitates maintenance; the asynchronous loading engine with priority scheduling, dependency resolution and error retries can improve loading stability and concurrency efficiency, avoid browser blocking, and ensure the continuous and reliable scene rendering process.

[0082] Furthermore, the process of using a simulated scene model as input, identifying duplicate models and classifying them into a shared group, and merging and baking the lightmaps of models within the shared group into a shared texture set, so that multiple models within the shared group reference the same light and shadow texture resource, includes: The number of vertices in the model Triangle topology hash value Triangle index sequence hash value Material instance unique identifier and the hash value of the UV layout features of illumination Combined into multidimensional feature vectors The multidimensional feature vector is serialized and then the globally unique fingerprint code is calculated using the MD5 hash algorithm. Based on fingerprint consistency, models with the same fingerprint are grouped into the same shared group; A blank texture is created for each shared group as a shared baked texture atlas. The MaxRects rectangular binning heuristic algorithm is used to calculate the spatial layout of the UV rectangles of the lightmaps of all models in the shared group to obtain the layout result. Based on the layout results, the UV channel coordinates of each model are dynamically modified to complete UV remapping. Global lighting baking is then performed to ensure that the lighting map information of the shared group is uniformly baked into the shared baked texture atlas. Update the texture coordinate transformation parameters in the lightweight metadata corresponding to each model. The texture coordinate transformation parameters correspond to the position and range of the model in the shared baked texture atlas.

[0083] Among them, the accuracy of shared group classification is improved by accurately identifying duplicate models through multi-dimensional features and MD5 fingerprints; the MaxRects algorithm is used to complete UV layout and shared atlas baking, which greatly reduces the number of light and shadow textures, realizes the reuse of multi-model resources, significantly reduces storage and memory overhead, and ensures that the accuracy of light and shadow rendering is not affected.

[0084] Furthermore, the step of using the MaxRects rectangular binning heuristic algorithm to perform spatial layout calculations on the UV rectangles of the lightmaps of all models within the shared group to obtain the layout results includes: The MaxRects rectangular boxing heuristic algorithm is used to calculate the spatial layout of the UV rectangles of the lightmaps for all models within a shared group. The formula is as follows: ,in This is a collection of lightmap UV rectangles for all models within the shared group. Each lightmap UV rectangle By its width and height definition, The total width of the shared baking texture atlas, To share the total height of the baking texture atlas, The coordinates of the lightmap UV rectangle within the shared baked texture atlas; The MaxRects rectangular binning heuristic algorithm is used to calculate the spatial layout of the UV rectangles of the lightmaps of all models in the shared group, and maintain a list of available rectangular spaces. Initialize the list of available rectangular spaces This indicates that the shared baking texture atlas is not in use; All lightmap UV rectangles to be arranged are sorted by area ( Sort in descending order; Iterate through the current list of available rectangular spaces to find one that can accommodate each lightmap UV rectangle. The target area is the location with the smallest remaining space after placement. Place the UV rectangle of the light map on the target area and record the coordinates of the target area. ; Remove the target region from the list of available rectangular spaces, and mark the area in the target region where the lightmap UV rectangle is placed as an occupied area; The remaining rectangles generated by dividing the occupied area are added back to the list of available rectangle spaces; Returns the placement coordinates of all lightmap UV rectangles. This results in a layout.

[0085] By standardizing the execution steps of the MaxRects algorithm, the UV rectangle layout is made efficient, reliable, and has high space utilization, providing a stable and feasible arrangement scheme for shared baked texture atlases, further improving the resource merging and optimization effect, and making the scheme reproducible.

[0086] Furthermore, the establishment of a two-level caching system consisting of memory and persistent storage includes: A two-level cache system is established, consisting of a first-level memory cache located in memory and a second-level cache that utilizes the browser's index database interface for persistent storage. Active lighting and texture resources are stored in the first-level memory cache. When the cache capacity of the first-level memory cache exceeds a set threshold, the resource with the shortest last access time is selected and removed. The second-level cache uses the browser's index database interface to persistently store accessed light and shadow texture resources; Once the lighting and texture resources are successfully loaded over the network, they are stored in the first-level memory cache. At the same time, the binary data of the lighting and texture resources is asynchronously written to the second-level cache, and the version hash value of the lighting and texture resources is recorded. When reading a target lighting and texture resource, check if the target lighting and texture resource exists in the secondary cache. If it exists and matches the version hash value of the target lighting and texture resource, then read the target lighting and texture resource from the secondary cache. If the target lighting and texture resource does not exist or the version hash value does not match, then download the target lighting and texture resource from the remote server.

[0087] Among them, by using a two-level cache of memory and index database to store resources, combined with the LRU eviction policy and version verification mechanism, memory can be used efficiently, duplicate network requests can be reduced, resource reading and scene switching speed can be accelerated, and the application's secondary access experience can be improved.

[0088] Furthermore, the step of predicting the future field of view based on camera parameters and preloading the lighting and texture resources associated with the model that is about to enter the future field of view includes: In each frame update, the camera's current position, forward vector, and current motion velocity vector are obtained, and a cone-shaped prediction region with a preset angle and preset distance is defined in front of the camera. Let the current position of the camera be... The forward vector is The current velocity vector is The prediction time window is The prediction time window is a preset time threshold, representing the prediction of the camera's future... The browsing area within the frame; pass Predicting cameras in the future The endpoint reached after the frame is used as the vertex of the cone-shaped prediction region; the value is taken when the camera is stationary. Then the predicted termination position is taken as , The preset minimum detection distance is defined as the termination position, which is the distance extended along the forward vector. point; The effective detection distance of the cone-shaped prediction region is: ,in For camera motion rate; The cone-shaped prediction region for ,in The half-apex angle of the cone-shaped prediction region; The conical prediction region is converted into an axis-aligned bounding box as the query body. The BVH spatial index (bounding body hierarchy) pre-built in the scene is traversed to filter out models that overlap with the query body. The light and shadow texture resources associated with the model are submitted to the asynchronous loading engine for preloading.

[0089] Among them, a cone-shaped prediction region is constructed by using camera parameters and combined with the BVH index to quickly filter models, achieving accurate preloading, avoiding screen stuttering caused by lag in loading of lighting and shadow resources, and improving the smoothness of scene browsing and the timeliness of lighting and shadow presentation.

[0090] Furthermore, during WebGL simulation scene runtime, the asynchronous loading engine loads the model prefab and its associated lightweight metadata and resource packages on demand, dynamically binds the lighting and texture resources corresponding to the resource packages to the rendering pipeline to restore the model's lighting and texture effects, monitors the usage status of the lighting and texture resources, and unloads and reclaims inactive lighting and texture resources, including: After loading the model prefab in the WebGL simulation scene, an asynchronous loading request is initiated through the asynchronous loading engine to load the lightweight metadata and lighting and texture resources associated with the model prefab; once the lightweight metadata and lighting and texture resources are loaded, the dynamic binding process is triggered. The loaded lightmap texture is created as a new light data instance, added to the global lightmap array, and the model renderer is traversed to update its lightmap index and texture coordinate transformation parameters according to the lightweight metadata to complete the runtime binding. A reference counter is maintained for each dynamically loaded lighting and texture resource. When the lighting and texture resource is used, the reference count of its corresponding reference counter increases. When the models associated with the lighting and texture resource are destroyed, set to invisible, or determined to be no longer needed, the reference count of its corresponding reference counter decreases. When the reference count of the lighting and texture resource's corresponding reference counter is zero and the idle timeout period has passed, the lighting and texture resource is released and the cache state is updated.

[0091] In one embodiment, such as Figure 12 As shown, a simulation model light and shadow texture dynamic loading optimization device 10 is provided, including: resource parsing module 1, loading engine module 2, resource reuse module 3, cache preloading module 4, and rendering management module 5.

[0092] The resource parsing module 1 is used to traverse the models in the WebGL simulation scene, analyze and extract the lighting and texture resources that each model depends on. The lighting and texture resources include light maps, light probes and reflection probe resources. A resource dependency graph is constructed according to the corresponding dependency relationship between the model and the lighting and texture resources. The model and the lighting and texture resources are decoupled and serialized into lightweight metadata. The lightweight metadata is associated with and stored with the model prefab. The loading engine module 2 is used to build an asynchronous loading engine that supports priority scheduling and error retries, package the light and shadow texture resources into a remotely addressable resource package, and establish an address mapping relationship between the lightweight metadata and the resource package; The resource reuse module 3 is used to take the simulation scene model as input, identify duplicate models and classify them into a shared group, merge and bake the light maps of the models in the shared group into a shared texture set, so that multiple models in the shared group can reference the same light and shadow texture resource. The cache preloading module 4 is used to establish a two-level cache system of memory and persistent storage. The two-level cache system includes a first-level memory cache and a second-level cache. The first-level memory cache is located in memory. The second-level cache uses the browser's index database interface to achieve persistent storage, predicts the future field of view based on camera parameters, and preloads the light and shadow texture resources associated with the model that will soon enter the future field of view. The rendering management module 5 is used to load model prefabs and their associated lightweight metadata and resource packages on demand through the asynchronous loading engine when the WebGL simulation scene is running. It dynamically binds the lighting and texture resources corresponding to the resource packages to the rendering pipeline to restore the lighting and shadow effects of the model, monitors the usage status of the lighting and texture resources, and unloads and reclaims inactive lighting and texture resources.

[0093] In the aforementioned simulation model's dynamic loading optimization device for light and shadow textures, the size of the application's base package can be significantly reduced and the initial loading time shortened by decoupling light and shadow texture resources from the model and generating lightweight metadata. On-demand loading of light and shadow resources is achieved through resource subpackaging and remote addressing, improving the rigidity of traditional full loading. Resource redundancy and memory consumption are effectively reduced by sharing texture map sets and repeating light maps. The smoothness of resource loading is improved and network requests are reduced through two-level caching and viewpoint prediction preloading. Runtime dynamic binding and automatic resource reclamation stabilize memory usage, comprehensively improving the loading speed and smoothness of WebGL 3D applications while ensuring the visual quality of baked light and shadows.

[0094] Specific limitations regarding the dynamic loading and optimization device for simulation model lighting and texture mapping can be found in the limitations of the dynamic loading and optimization method for simulation model lighting and texture mapping described above, and will not be repeated here. Each module in the aforementioned dynamic loading and optimization device for simulation model lighting and texture mapping can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0095] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 13 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and the database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores dynamic loading optimization data for the lighting and shading of simulation models. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements a method for dynamic loading optimization of lighting and shading for simulation models.

[0096] Those skilled in the art will understand that Figure 13The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0097] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of a method for dynamically loading and optimizing the lighting and shadow mapping of a simulation model.

[0098] For specific limitations on the steps implemented by the processor when executing a computer program, please refer to the limitations on the method of dynamic loading optimization of simulation model light and shadow textures above, which will not be repeated here.

[0099] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of a method for dynamically loading and optimizing the light and shadow texture of a simulation model.

[0100] For specific limitations on the steps implemented when a computer program is executed by a processor, please refer to the limitations on the method of dynamic loading optimization of light and shadow textures for simulation models mentioned above, which will not be repeated here.

[0101] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0102] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for dynamically loading and optimizing the light and shadow texture of a simulation model, characterized in that, Includes the following steps: The model in the WebGL simulation scene is traversed, and the lighting and texture resources on which each model depends are analyzed and extracted. The lighting and texture resources include light maps, light probes, and reflection probe resources. A resource dependency graph is constructed based on the corresponding dependency relationship between the model and the lighting and texture resources. The model and the lighting and texture resources are decoupled and serialized into lightweight metadata. The lightweight metadata is associated with and stored with the model prefab. Construct an asynchronous loading engine that supports priority scheduling and error retries, package the light and shadow texture resources into a remotely addressable resource package, and establish an address mapping relationship between the lightweight metadata and the resource package; Using the simulation scene model as input, duplicate models are identified and classified into a shared group. The light maps of the models in the shared group are merged and baked into a shared texture set, so that multiple models in the shared group can reference the same light and shadow texture resource. A two-level caching system of memory and persistent storage is established, wherein the two-level caching system includes a first-level memory cache and a second-level cache. The first-level memory cache is located in memory, and the second-level cache uses the browser's index database interface to achieve persistent storage. The future field of view is predicted based on camera parameters, and the light and shadow texture resources associated with the model that is about to enter the future field of view are preloaded. During WebGL simulation, the asynchronous loading engine loads model prefabs and their associated lightweight metadata and resource packages on demand. The lighting and texture resources corresponding to the resource packages are dynamically bound to the rendering pipeline to restore the lighting and shadow effects of the model. The usage status of the lighting and texture resources is monitored, and inactive lighting and texture resources are unloaded and recycled.

2. The method for dynamically loading and optimizing the lighting and shadow mapping of a simulation model according to claim 1, characterized in that, The step of constructing a resource dependency graph based on the correspondence between the model and the lighting and texture resources, decoupling the model and the lighting and texture resources and serializing them into lightweight metadata, and associating and storing the lightweight metadata with the model prefab includes: A directed acyclic graph is constructed using the model as a node and the light and shadow texture resources that the model depends on as edges, serving as a resource dependency graph; The static binding relationship between the model and the lighting and texture resources is decoupled and serialized into lightweight metadata containing only resource reference indexes and coordinate transformation parameter information. The lightweight metadata is then bound and stored in a custom component on the model prefab.

3. The method for dynamic loading and optimization of lighting and shadow mapping in simulation models according to claim 1, characterized in that, The construction of an asynchronous loading engine that supports priority scheduling and error retries, packages the lighting and texture resources into remotely addressable resource packages, and establishes an address mapping relationship between the lightweight metadata and the resource packages, including: Configure the light and shadow texture resources as addressable assets, and logically group and package them into independent resource packages, and establish the address mapping relationship between the lightweight metadata and the resource packages; An asynchronous loading engine is formed by constructing a loading management module that includes priority task scheduling, dependency resolution, concurrency control, and loading error retries based on the resource dependency graph.

4. The method for dynamic loading and optimization of lighting and shadow mapping in simulation models according to claim 1, characterized in that, The process involves taking a simulated scene model as input, identifying duplicate models and classifying them into a shared group, merging and baking the lightmaps of models within the shared group into a shared texture set, so that multiple models within the shared group can reference the same light and shadow texture resource, including: The number of vertices in the model Triangle topology hash value Triangle index sequence hash value Material instance unique identifier and the hash value of the UV layout features of illumination Combined into multidimensional feature vectors The multidimensional feature vector is serialized and then the globally unique fingerprint code is calculated using the MD5 hash algorithm. Based on fingerprint consistency, models with the same fingerprint are grouped into the same shared group; A blank texture is created for each shared group as a shared baked texture atlas. The MaxRects rectangular binning heuristic algorithm is used to calculate the spatial layout of the UV rectangles of the lightmaps of all models in the shared group to obtain the layout result. Based on the layout results, the UV channel coordinates of each model are dynamically modified to complete UV remapping. Global lighting baking is then performed to ensure that the lighting map information of the shared group is uniformly baked into the shared baked texture atlas. Update the texture coordinate transformation parameters in the lightweight metadata corresponding to each model. The texture coordinate transformation parameters correspond to the position and range of the model in the shared baked texture atlas.

5. The method for dynamic loading and optimization of lighting and shadow mapping in simulation models according to claim 4, characterized in that, The MaxRects rectangular binning heuristic algorithm is used to calculate the spatial layout of the UV rectangles of the lightmaps of all models within the shared group to obtain the layout results, including: The MaxRects rectangular boxing heuristic algorithm is used to calculate the spatial layout of the UV rectangles of the lightmaps for all models within a shared group. The formula is as follows: ,in This is a collection of lightmap UV rectangles for all models within the shared group. Each lightmap UV rectangle By its width and height definition, To share the total width of the baking texture atlas, To share the total height of the baking texture atlas, The coordinates of the lightmap UV rectangle within the shared baked texture atlas; The MaxRects rectangular binning heuristic algorithm is used to calculate the spatial layout of the UV rectangles of the lightmaps of all models in the shared group, and maintain a list of available rectangular spaces. Initialize the list of available rectangular spaces This indicates that the shared baking texture atlas is not in use; All lightmap UV rectangles to be arranged are sorted by area ( Sort in descending order; Iterate through the current list of available rectangular spaces to find one that can accommodate each lightmap UV rectangle. The target area is the location with the smallest remaining space after placement. Place the UV rectangle of the light map on the target area and record the coordinates of the target area. ; Remove the target region from the list of available rectangular spaces, and mark the area in the target region where the lightmap UV rectangle is placed as an occupied area; The remaining rectangles generated by dividing the occupied area are added back to the list of available rectangle spaces; Returns the placement coordinates of all lightmap UV rectangles. This results in a layout.

6. The method for dynamic loading and optimization of lighting and shadow mapping in simulation models according to claim 1, characterized in that, The aforementioned two-level caching system, consisting of in-memory and persistent storage, includes: A two-level cache system is established, consisting of a first-level memory cache located in memory and a second-level cache that utilizes the browser's index database interface for persistent storage. Active lighting and texture resources are stored in the first-level memory cache. When the cache capacity of the first-level memory cache exceeds a set threshold, the resource with the shortest last access time is selected and removed. The second-level cache uses the browser's index database interface to persistently store accessed light and shadow texture resources; Once the lighting and texture resources are successfully loaded over the network, they are stored in the first-level memory cache. At the same time, the binary data of the lighting and texture resources is asynchronously written to the second-level cache, and the version hash value of the lighting and texture resources is recorded. When reading a target lighting and texture resource, check if the target lighting and texture resource exists in the secondary cache. If it exists and matches the version hash value of the target lighting and texture resource, then read the target lighting and texture resource from the secondary cache. If the target lighting and texture resource does not exist or the version hash value does not match, then download the target lighting and texture resource from the remote server.

7. The method for dynamic loading and optimization of lighting and shadow mapping in simulation models according to claim 1, characterized in that, The method of predicting the future field of view based on camera parameters and preloading the lighting and texture resources associated with the model that is about to enter the future field of view includes: In each frame update, the camera's current position, forward vector, and current motion velocity vector are obtained, and a cone-shaped prediction region with a preset angle and preset distance is defined in front of the camera. Let the current position of the camera be... The forward vector is The current velocity vector is The prediction time window is The prediction time window is a preset time threshold, representing the prediction of the camera's future... The browsing area within the frame; pass Predicting cameras in the future The endpoint reached after the frame is used as the vertex of the cone-shaped prediction region; the value is taken when the camera is stationary. Then the predicted termination position is taken as , The preset minimum detection distance is defined as the termination position, which is the distance extended along the forward vector. point; The effective detection distance of the cone-shaped prediction region is: ,in For camera motion rate; The radius of the base of the cone-shaped prediction region is: ,in The half-apex angle of the cone-shaped prediction region; The conical prediction region is converted into an axis-aligned bounding box as the query body. The BVH space index pre-built in the scene is traversed to filter out the models that overlap with the query body. The light and shadow texture resources associated with the models are submitted to the asynchronous loading engine for preloading.

8. The method for dynamically loading and optimizing the lighting and shadow mapping of a simulation model according to claim 1, characterized in that, During WebGL simulation runtime, the asynchronous loading engine loads model prefabs and their associated lightweight metadata and resource packages on demand. The corresponding lighting and texture resources of the resource packages are dynamically bound to the rendering pipeline to restore the model's lighting effects. The usage status of the lighting and texture resources is monitored, and inactive lighting and texture resources are unloaded and reclaimed, including: After loading the model prefab in the WebGL simulation scene, an asynchronous loading request is initiated through the asynchronous loading engine to load the lightweight metadata and lighting and texture resources associated with the model prefab; once the lightweight metadata and lighting and texture resources are loaded, the dynamic binding process is triggered. The loaded lightmap texture is created as a new light data instance, added to the global lightmap array, and the model renderer is traversed to update its lightmap index and texture coordinate transformation parameters according to the lightweight metadata to complete the runtime binding. A reference counter is maintained for each dynamically loaded lighting and texture resource. When the lighting and texture resource is used, the reference count of its corresponding reference counter increases. When the models associated with the lighting and texture resource are destroyed, set to invisible, or determined to be no longer needed, the reference count of its corresponding reference counter decreases. When the reference count of the lighting and texture resource's corresponding reference counter is zero and the idle timeout period has passed, the lighting and texture resource is released and the cache state is updated.

9. A device for dynamically loading and optimizing the light and shadow texture of a simulation model, characterized in that, The device includes: The resource parsing module is used to traverse the models in the WebGL simulation scene, analyze and extract the lighting and texture resources that each model depends on. The lighting and texture resources include light maps, light probes and reflection probe resources. Based on the corresponding dependency relationship between the model and the lighting and texture resources, a resource dependency relationship graph is constructed. The model and the lighting and texture resources are decoupled and serialized into lightweight metadata. The lightweight metadata is associated with and stored with the model prefab. The loading engine module is used to build an asynchronous loading engine that supports priority scheduling and error retries, package the light and shadow texture resources into remotely addressable resource packages, and establish an address mapping relationship between the lightweight metadata and the resource packages. The resource reuse module is used to take the simulation scene model as input, identify duplicate models and classify them into a shared group, merge and bake the light maps of the models in the shared group into a shared texture set, so that multiple models in the shared group can reference the same light and shadow texture resource. The cache preloading module is used to establish a two-level cache system of memory and persistent storage. The two-level cache system includes a first-level memory cache and a second-level cache. The first-level memory cache is located in memory, and the second-level cache uses the browser's index database interface to achieve persistent storage. It predicts the future field of view based on camera parameters and preloads the light and shadow texture resources associated with the model that will soon enter the future field of view. The rendering management module is used to load model prefabs and their associated lightweight metadata and resource packages on demand through the asynchronous loading engine when the WebGL simulation scene is running. It dynamically binds the lighting and texture resources corresponding to the resource packages to the rendering pipeline to restore the lighting and shadow effects of the model, monitors the usage status of the lighting and texture resources, and unloads and reclaims inactive lighting and texture resources.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the simulation model light and shadow texture dynamic loading optimization method according to any one of claims 1 to 7.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the simulation model light and shadow texture dynamic loading optimization method according to any one of claims 1 to 7.

Images