Scene resource package generation method and device, equipment and medium

Abstract

The application relates to a scene resource package generation method and device, equipment and a medium. The method comprises the following steps: determining the distance level of each scene object according to the visible distance of each scene object for a scene map of a game world, forming a logical object set of each level; dividing the area where each logical object set is distributed into a plurality of scene blocks in space according to the level division standard of each level, each block containing a scene object original model falling into the block and belonging to the level; generating a model of the scene block of each level from near to far along the distance level sequence, the model being obtained by degeneration of the original model specific to the level and the models generated by all previous levels which are spatially overlapped; and finally constructing a scene resource package containing a detailed model mapping table for calling by a client. The application improves the resource package generation efficiency and helps to realize fine streaming loading and rendering.

Description

Technical Field

[0001] This application relates to the field of game image processing technology, and in particular to a method, apparatus, device, and medium for generating scene resource packs. Background Technology

[0002] In the development of large-scale 3D games, especially open-world games, streaming is a common technique for managing massive scene resources and ensuring smooth game operation. The basic idea is to dynamically load the resource data required for a game area only when the player character (virtual camera) approaches it, and unload it when the player moves away, thus avoiding the enormous memory pressure and loading latency caused by loading the entire game world at once.

[0003] In traditional technologies, the game world is typically pre-divided into multiple regions. To support streaming loading, the development process can prepare rendering resources for all scene objects contained within each region, packaging them into a data package that can be loaded at runtime. Simultaneously, a fixed loading distance threshold can be set for the entire scene map. During game runtime, the distance from the virtual camera to each region is continuously calculated and compared with the preset loading distance threshold to determine whether to load or unload the entire region's data package.

[0004] However, this traditional preprocessing and data packaging method has significant limitations in practical applications. The fundamental reason is that it uses the entire area as the sole granularity for resource organization and management, ignoring the vast differences in visual attributes between objects within a plot of land. An area typically contains multiple types of objects simultaneously, such as massive castles visible from a great distance, trees visible at medium distances, and vegetation and gravel that can only be discerned at close range. The effective viewing distances for these objects are drastically different.

[0005] During the preprocessing stage, traditional packaging methods simply include all these objects and their detailed models at all levels into the resource package for that area. This results in coarse-grained, undifferentiated data packets. Since runtime loading decisions can only be made for the entire data packet, developers are forced to set a single loading distance threshold for the entire area. This threshold is often a trade-off: if it is set to meet the long-distance visibility requirements of the most prominent objects (such as castles), it will cause a large number of secondary near-field objects to be loaded prematurely and consequently, resulting in wasted memory resources and redundant I / O transfers; if it is set to meet the needs of most near-field objects, it may cause important far-field objects to be missing from the player's field of vision when they should appear, because the entire tile they belong to has not met the loading conditions, resulting in visual voids or abrupt pop-up effects.

[0006] Therefore, there is a fundamental contradiction between the inherent data organization of scene resource packages generated by traditional preprocessing methods and the fine-grained scheduling requirements of runtime. This contradiction not only makes runtime resource scheduling difficult to optimize, but also places a heavy burden on content creators, who often need to spend a lot of time manually adjusting the loading distance of different object groups, and it is difficult to guarantee the consistency of global performance.

[0007] It is evident that traditional technologies, due to their inherent coarse-grained data organization patterns, have become a key bottleneck restricting the efficient, refined streaming loading and high-performance rendering of large-scale game scenes, and urgently need improvement. Summary of the Invention

[0008] The purpose of this application is to solve the above-mentioned problems by providing a method for generating scene resource packages and corresponding apparatus, devices, non-volatile readable storage media, and computer program products.

[0009] According to one aspect of this application, a method for generating a scene resource package is provided, comprising: For the scene map of the game world, based on the visible distance of each scene object in the scene map, determine the target distance level in the distance level sequence to which each scene object belongs, and define the scene objects belonging to the same distance level as the logical object set of that distance level. According to the corresponding tier segmentation specifications for each distance tier, the area where the logical object set corresponding to the distance tier is distributed is divided into multiple scene blocks in the spatial dimension. Each scene block contains the original model of the scene objects belonging to the logical object set that fall within its spatial range. Along the distance ladder sequence from near to far, a model of the scene object in its scene block is generated for each distance ladder. The model of any distance ladder is obtained by spatially simplifying the original model of the scene object that falls within the spatial range of the scene block and is unique to that distance ladder, with the models generated by all preceding distance ladders that overlap with the scene block in space. A scene resource package is constructed for the game program running on the client to call. The scene resource package contains a detailed model mapping table for recording the mapping relationship between each scene object in the scene plot and the model used in the corresponding scene block at each distance level.

[0010] According to another aspect of this application, a scene resource package generation apparatus is provided, comprising: The tier division module is set to target the scene map of the game world. Based on the visible distance of each scene object in the scene map, it determines the target distance tier in the distance tier sequence to which each scene object belongs, and defines the scene objects belonging to the same distance tier as the logical object set of that distance tier. The logical segmentation module is configured to divide the area where the logical object set corresponding to each distance step is distributed into multiple scene blocks in the spatial dimension according to the corresponding step segmentation specification. Each scene block contains the original model of the scene object belonging to the logical object set that falls within its spatial range. The degeneracy generation module is configured to generate a model of the scene object in the scene block for each distance step in the distance step sequence from near to far. The model of any distance step is obtained by spatially degenerated based on the original model of the scene object that falls within the spatial range of the scene block and is unique to that distance step, and the models generated by all preceding distance steps that overlap with the scene block in space. The resource package module is configured to construct scene resource packages for the game program running on the client to call. The scene resource package contains a detailed model mapping table for recording the mapping relationship between each scene object in the scene plot and the model used in the corresponding scene block at each distance level.

[0011] According to another aspect of this application, an electronic device is provided, including a central processing unit and a memory, wherein the central processing unit is configured to invoke and run a computer program stored in the memory to perform the steps of the method described in this application.

[0012] According to another aspect of this application, a non-volatile readable storage medium is provided, which stores a computer program implemented according to the scene resource package generation method in the form of computer-readable instructions, wherein the computer program is invoked by a computer to execute the steps included in the method.

[0013] According to another aspect of this application, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method.

[0014] This application automates the construction of a structured scene resource package containing a mapping table by automatically dividing the space into levels based on visible distance, segmenting the space according to the level specifications, and iteratively simplifying along the distance sequence to generate multi-level detail models. Compared with traditional technologies, this application achieves a leap in refined management from the region level to the scene block level, allowing for independent setting of loading timing for distant and near objects, thus avoiding memory waste and visual voids from the source. Simultaneously, the automatically generated models at different levels ensure smooth visual transitions and efficient rendering. Furthermore, this application standardizes and batches the traditionally manual processes, greatly improving the automation and standardization of content production. Attached Figure Description

[0015] Figure 1This is an exemplary network architecture used in this application to run the game; Figure 2 This is a flowchart illustrating one embodiment of the scene resource package generation method of this application; Figure 3 This is a schematic diagram illustrating the relationship between the visible distance and distance levels of the objects in the scenario described in this application. Figure 4 This is a schematic diagram illustrating the relationship between scene blocks in the same area corresponding to different distance levels in the game world of this application; Figure 5 This is a schematic diagram illustrating the principle of the geometric projection formula used in this application; Figure 6 This is a schematic diagram of the scene resource package generation device of this application; Figure 7 This is a schematic diagram of the structure of an electronic device used in this application. Detailed Implementation

[0016] The technical solution of this application can be deployed in the preprocessing and content production pipeline that supports the development of large-scale 3D game scenes. Figure 1 This diagram schematically illustrates a typical deployment architecture, which includes a preprocessing device (which can be integrated into a developer's workstation or build server) for content development and processing, and a terminal device that ultimately runs the game as a client. The preprocessing device is responsible for executing the scene resource package generation method of this application, automatically analyzing, processing, and packaging the raw scene data in the game world to generate structured scene resource packages. These resource packages can then be distributed to the server 81 or the terminal device 80 via a network or storage medium. The terminal device 80, such as a personal computer, game console, or mobile device, is the carrier that ultimately consumes these scene resource packages and runs the game client application. The server 81 is responsible for maintaining the global state and logic of the game world.

[0017] This application is particularly applicable to building streaming-ready scene assets for open-world games or massively multiplayer online games with vast geographical spaces and massive visual details. In such applications, the game world is typically viewed as a complete scene map containing tens of thousands of scene objects with varying geometric complexities, visual importance, and spatial distributions, such as terrain, buildings, vegetation, and props. Traditional content production methods struggle to efficiently and scientifically automate logical layering, spatial segmentation, multi-level detail model generation, and the setting of reasonable streaming parameters for such a massive number of objects. This application aims to provide a complete method that, during the preprocessing stage, automatically and in batches completes the entire process from object analysis, logical object set partitioning, scene segmentation, iterative degeneracy, to structured encapsulation of resource packages based on the scene objects' own visual attributes. This generates refined scene resource packages that can be efficiently invoked by the client, fundamentally improving content production efficiency and laying a data foundation for high-performance rendering at runtime.

[0018] The scene resource package generation method of this application can be implemented step by step by a specific computing hardware system including a processor, memory, and dedicated computing units (such as CPUs or GPUs for mesh processing). Specifically, in the preprocessing device, the processor is responsible for performing core logical tasks such as traversing scene objects, analyzing spatial dependencies, batch calculating visible distances, automatically partitioning distance tiers, determining logical object sets, applying tier partitioning specifications, generating scene blocks, iterative degeneracy operations, and organizing and serializing metadata and mapping tables. The memory is used to store the original scene data of the game world, intermediate calculation results, and the finally generated scene resource package. The dedicated computing unit can accelerate the execution of computationally intensive degeneracy operations such as geometry merging and mesh simplification. Through the specific programming and collaboration of the above hardware components, the method of this application transforms and implements the traditionally highly manual, fragmented, and error-prone scene data preparation work into a rule-driven, batch-executable automated preprocessing pipeline. This pipeline directly produces scenario resource packages with optimized structure and rich metadata, substantially improving the standardization, automation level and data quality of content production, thereby providing high-performance and easy-to-manage data assets at the physical level for subsequent game packaging, distribution and operation.

[0019] To facilitate understanding of subsequent embodiments, some basic concepts involved in this application are uniformly explained here. Scene map, in this application, refers to the complete geographic space of the game world to be processed, and is the overall unit for integrated processing in this application. Scene object is a basic element or combination of elements constituting the visual content of the game world, such as an independent or combined model instance. Visible distance is a theoretical value calculated for each scene object, representing the limit of spatial distance at which an observer can clearly see the object when the pixel proportion occupied by the scene object in the screen space is lower than a certain preset threshold. Distance tier is a logical classification of scene objects based on visible distance. Each tier corresponds to a distance range, which can be defined by the upper limit of the current distance tier and the distance tier closest to it. It should be noted that the visible distance and the upper limit of each distance tier are defined and measured based on the same spatial reference point. This reference point can be the spatial center point of the scene object itself, the center point of its geometric bounding box, or a representative location preset for processing convenience. Logical object set refers to the collection of all scene objects belonging to the same distance tier, and is the logical unit for subsequent spatial division and model processing in this application. The tiered partitioning specification is a predefined grid parameter used to spatially divide the area where the logical object set is distributed for each distance tier, determining the size of the scene chunks under that tier. A scene chunk is a cubic (or other regular-shaped) region with a certain geographical range, spatially divided according to the tiered partitioning specification of its distance tier. It is the smallest physical unit in streaming loading management that can be independently scheduled, resource-bound, and load / unloaded. Degeneracy, in this application, specifically refers to the process of geometrically merging and simplifying the models of multiple scene objects (whether original or simplified models) to generate a single aggregated model with less data and lower visual complexity. The various models of a scene object in different distance tiers are multiple model versions of the same scene object pre-prepared to adapt to different viewing distances (i.e., different distance tiers), with different levels of visual detail and geometric complexity. The higher the level of visual detail, the higher the accuracy of the corresponding model is usually. The detail model mapping table is a data structure that records the mapping relationship between each scene object in the scene map and the model used in the corresponding scene chunks of each distance tier. (Default) Streaming distance is a key distance threshold preset for each scene chunk to trigger its loading behavior at runtime. Its value can be determined based on the visible distance of the scene objects contained in the scene chunk.

[0020] After providing a general overview of the technical architecture, application scenarios, and basic concepts of this application, the specific implementation methods of this application will be described in detail below with reference to the accompanying drawings.

[0021] Please see Figure 2The scene resource package generation method of this application can be installed and run on an electronic device that serves as a preprocessing device for a computer program product. In some embodiments, it includes the following steps: Step S3100: For the scene map of the game world, based on the visible distance of each scene object in the scene map, determine the target distance level in the distance level sequence to which each scene object belongs, and define the scene objects belonging to the same distance level as the logical object set of that distance level. This step initiates the preprocessing workflow for the scene map of the entire game world. The scene map is the complete virtual game world to be processed. The goal of this application is to automatically generate a structured scene resource package for this complete map. The first step in the process is to determine the theoretical visible range of each basic visual element, i.e., scene object, within this scene map.

[0022] Therefore, the first step is to obtain the visible distance of each scene object within the scene map. The visible distance is a value calculated from the object's own spatial reference point (e.g., its geometric center). It represents the theoretically maximum spatial distance at which an observer, such as a virtual camera in a game scene, can clearly identify the object when its pixel proportion in screen space is below a certain preset threshold. There are several ways to obtain the visible distance. In one embodiment, the visible distance is pre-calculated and stored in the scene resource's metadata; in this case, the acquisition operation reads the corresponding value from that metadata. In another embodiment, the visible distance needs to be calculated in real-time during the preprocessing flow. The calculation can be based on the scene object's geometric bounding box size, a preset minimum pixel proportion threshold in screen space, and the field of view of a standard reference camera, using a preset geometric projection formula. Regardless of the method used, at the end of this step, each scene object within the scene map should be associated with a specific visible distance value.

[0023] After successfully obtaining the visible distances of all scene objects, each scene object can be assigned to its appropriate distance tier based on these distance values. The distance tier is a logical hierarchical system predefined in this application, consisting of a set of tiers ordered from near to far (or from far to near) by observation distance. Each distance tier has a clearly defined upper distance limit with the scene object as the reference point. The partitioning logic involves comparing the visible distance of a scene object with the upper distance limits of each distance tier sequentially. A typical partitioning algorithm is sequential search: starting from the distance tier with the smallest upper distance limit (corresponding to the closest observation distance), the visible distance of each scene object is sequentially compared with the upper distance limit of the current distance tier. When the first distance tier whose upper distance limit is greater than or equal to the visible distance of the scene object is found, the partitioning is complete, and the scene object is assigned to this distance tier, which becomes the target distance tier for that scene object.

[0024] For example, refer to Figure 3 Suppose there are three distance levels, L0, L1, and L2, with upper limits of 100 meters, 500 meters, and 2000 meters, respectively. If the visible distance of a scene object is 350 meters, it is greater than the upper limit of L0 (100 meters) but less than or equal to the upper limit of L1 (500 meters). Therefore, it will be assigned to distance level L1, which is its target distance level. After classifying all scene objects, all scene objects belonging to the same distance level (e.g., L1) together constitute the logical object set of that distance level. The logical object set is a logical grouping that includes all scene objects that become visible within the same theoretical observation distance range. This is the basic unit for subsequent spatial partitioning and model processing. Through this automated classification based on objective threshold comparison, all scene objects are scientifically and consistently organized into different logical sets, forming the data foundation for all subsequent refined processing steps.

[0025] Step S3200: According to the corresponding tier segmentation specifications for each distance tier, the area where the logical object set corresponding to the distance tier is distributed is divided into multiple scene blocks in the spatial dimension, wherein each scene block contains the original model of the scene object belonging to the logical object set that falls within its spatial range. After dividing all scene objects within the scene map into different distance tiers based on their visible distance and forming logical object sets for each tier, this step performs spatial physical organization for each distance tier. The purpose is to further divide scene objects logically belonging to the same visible range (i.e., the same distance tier) into a series of discrete, regular spatial units based on their actual geographical location, laying the physical foundation for subsequent model processing and runtime scheduling.

[0026] Therefore, a key parameter, namely the step-level segmentation specification, can be preset for each distance step. The step-level segmentation specification defines the size of the spatial grid used to divide the area where the logical object set is distributed within that distance step. In specific implementations, the step-level segmentation specification can be set as area data, or expressed as length multiplied by width; those skilled in the art can implement it flexibly accordingly. Combined with... Figure 4 The closer the distance step is to the observation point (e.g., L0), the smaller its step size, meaning the smaller the size of the resulting spatial grid (i.e., scene block 101), to support more refined local scheduling; conversely, the farther the distance step is from the observation point (e.g., L2), the larger its step size, and the larger the size of the resulting scene block 1; while the intermediate-scale step size results in a moderately sized scene block 10. Figure 3 It can be seen that, generally speaking, there can be a spatial inclusion relationship between scene blocks corresponding to different distance levels.

[0027] In practice, for a specific distance level to be processed, the preset level segmentation specification is first obtained. Then, in the game world coordinate system, using the grid size defined by this specification, a uniform and regular spatial grid is performed on the area where the logical object set of that distance level is distributed in the entire scene map (usually covering the entire map or related parts). This segmentation produces a series of spatially continuous, non-overlapping, and usually equal-sized cubic (or other regular-shaped) regions, each of which is defined as a scene block.

[0028] After dividing the scene into blocks, it is necessary to determine the scene objects contained in each scene block. The determination rule can be spatial containment: traverse each scene object in the logical object set of that distance tier and determine which scene block's spatial range its spatial reference point (or bounding box) falls into. If a scene object falls into a scene block, then the scene object's original model (i.e., its highest precision, unmerged and unsimplified version) is associated with that scene block. Therefore, each scene block ultimately contains a list recording all scene objects within its spatial range belonging to that distance tier and their original model references. This means that in the preprocessing stage, the scene block acts as a spatial container for objects, but it still contains the original, independent models of the scene objects, without any form of merging or simplification.

[0029] For example, continue to use Figure 3For example, assuming the gradient division specification for distance level L1 (mid-shot) is defined as a cubic grid with a side length of 200 meters, this 200-meter square grid can be used to divide the entire scene map. All scene objects divided into L1 in step S3100 will be assigned to these 200x200x200-meter scene blocks according to their location. A scene block containing trees and rocks will internally store the independent original high-precision models of these trees and rocks. Accordingly, the macroscopic scene map is transformed into a hierarchical spatial management structure composed of grids of different sizes (corresponding to different distance levels), and each grid unit (scene block) clearly defines the set of original scene objects it manages.

[0030] Step S3300: Along the distance ladder sequence from near to far, generate a model of the scene object in the scene block for each distance ladder. The model of any distance ladder is obtained by spatially simplifying the original model of the scene object that falls within the spatial range of the scene block and is unique to that distance ladder, with the models generated by all preceding distance ladders that overlap with the scene block in space. After organizing all scene objects into scene blocks of different distance levels according to the tiered segmentation specifications, the process continues to generate a unified simplified model for each scene block, which should be rendered at the corresponding viewing distance. This process does not generate a separate model for each scene object, but rather uses scene blocks as the basic processing unit, iteratively merging and simplifying the sets of objects contained within them according to the viewing hierarchy from near to far, thereby constructing a model representation with hierarchical detail.

[0031] Specifically, model generation strictly follows the order from nearest to farthest in the distance hierarchy sequence. First, the distance hierarchy closest to the observation point, such as L0, is processed. For the L0 hierarchy, the generation of models in each scene block is relatively simple. Since L0 is the closest hierarchy and has no preceding distance hierarchy, the model generated for a scene block of L0 is directly based on the original models of scene objects that fall within the space of that block and belong to the L0 logical object set (i.e., L0-specific). In one implementation, these original models can be directly used as the L0 model, or they can be lightly optimized while maintaining high detail. Regardless of the processing method, the final result is the initial model corresponding to each scene block of the L0 hierarchy.

[0032] After generating the model for the nearest distance level L0, the iterative phase begins, generating models for each scene block of the next, more distant distance level, such as L1. According to the definition of this step, generating a model for any target scene block of L1 requires combining two parts of input. The first part is the original model of the scene objects unique to this target scene block itself, i.e., those scene objects that were assigned to the L1 level in step S3100 and fall within the spatial range of this L1 block in step S3200. These objects are new content that becomes theoretically visible for the first time at the L1 viewing distance. The second part is the models generated by all preceding distance levels (L0 in this example) that spatially overlap with this L1 target scene block. This means that it is necessary to collect the models corresponding to all L0 scene blocks that cover all or part of the area of ​​this L1 scene block in three-dimensional space.

[0033] The two input components—the original models of new objects specific to L1 and the spatially overlapping set of L0 models—are logically or data-wise integrated to form a unified geometric dataset to be processed. Next, a degeneracy operation is performed on this dataset. In this application, degeneracy specifically refers to a series of automated processes aimed at reducing model data volume and visual complexity. Typical implementations include, but are not limited to: merging multiple independent model meshes into a single mesh; applying preset mesh simplification algorithms, such as edge folding and vertex clustering, to reduce the number of triangles; downsampling or merging textures; and simplifying material and shader complexity. By performing a degeneracy operation that meets the accuracy requirements of L1 viewing distance, a new, unified simplified model is finally generated for the L1 target scene blocks. This model contains the specific simplified models of scene objects in scene blocks that spatially overlap in terms of preceding distance levels. The scene block model can visually represent both the model of the newly added L1 scene object and the merged, simplified model of all L0 scene objects in that region.

[0034] The above process continues, generating models for each further step (e.g., L2) along the distance sequence. In each iteration, the original model of the objects specific to the current step is merged and simplified with the models of all spatially overlapping, closer steps (already generated). Ultimately, the scene block model generated for the furthest step (e.g., L2) is an extremely simplified representation of a massive number of objects within a very large area of ​​the entire scene map. It may consist of only a few extremely simplified geometric shapes, but it is sufficient to outline the macroscopic contours of the scene from a great distance.

[0035] By employing an iterative simplification approach based on scene blocks and progressing from near to far, this application automatically constructs a hierarchical system of detail models. Each model in the system is strictly bound to a specific distance tier and scene block. More importantly, this process naturally establishes spatial and detail inclusion relationships between models at different levels. That is, simplified models at greater distances are, in visual terms, further generalizations and simplifications of models at closer distances. This provides a crucial data foundation for achieving smooth, visually flawless switching of detail levels and streaming rendering scheduling during game runtime.

[0036] Step S3400: Construct a scene resource package for the game program running on the client to call. The scene resource package contains a detailed model mapping table for recording the mapping relationship between each scene object in the scene plot and the model used in the corresponding scene block at each distance level.

[0037] After completing the logical layering and spatial segmentation of scene objects across the entire scene map, and generating multi-level detail models for each segment, all data assets and metadata produced in the preceding steps can be systematically collected, integrated, serialized, and encapsulated to generate a complete, independent data unit that can be directly loaded and used by the game client at runtime—the scene resource package. This resource package file is the final product of the automated preprocessing pipeline, containing all optimized rendering resources and fine-grained scheduling metadata.

[0038] Specifically, for the processed scene map, the preprocessing outputs that need to be collected and packaged mainly include the following types of data. The first type is rendering asset data such as models and textures, that is, simplified model files generated by step S3300 for each scene block of each distance level, as well as texture maps, material definitions, etc. associated with these models. These files are the underlying resources that the client relies on for the final rendering of the screen.

[0039] The second category is structured metadata used to describe and manage the aforementioned rendering assets. This metadata ensures that the client can understand the complex logical relationships within the resource package and perform efficient scheduling. Metadata includes, but is not limited to: the identifiers and upper limits of each distance tier defined for the scene map, the tier division specifications used for each distance tier, the spatial extent definitions of all scene blocks divided according to these specifications (e.g., their center coordinates and dimensions), and the (default) streaming distance set for each scene block to support fine-grained streaming loading. Among these, the detail model mapping table is a key component of the metadata, recording the mapping relationships established during the iterative simplification process in step S3300: that is, for each scene object within the scene map, at each distance tier, its visual content is merged into which (or which) scene block's simplified model. This mapping table allows the runtime to quickly trace the specific rendering model corresponding to any scene object at different viewing precision levels.

[0040] After collecting all the aforementioned asset data and metadata, the resource package can be constructed. A common implementation method is serialization and packaging. First, all the descriptive metadata (including distance hierarchy definitions, scene chunk definitions, detail model mapping tables, etc.) is converted into a structured, machine-readable data format, such as JSON, XML, or a custom binary format, thereby generating one or more metadata files. Meanwhile, all model files, texture files, and other assets retain their original formats. Next, these serialized metadata files and all asset files are placed together in a logical directory or directly packaged. In one embodiment, a common archiving and compression format (such as ZIP) or a game engine-customized resource package format can be used to package and compress all files into a single scene resource package file that is easy to distribute and version-manage. In another embodiment that focuses on dynamic loading, metadata and model assets can be packaged into multiple dependent sub-packages.

[0041] The final generated and output scene resource package file has a specially designed internal structure to support efficient parsing and on-demand invocation by the client. After loading this resource package at runtime, the client can parse its metadata to reconstruct the hierarchical spatial management structure of the scene map. The detailed model mapping table will serve as the query basis, enabling the client to accurately match the scene tile model corresponding to the current viewing distance for each scene object during rendering. At the same time, metadata such as the default streaming distance associated with each scene tile provides direct and reliable data support for the client to make fine-grained streaming loading decisions based on spatial distance.

[0042] This completes the fully automated preprocessing workflow described in this application, transforming a raw, unorganized scene map into a standardized scene resource package containing multi-level optimized detail models, precise spatial indexes and scene object-model mapping relationships, and pre-configured streaming scheduling parameters. This data product provides a solid data foundation for achieving high-performance, high-fidelity, and smooth, seamless large-scale scene rendering at runtime.

[0043] As can be seen from the above embodiments, this application obtains the visible distance of each scene object in the scene map, and automatically divides the scene objects into different distance tiers to form logical object sets for each tier. Then, according to the tier segmentation specifications, the logical object sets are spatially divided into fine scene blocks. Following the order of increasing distance, using scene blocks as processing units, the original object model unique to this block is iteratively simplified with all preceding tier block models that overlap in space. A corresponding simplified model is generated for each scene block of each distance tier, and a detailed model mapping table is constructed to record the mapping relationship between objects and their final assigned block models. Finally, these structured block models, mapping tables, and related metadata are encapsulated into a scene resource package. Therefore, this application achieves several significant beneficial effects, including but not limited to: First, the automated preprocessing workflow implemented in this application significantly reduces reliance on human experience and improves the standardization and maintainability of large-scale game content production. In traditional technologies, arduous tasks such as scene segmentation, multi-level detailed model generation, and streaming distance setting are highly dependent on manual labor. This application transforms all processes—including visible distance calculation, distance tier division, tier segmentation specification application, scene segmentation generation, iterative degeneracy, and mapping table construction—into an automated workflow based on preset rules. This enables the batch and standardized processing of massive scene objects, generating data with high global consistency and scientific rigor, greatly liberating productivity, reducing the risk of human error, and making the construction, iteration, and performance optimization of ultra-large-scale open worlds efficient, predictable, and sustainable.

[0044] Secondly, this application achieves a fundamental leap from coarse-grained scene map management to fine-grained scene block management, resolving the contradiction between traditional resource packaging and scheduling requirements. Through distance-level logical layering and tiered segmentation spatial partitioning, this application automatically constructs a multi-layered, fine-grained spatial management grid—the scene block—during the preprocessing stage. This enables the runtime streaming loading system to use scene blocks as the smallest decision unit, setting independent and precise loading trigger conditions for groups of objects with different visual attributes, such as distant and near objects, completely eliminating the dilemma of setting a single compromise threshold for the entire area. As a result, resource loading timing perfectly matches the visual distance of objects; distant objects are loaded in a timely manner to avoid visual gaps, while a large number of near objects are prevented from being loaded prematurely, thus optimizing memory usage from the source, significantly reducing redundant I / O transmission, and laying a solid foundation for smooth and stable game operation.

[0045] Furthermore, this application automatically constructs a hierarchical detailed model system through iterative simplification based on scene blocks, and solidifies the relationship between objects and models through a detailed model mapping table, ensuring visual continuity while maintaining rendering efficiency. The models generated by this process naturally possess hierarchical inclusion and simplification relationships. Combined with the detailed model mapping table, the runtime can quickly determine the specific scene block model corresponding to any scene object at any viewing level. This allows the game system to intelligently switch between the original model of the scene object and the block aggregation model at different simplification levels based on the loading status of the scene blocks or the viewing distance, ensuring that rendering is performed with the most appropriate visual precision at any distance. This effectively eliminates visual pop-ups, flickering, or object loss caused by improper model switching, achieving a perfect balance between image quality, rendering performance, and streaming loading scheduling.

[0046] Based on any embodiment of the method in this application, before determining the target distance tier and corresponding logical object set in the distance tier sequence to which each scene object belongs, according to the visible distance of each scene object in the scene map, the method includes: Step S3110: Traverse the visually visible elements in the scene map and determine the spatial dependencies of each visually visible element; In the data structures of many game engines, a complex object that appears as a single, unified whole—such as a tree model composed of a trunk, branches, and leaves, or a vehicle composed of a body, tires, and windows—may internally consist of multiple independent, visually visible elements with hierarchical or logical relationships. Directly using these finest-grained elements as units for calculating visible distance and performing streaming scheduling would result in overly fragmented management and could lead to visual judgment errors due to the separate calculation of parent and child elements. This embodiment aims to address this problem by combining multiple elements with close spatial relationships into a single logical scene object for processing.

[0047] Specifically, the process begins by traversing all basic visually visible elements within the current scene map. Visually visible elements are the smallest rendering units that constitute the visible content of the game world, typically corresponding to a renderable mesh, particle system, or bulletin board. During traversal, the spatial dependencies between these elements are analyzed. Spatial dependencies describe the close integration of a group of visually visible elements in terms of spatial structure, motion logic, or function, and should generally be considered as an indivisible visual whole. One type of dependency is a parent-child hierarchy, where multiple child components (such as multiple static meshes) are attached to a single game object (e.g., a parent Actor). In this case, the parent object has a clear spatial dependency on all child objects because the position, rotation, and scaling of the child objects are typically defined relative to the parent object. Another type of spatial dependency can be determined through predefined grouping labels or physical constraints (e.g., hinges, welds). In one embodiment, parent-child dependencies can be automatically identified by parsing the node hierarchy tree of the scene editor. In another embodiment, artists or tools can assign the same grouping label to multiple elements that logically belong to the same object, and the preprocessing tool identifies the dependency by reading this label.

[0048] Step S3120: Pack visually visible elements with spatial dependencies into scene objects corresponding to the same group, and treat visually visible elements without spatial dependencies as independent scene objects. Once spatial dependencies are determined, a packing operation can be performed to logically combine a group of spatially dependent visually visible elements and define them as a new, uniformly managed scene object. This newly defined scene object will have a unique identifier and be associated with references to all visually visible elements it contains. The packing operation does not change the geometric data of the original elements, but rather establishes a higher-level management structure. Meanwhile, for those independent visually visible elements identified during traversal as having no spatial dependencies (e.g., an isolated stone, a single street lamp model), each such element is directly defined as an independent scene object. Through this step, no matter how complex the original data structure is, it is normalized into a set of discrete, logically independent scene objects, each representing a visually unified entity.

[0049] Step S3130: Determine the visible distance of each scene object and store the visible distance as the metadata of the scene object, wherein the visible distance is the maximum value among the visible distances of each visually visible element within the scene object.

[0050] Finally, the visible distance is calculated for each newly defined (or identified) scene object. This calculation can be performed based on all visually visible elements contained within the scene object. To do this, the visible distance of each visually visible element within the scene object is obtained, calculated using a predefined geometric trigonometric formula based on the element's bounding box size, screen space occupancy, and the field of view of a standard virtual camera. Then, the maximum visible distance of all these elements is taken as the final visible distance of the scene object. Using the maximum value is conservative and reasonable; it ensures that if any part of the scene object becomes visible at a certain distance, the entire object (as a logical whole) should be considered visible at that distance, thus triggering the loading of the entire object and avoiding inconsistencies such as partial loading and partial missing objects. The calculated visible distance becomes a key attribute of the scene object, stored as attribute data in the scene object's metadata, and used for subsequent processing such as dividing distance tiers and generating detailed models.

[0051] The above embodiments automatically identify and logically package visual elements that are closely related in space and function. They extract atomic units from the original, complex engine data structure that conform to human visual perception and game logic, suitable for streaming scheduling management. This ensures that all subsequent automated calculations based on scene objects are performed at the correct and meaningful granularity, avoiding decision-making biases caused by problems with the data source's own structure. Simultaneously, by taking the maximum visible distance of the internal elements of a composite object, adhering to conservative and reliable design principles, the visual integrity of streaming loading is guaranteed from the source. This lays a solid and accurate data foundation for the subsequent implementation of refined, error-free adaptive rendering scheduling in this application.

[0052] Based on any embodiment of the method in this application, determining the visible distance of each scene object includes: Step S3131: Obtain the bounding box size of each visually visible element contained in the scene object in the game world; The visible distance of scene objects can be determined automatically. This automatic calculation begins with each visually visible element contained within the scene object. For each visually visible element, its bounding box size in the game world coordinate system needs to be obtained. A bounding box is an axially aligned cube that completely encloses all vertices of the element; its dimensions are typically expressed as width, height, and depth. One implementation of obtaining this size is to directly query the bounding box data of the visually visible element's rendering mesh from the game engine. In another implementation requiring higher precision, its precise bounding box can be recalculated. The obtained size is typically taken as the representative size of the element in the calculation, using its maximum axial dimension (i.e., the maximum value among width, height, and depth).

[0053] Step S3132: Substitute the size of the bounding box, the preset minimum screen space ratio, and the field of view of the standard virtual camera into the preset geometric projection formula to calculate the visible distance of each visually visible element. After obtaining the bounding box dimensions, they are combined with a preset minimum screen space ratio and the field of view of a standard virtual camera, and then substituted into a preset geometric projection formula for calculation. The preset minimum screen space ratio parameter can be defined in several ways. In one embodiment, it can be a predefined minimum screen space area ratio threshold (e.g., 0.5%) that indicates the percentage of pixel area occupied by the projected area of ​​a visually visible element on the screen cannot be lower than this value. In this case, the area ratio threshold usually needs to be converted to a linear size ratio before being substituted into the formula. In another embodiment, the preset parameter can be directly defined as a linear screen ratio threshold used for formula calculation. The standard virtual camera is a reference camera set up for calculation, typically using the default perspective projection settings commonly used in games, and its field of view is a known fixed value.

[0054] Please refer to Figure 5 A mathematical relationship between object size, minimum screen space ratio, field of view, and visible distance is established through a preset geometric projection formula. Based on the principle of similar triangles, the formula can be expressed as: Visible distance D = (Representative size of the visually visible element) / (2 * k * tan(Standard field of view / 2)). Here, k is the linear screen-to-body ratio threshold used for calculation. When the preset parameter is the area ratio P, k can be taken as sqrt(P), which is a common approximation from area to linearity. When the preset parameter itself is a linear threshold, k can be used directly. The representative size of a visually visible element usually refers to the projected size of its bounding box in the viewing direction. To simplify calculations, in one embodiment, the maximum axial dimension of its axially aligned bounding box (AABB) can be directly used as a conservative estimate. In another embodiment with higher accuracy requirements, the projected size of its oriented bounding box (OBB) in the standard viewing direction can be calculated to more accurately reflect its visual size.

[0055] The visible distance D calculated using the above formula is the theoretical furthest viewing distance when the linear proportion of the visually visible element on the screen is exactly not less than the threshold, under the current standard camera settings and a given linear screen-to-body ratio threshold k. In one embodiment, this calculation can be performed in batches to improve preprocessing efficiency. In another performance-considered embodiment, for the same model that is used frequently, its visible distance can be calculated only once and the result cached to avoid duplicate calculations.

[0056] Step S3133: Determine the maximum value among the visible distances of all visually visible elements of the scene object as the visible distance of the scene object.

[0057] After calculating the independent visible distance for each visually visible element, these values ​​need to be combined to determine the visible distance of its corresponding scene object. As previously disclosed, a scene object may be composed of multiple visually visible elements. The rule adopted in this embodiment is to take the maximum visible distance among all the visually visible elements contained in the scene object as the final visible distance of the scene object. This rule is conservative and logical. It means that as long as any component (element) of the scene object becomes theoretically visible at a certain distance, the entire logical object should be considered potentially visible at that distance, thereby triggering subsequent operations such as loading. This ensures the integrity of the visual presentation of the scene object as a whole. For example, a tree as a scene object is composed of multiple elements such as the trunk and crown. The crown may be calculated as visible from a greater distance due to its larger bounding box. Therefore, the visible distance of the entire tree should be determined by the maximum visible distance of the crown to ensure that the resources of the entire tree (including the trunk) are ready when the player sees the outline of the crown.

[0058] The above embodiments, utilizing standardized formulas based on geometric projection principles, correlate the physical dimensions of visually visible elements, the desired screen display threshold, and camera parameters to automatically and accurately calculate the theoretical visible limit distance for each visually visible element and even each scene object. This method completely eliminates the reliance on subjective estimations by artists or planners in traditional approaches, eliminating human error and ensuring the scientific validity and consistency of the visible distance parameters for massive amounts of scene objects across the entire system. This not only greatly improves the efficiency and reliability of large-scale world map construction but, more importantly, provides solid and reliable input data for all subsequent automated processing, including distance hierarchy division, spatial segmentation, and streaming distance settings. This allows the entire vision-based rendering control system to be built on an objective and quantitative computational foundation, fundamentally guaranteeing the overall effectiveness of the solution and the predictability of its optimization effects.

[0059] Based on any embodiment of the method in this application, according to the visible distance of each scene object in the scene map, the target distance tier and the corresponding logical object set in the distance tier sequence to which each scene object belongs are determined, including: Step S3140: Obtain multiple pre-defined distance levels, wherein each distance level is associated with a distance upper limit that is relatively defined with reference to the scene object; Multiple distance levels can be set using a predefined logical hierarchy system, serving as configuration parameters or design constants for the preprocessing workflow. The purpose of setting distance levels is to divide the continuous observable distance space into several discrete logical intervals, enabling logical classification of scene objects at different observation distances and providing a basis for subsequent spatial organization and model processing.

[0060] Each distance tier is associated with a key parameter: the distance upper limit. The distance upper limit is not an absolute spatial coordinate or geographical range, but rather a relative definition with reference to the scene object. This means that the distance upper limit represents a theoretical radius measured outward from a spatial reference point of the target scene object itself (e.g., its geometric center, bounding box center, or a pre-defined representative location). In one embodiment, this reference point is the same point used when calculating the visible distance of the scene object, ensuring a consistent measurement benchmark for subsequent segmentation comparisons. For example, referencing... Figure 5 As shown, the upper limit of a distance tier is defined as 500 meters. Technically, this means a spherical spatial boundary with a radius of 500 meters, centered on the reference point of any scene object. This distance tier governs scene objects whose theoretical visible range (i.e., visible distance) does not exceed this radius.

[0061] There are several ways to obtain these pre-defined distance levels and their upper distance limits. In one embodiment, the developer or tool directly defines a set of distance levels ordered from near to far (or from far to near) according to the observation distance in a preprocessing configuration file, and explicitly specifies the upper distance limit value for each level. For example, it can be done as follows: Figure 5 The diagram defines a sequence containing three distance levels: L0, L1, and L2, with upper limits of 100 meters, 500 meters, and 2000 meters, respectively. In another embodiment, the number of distance levels and the upper limit of each level can be automatically derived using algorithms or rules, such as calculations based on the overall size of the scene map, the average size of scene objects, or the target rendering performance budget. The result is also a set of pre-determined parameters that can be used in subsequent steps.

[0062] Step S3150: Compare the visible distance of each scene object with the upper limit of each distance tier in turn, and divide the scene object into the distance tier to which its visible distance falls. The distance tier to which it falls is the first distance tier among the plurality of distance tiers that satisfies that its upper limit is greater than or equal to the visible distance of the scene object. After setting multiple distance tiers with explicit upper limits and determining the visible distance of each scene object within the scene map, these two datasets can be linked together. An objective and repeatable partitioning algorithm can then precisely assign each scene object to its logically belonging single distance tier. Specifically, this can be accomplished by systematically comparing each scene object's own visible distance value with the preset distance tier system.

[0063] Specifically, for the current scene map to be processed, each scene object within it is traversed. For any given scene object, its calculated visible distance is compared sequentially with predefined distance tiers, typically sorted by their maximum distance values ​​from smallest to largest. The goal of the comparison is to find a matching distance tier, determined by the criterion that the maximum distance value of that tier is exactly greater than or equal to the visible distance of the scene object. In one embodiment, this matching process uses a sequential search algorithm. Starting with the distance tier with the smallest maximum distance value (i.e., corresponding to the closest observation distance), the visible distance of the scene object is compared sequentially with the maximum distance value of the currently traversed distance tier. When the first distance tier whose maximum distance value is greater than or equal to the visible distance of the scene object is encountered, the comparison process terminates, and the scene object is assigned to that specific distance tier. This finally determined distance tier is called the distance tier to which the visible distance of the scene object falls.

[0064] Here, "falling into" means that the visible distance of a scene object is less than or equal to the upper limit of this distance level, and simultaneously greater than the upper limit of the preceding (closest) distance level (if it exists). For example, continuing the example mentioned earlier, suppose three distance levels L0, L1, and L2 are predefined, with upper limits of 100 meters, 500 meters, and 2000 meters, respectively. For a scene object with a visible distance of 350 meters, its visible distance is compared with the upper limits of each level in turn. First, it is compared with the upper limit of L0, 100 meters. Since 350 meters is greater than 100 meters, the condition is not met, so it does not belong to L0. Next, it is compared with the upper limit of L1, 500 meters. Since 350 meters is less than or equal to 500 meters, the condition is met for the first time, so the scene object is classified into distance level L1. Similarly, for a scene object with a visible distance of 80 meters, since it is less than or equal to the upper limit of L0 (100 meters), the condition is met during the first comparison, so it is classified into distance class L0. However, for a scene object with a visible distance of 1500 meters, it is greater than the upper limit of L1 (500 meters) but does not meet the conditions of L0 and L1. The condition is only met when compared with the upper limit of L2 (2000 meters), so it falls into distance class L2.

[0065] Step S3160: According to the distance tier to which the scene object belongs, add each scene object in the scene map to the logical object set corresponding to the distance tier to which the scene object belongs.

[0066] After dividing each scene object and determining its corresponding distance tier, a crucial logical organization operation is required: constructing a set of logical objects for each distance tier. This step serves as a bridge between the logical division and subsequent physical processing, i.e., spatial partitioning.

[0067] Specifically, a corresponding logical object set is pre-maintained for each defined distance tier, and this set is initially empty. Next, all scene objects within the scene map are traversed again. For each scene object, its unique identifier (or reference) is added to the logical object set corresponding to that distance tier, based on its assigned distance tier identifier determined in step S3150. Essentially, this process regroups and indexes the scattered scene objects according to their visual attributes (visible distance).

[0068] After this step, the massive number of scene objects that originally existed individually are systematically organized into several discrete logical sets. Each logical object set, such as the L1 logical object set, contains all scene objects whose visible distance falls within the L1 range (i.e., greater than 100 meters and less than or equal to 500 meters). These logical object sets clearly define the object range to be managed by each distance tier, providing a clear and homogeneous set of input objects for the next step (S3200) to divide the space according to the tier segmentation specifications.

[0069] The above embodiments, based on an automated segmentation mechanism using objective distance comparison, scientifically and accurately categorize scene objects into preset structured levels, i.e., distance tiers, according to their inherent visual attributes and visible distances, and construct logical object sets for each tier. This lays the data foundation for all subsequent refined processing and scheduling in this application. By using explicit and repeatable algorithmic rules, it replaces the subjective and coarse classification relying on manual experience or simple spatial division in traditional methods, ensuring a high degree of consistency and objectivity in the classification standards of massive scene objects across the entire scope. This provides a reliable and homogeneous set of logical inputs for subsequent refined processing steps such as spatial segmentation and model degeneracy, realizing a fundamental shift from general processing of the entire scene map to refined and hierarchical scheduling based on visual attributes and spatial locations.

[0070] Based on any embodiment of the method in this application, a model of the scene object in its scene block is generated for each distance level in the distance ladder sequence, from near to far, including: Step S3210: For the first distance step in the distance step sequence that is closest to the first distance step, determine the original model contained in each scene block as the model of the first distance step. This step is the starting point of the hierarchical model generation process. The object processed is the distance level closest to the observation point, which can be called the first distance level, such as L0. After completing step S3200, the distance level (L0) has been spatially divided into multiple scene blocks according to its level segmentation specifications, and the original models of scene objects belonging to the L0 logical object set that fall within its spatial range have been associated with each scene block.

[0071] For this first distance level, since there are no closer distance levels, the model generation process is the most straightforward. A common and efficient implementation is to avoid performing complex geometric merging and simplification operations on the original models within each L0 scene block. This is because L0 represents the closest viewing distance and needs to present the highest visual detail. Therefore, this step involves directly determining the original model (i.e., the independent high-precision model without merging and simplification) of the scene objects contained within each L0 scene block as the model corresponding to that scene block at the L0 distance level.

[0072] This means that when generating a model for the L0 level, a direct association is being established between the scene chunk and its internal list of primitive object models. Each L0 scene chunk has its own set of models of its internal primitive objects. In subsequent steps, this set of models will serve as one of the input components when generating simplified models for more distant levels (such as L1). In this way, the need for high accuracy at the closest distance is met, while structured input data is prepared for iterative processing across levels.

[0073] Step S3220: For the next more distant distance step in the distance step sequence, the original model of the scene object unique to each scene block in the distance step is geometrically merged and simplified with the model generated for the previous distance step that overlaps with the scene block in space, to generate the model of the current distance step. After determining the model for the first distance level (L0), the iterative phase begins, starting the generation of models for the next, more distant distance level (e.g., L1). This step defines the core rules for generating scene chunk models for any further distance level, and these rules form the basis for iterative execution.

[0074] Specifically, for the longer-distance thresholds being processed (e.g., L1), model generation is performed independently for each scene block within L1. For a specific target scene block in L1, model generation requires combining two input components: The first is the original model of objects specific to this ladder level: that is, the original models of scene objects that were assigned to the L1 ladder level in step S3100 and fall within the specific L1 scene block space range in step S3200. These are new contents that become theoretically visible for the first time at the L1 viewing distance.

[0075] Secondly, there's the spatially overlapping preceding tier model: Due to the greater viewing distance, the region represented by the current L1 block is typically covered by multiple smaller L0 scene blocks at the closer L0 tier. Therefore, it's necessary to collect models corresponding to all L0 scene blocks that spatially overlap with the current L1 target block. These models represent potentially high-precision visual representations of all objects in the region at closer distances.

[0076] The two inputs—the original model set unique to the current L1 block and the model set of all spatially overlapping L0 blocks—are logically integrated into a single dataset to be processed. Then, a geometric merging and simplification algorithm is performed on this integrated dataset. This operation significantly optimizes the model based on the lower visual detail requirements corresponding to the current L1 distance gradient compared to L0. The merging operation merges multiple independent model meshes into a single mesh; simplification operations, such as edge collapsing and vertex clustering, significantly reduce the number of triangles in the mesh. Additionally, texture downsampling can be applied. Finally, a new, single, and highly simplified aggregated model is generated for this L1 target scene block. This model visually integrates the simplified forms of newly added L1 objects and all L0 objects within the region.

[0077] Step S3230: Iteratively execute the above operations for the next more distant distance step in order of increasing distance, and generate a model for each distance step.

[0078] The processing logic defined in step S3220 constitutes an iterable template. After generating models for all scene blocks in the L1 level, the process will continue to serve the next more distant level (e.g., L2).

[0079] For the L2 level, the same operations are iteratively performed for each scene block: First, determine the original model of the L2-specific scene object falling within the L2 block. Second, find the (simplified) models generated by all L1 scene blocks that spatially overlap with the L2 block. Then, merge and simplify these two parts (the L2-specific original model + the overlapping L1 simplified models) to generate the final, further simplified aggregate model of the L2 block based on the lower detail requirements of the L2 level.

[0080] This iterative process continues, strictly following the order of distance from nearest to farthest, generating models for all scene blocks corresponding to each distance tier (L0, L1, L2, ...). Each iteration adds new objects specific to the distance tier, fusing and further simplifying them with the already generated simplified models representing the visual content of all closer areas. Ultimately, the model generated for the farthest distance tier (e.g., L2) is the ultimate simplified representation of a massive number of objects within a very large geographic region; the data volume is extremely small, but sufficient to delineate the macroscopic terrain from a great distance.

[0081] The above embodiments automatically construct a hierarchical, spatially aligned pyramid of detail models by using scene blocks as processing units and following an iterative degeneracy process from near to far. Higher-level (far-range) models completely encompass the areas represented by lower-level (near-range) models in terms of content, but are presented with coarser precision. This data structure naturally supports efficient and smooth switching of detail levels and spatially based streaming rendering scheduling during game runtime, which is a key technological guarantee for achieving high-performance, high-visual-quality large-scale scene rendering in this application.

[0082] Based on any embodiment of the method in this application, before constructing a scene resource package for the game program running on the client to call, the method includes: Step S4100: Set a default streaming distance for each scene block of each distance tier, the default streaming distance being set based on the maximum visible distance among the scene objects contained in the scene block; For each scene chunk generated in the preprocessing flow, a key scheduling threshold, namely the default streaming distance, can be pre-calculated and set. This distance will become the benchmark for the game runtime to determine when resources within that scene chunk need to be loaded.

[0083] The logic for determining the default streaming distance is closely related to the visual content of the scene chunk. Specifically, for a scene chunk currently being processed (e.g., a scene chunk belonging to distance level L1), it is first necessary to determine all scene objects managed by that scene chunk. These objects are those scene objects that were associated with that chunk based on spatial inclusion relationships in step S3200 and belong to the logical object set of their respective distance levels. Next, the visible distance values ​​of these scene objects are read. Then, a predefined, conservative rule is applied to determine the default streaming distance of that scene chunk: the maximum value is selected from the visible distances of all scene objects contained in that scene chunk, and this maximum value is set as the default streaming distance of that scene chunk.

[0084] For example, continuing with the previous scenario, suppose a scene block belonging to distance level L2 contains three scene objects with visible distances of 1500 meters, 1800 meters, and 2000 meters respectively. Then, the default streaming distance for this scene block would be set to 2000 meters. The rationale behind this rule is that it ensures the default streaming distance is greater than or equal to the distance theoretically required for any object within the block to become visible. This means that before the virtual camera gets close enough for any object within the block (even the one with the furthest visible distance) to enter the field of view, the entire block has already (or at least has a chance to) be loaded, thus fundamentally avoiding the problem of sudden visual gaps in objects within the block due to resource loading delays.

[0085] Step S4200: The default streaming distance is stored as metadata associated with the corresponding scene block. The default streaming distance is used by the game client to define the effective streaming distance for triggering the loading of the object aggregation layer during game runtime.

[0086] After successfully calculating the default streaming distance for each scene chunk, this information must be persisted so that subsequent game runtime processes can read and use it. Therefore, this step stores the calculated default streaming distance as key metadata, strongly associated with the scene chunk that generated it.

[0087] Associative storage can be implemented through various technical means. In one embodiment, a dedicated field can be added to the metadata structure describing the scene chunk (e.g., a descriptor containing fields such as its spatial extent, distance tier, and model reference) to store the value of its default streaming distance. In another embodiment focusing on data separation management, a separate metadata mapping table can be created, where each record contains a unique identifier for the scene chunk and its corresponding default streaming distance, allowing for association queries through the identifier. Regardless of the storage method used, the goal is to ensure that when the scene resource package is finally constructed, these preset default streaming distances can be packaged and serialized together with other metadata such as the scene chunk definition, model reference, and detailed model mapping table to form a complete data package.

[0088] The default streaming distance stored within the scene resource package serves as a reliable and configurable baseline parameter for the game client's streaming loading decisions during runtime. After loading and parsing the scene resource package, the client reads the preset default streaming distance for each scene chunk. It's important to note that this default streaming distance is a theoretical value calculated during the preprocessing stage based on ideal visual conditions. In actual operation, the client can adjust a global scaling factor based on real-time device performance, network bandwidth, player image quality settings, or specific game modes. When a loading decision is needed, the client multiplies the default streaming distance of a scene chunk by this global scaling factor to calculate an effective streaming distance for comparison. This effective streaming distance serves as the final loading trigger threshold, compared with the spatial distance from the virtual camera to that scene chunk, to determine whether to load that chunk and its associated resources.

[0089] The above embodiments scientifically preset a default streaming distance for each scene block during the preprocessing stage and solidify it as key metadata in the resource package, constituting a further technical advantage of this application in solving resource scheduling optimization problems. It integrates the complex and error-prone threshold setting work in traditional runtime loading decisions into the preprocessing flow in a pre-processing manner. By automatically calculating the default streaming distance based on the visible distance of objects within the scene block, it ensures the inherent consistency between loading triggering conditions and the visual attributes and spatial organization of objects, guaranteeing the timeliness and rationality of loading from the data source. Simultaneously, the preset default streaming distance provides a unified and adjustable benchmark for runtime, enabling the client to flexibly and efficiently calculate the effective streaming distance adapting to real-time environmental changes based on this benchmark. This achieves more refined and adaptive control of memory and I / O load while ensuring visual continuity, significantly enhancing the robustness, configurability, and overall performance of the entire streaming loading system.

[0090] Based on any embodiment of the method in this application, a scene resource package is constructed for the game program running on the client to call, including: Step S3410: For the scene map, serialize the identifiers and segmentation specifications of each distance level, the spatial range definition of each scene block and the associated default streaming distance, and the detail model mapping table into structured description data. After completing all preprocessing steps such as scene segmentation, model generation, and parameter setting, this step systematically organizes and converts all the key metadata generated by these processes that describes and manages the entire scene map. This metadata is discrete, existing in various in-memory data structures or intermediate files, but it collectively defines the scene's hierarchical structure, spatial organization, resource associations, and scheduling strategies. This step aims to convert it into one or more unified, compact, machine-readable serialization formats for efficient storage, network transmission, and accurate reconstruction at client runtime.

[0091] Specifically, for the processed scene map, the core metadata categories that need to be collected and serialized include, but are not limited to, the following: The first is the distance tier definition data: this includes the identifiers of all distance tiers defined for the scene map (e.g., L0, L1, L2), the upper limit of the relative distance associated with each distance tier with reference to scene objects (e.g., 100 meters, 500 meters, 2000 meters), and the tier division specification. The tier division specification defines the grid size used for spatial division under that distance tier, and is the basis for understanding the spatial range of scene blocks at each tier.

[0092] Secondly, there is the scene tile definition data: this belongs to the organizational unit metadata. It covers the definitions of all scene tiles generated for the scene map. For each scene tile, its definition data typically includes: a unique identifier for the scene tile, the distance tier identifier to which it belongs, a spatial extent definition used to precisely locate its space (e.g., the 3D coordinates and dimensions of its center point, or the minimum and maximum vertex coordinates of an axis-aligned bounding box), and the default streaming distance set for that scene tile. Additionally, it may include references to simplified model resources generated for that scene tile.

[0093] Thirdly, there is the detailed model mapping table: This table records the mapping relationship between each scene object within the scene map and the scene block identifier (or the model corresponding to that block) to which it ultimately belongs at each distance level. It doesn't directly record a reference from an object to an abstract model, but rather records which specific scene block's simplified model the scene object's visual content has been merged into after iterative simplification. This is the basis for quickly finding the corresponding rendering model for an object at runtime.

[0094] Serialization is the process of converting the aforementioned metadata with complex relationships into a linear byte stream or a structured text format. In one embodiment, all this data can be integrated into a unified description file. For example, a JSON file can be created, with its root node containing descriptions of distance tier arrays, scene chunk arrays, and detail model mapping objects. In the distance tier array, each element is an object containing id, distanceUpperLimit, and cellSize (tier segmentation specification) fields. In the scene chunk array, each element is also an object, containing its own id, levelId, bounds object of the description space, defaultStreamingDistance, and modelRef (model reference) fields. The detail model mapping table can be represented as an object whose key is the scene object identifier and its value is another object whose key is the distance tier identifier and its value is the scene chunk identifier that the object maps to at that tier. In another embodiment that prioritizes performance and storage space, serialization can be performed using a custom binary format such as Protocol Buffers or MessagePack, which organizes information through a predefined, compact data block structure.

[0095] Step S3420: Compress and package the structured description data and the model data generated for each scene block; After successfully generating structured description data files containing all metadata, these descriptive blueprints need to be physically integrated and encapsulated with the actual rendering assets produced by the preprocessing workflow. These actual assets mainly refer to the simplified model files generated for each scene block in step S3300, as well as the resource files such as texture maps, material definitions, and shaders associated with these models.

[0096] A common implementation is directory packaging. First, a logically clear temporary output directory is created. The serialized, structured description data file (e.g., named manifest.json or metadata.bin) is placed at the root of this directory or in a specific subdirectory. Simultaneously, all model files generated for scene chunks and their related resource files are also placed in appropriate locations according to a certain directory structure (e.g., organized by distance hierarchy or resource type). Next, compression and packaging operations are performed on the entire directory structure. In one embodiment, a common archiving and compression format (such as ZIP, TAR.GZ) can be used to package and compress the entire directory into a single, easily distributed, and version-managed archive file. In another embodiment optimized for game engines, a dedicated resource package format provided by the game engine or platform can be used directly for packaging, which may support advanced features such as streaming, block encryption, and incremental updates. The ultimate goal of packaging is to generate a logically self-contained data block containing all necessary data and metadata.

[0097] Step S3430: Generate and output a scene resource package file corresponding to the scene map, which can be loaded and parsed by the game client.

[0098] Finally, the single data block generated by the above packaging operation is officially output as a complete scene resource package file corresponding to the processed scene map. This file usually has a specific extension (such as .worldpak, .scene, etc.) to distinguish it from other files. After the file is generated, it can be stored in the output directory of the build server, committed to a version control system, uploaded to a content delivery network (CDN), or directly integrated into the game client's release package.

[0099] The generated scene resource package file is meticulously designed for efficient loading, parsing, and use by the game client at runtime. When needed, the client can load this resource package file via standard file I / O or network requests. After loading, the client first parses the structured descriptive data within, thereby reconstructing the metadata index of the entire scene map in memory: including the distance hierarchy, spatial definitions and scheduling parameters of all scene blocks, and detailed model mapping relationships. Simultaneously, the client can decompress, decode, and load the encapsulated model and texture resources associated with specific scene blocks within the resource package as needed, based on runtime requirements. Through the integrated detailed model mapping table within the resource package, the client can quickly determine the model to be rendered for any scene object within its field of view; through the preset default streaming distances for each scene block, the client can achieve precise, distance-based streaming loading decisions.

[0100] At this point, the complete automated preprocessing pipeline described in this application has reached its endpoint, transforming and encapsulating a raw, macroscopic scene map into a rigorously structured, standardized data product—the scene resource package—containing multi-layered optimized data and intelligent metadata. This data package ensures end-to-end optimization from automated content production to high-performance runtime consumption, providing a solid data delivery foundation for the smooth presentation of large-scale game scenes.

[0101] Based on any embodiment of the method in this application, before constructing a scene resource package for the game program running on the client to call, the method includes: Step S2100: Preset a streaming distance and an unloading distance for each scene block; wherein, the streaming distance is used to trigger loading of the scene block when the real-time viewing distance of the virtual camera to the scene block reaches the streaming distance during game operation; the unloading distance is used to trigger unloading of the scene block when the real-time viewing distance of the virtual camera to the scene block exceeds the unloading distance during game operation; and the settings of the streaming distance and the unloading distance satisfy the following relationship: for any scene block, its streaming distance is greater than the maximum visible distance among all scene objects contained in the scene block, and its unloading distance is greater than its streaming distance.

[0102] Before the final resource package is encapsulated, but after the scene chunks are constructed and models are generated, this embodiment adds an optimization step to the preprocessing flow, presetting two precise runtime behavior control parameters for each scene chunk: streaming distance and unloading distance. The purpose of setting these parameters is to define clear, unambiguous, spatial distance-based automatic triggering conditions for the complete runtime lifecycle (from loading to unloading) of each scene chunk during the preprocessing stage.

[0103] Specifically, streaming distance is a loading trigger threshold. Its function is defined as follows: During game runtime, the real-time spatial viewing distance from the virtual camera to the reference point (e.g., its center point) of the scene chunk is continuously monitored. When this distance is less than or equal to (i.e., "reaches") the preset streaming distance for that scene chunk, loading of that scene chunk and all its associated models, textures, and other resources is triggered. Conversely, unloading distance is an unloading trigger threshold. Its function is defined as follows: During game runtime, when the real-time viewing distance from the virtual camera to the scene chunk is greater than (i.e., "exceeds") the preset unloading distance for that scene chunk, unloading of the scene chunk is triggered, releasing the system memory and graphics memory resources it occupies.

[0104] This embodiment not only introduces these two parameters, but more importantly, it explicitly defines the numerical relationships that must be strictly observed between them and between them and the inherent visual attributes of scene blocks. These relationships contain two levels of inequality constraints, forming the core of scientific scheduling.

[0105] The first constraint is that for any scene chunk, its preset streaming distance must be greater than the maximum visible distance of all scene objects contained within that chunk. This constraint is a conservative and safe cornerstone. Since the maximum visible distance represents the farthest viewing distance from which any object within that chunk can theoretically become visible, setting the streaming distance to a value greater than this means that the entire chunk has already been (or at least has sufficient time) triggered to load before the virtual camera gets close enough for any object within the chunk (even the least visible one) to enter the field of view. This fundamentally eliminates the problem of objects "suddenly appearing" within the chunk or gaps in the visual image caused by resource loading delays, ensuring the integrity of the visual presentation.

[0106] The second constraint is that for the same scene chunk, its preset unloading distance must be greater than its own streaming distance. This constraint creates a crucial "load-unloading lag interval." This means that even if the virtual camera gradually moves away, causing the real-time viewing distance to exceed the streaming distance, the scene chunk will not be immediately unloaded as long as this distance has not exceeded a larger unloading distance. This design cleverly prevents scene chunks from being frequently loaded, unloaded, and reloaded when the camera moves slightly back and forth near the streaming distance threshold (e.g., the player lingers at the boundary). This effectively eliminates the performance jitter, I / O impact, and potential visual flicker (repeated model appearance and disappearance) caused by this, significantly improving the stability, smoothness, and resource scheduling efficiency of the game runtime.

[0107] It is particularly important to emphasize that all distances involved in this embodiment, including streaming distance, unloading distance, and the maximum visible distance used as a comparison benchmark, must be measured based on the same spatial reference point. Typically, this is consistent with the reference point used when calculating the visible distance of scene objects, with the scene object as the origin. For example, streaming distance and unloading distance are the distances from the virtual camera to the center point of the scene segment, while the maximum visible distance is the maximum value of the visible distances of all object reference points within that segment. Ensuring the uniformity of the measurement benchmark is a prerequisite for the aforementioned inequality constraints to produce accurate and expected technical effects.

[0108] This embodiment scientifically sets pairs of streaming and unloading distances with strict numerical relationships for each scene block during the preprocessing stage, and solidifies them as metadata, further enhancing the technical advantages of this application in solving the problem of refined management of resource lifecycle. It transforms the complex and error-prone dynamic threshold calculations of traditional runtime into static parameter configurations that are calculable, verifiable, and batch-processable during the preprocessing stage. These preset distance pairs, satisfying specific inequalities, provide a clear, stable, and reliable set of behavioral guidelines for the runtime streaming loading system. The rule that the streaming distance is greater than the maximum visible distance ensures timely loading from the data source, serving as the first line of defense against visual defects; while the rule that the unloading distance is greater than the streaming distance, by introducing a reasonable hysteresis buffer, greatly suppresses resource scheduling oscillations in critical states. The two work together to ensure that the streaming loading system achieves a better balance between response sensitivity, visual continuity, and operational stability, enabling large-scale game scenes to respond smoothly and without delay to player exploration while maintaining efficient and economical memory and I / O usage patterns, thereby greatly improving the overall experience quality and performance of the game.

[0109] Based on any embodiment of the method in this application, the scene resource package is configured to allow the game client to perform the following operations at runtime, including: Step S5100: For each scene block, when the real-time observation distance from the virtual camera to the scene block does not exceed the effective streaming distance set based on the scene block, load the scene block and its associated model. When the game client runs, it loads and parses the scene resource package generated according to this application, obtaining its structured metadata, including but not limited to: the spatial extent definition of all scene blocks, their respective associated default streaming distances, and detailed model mapping tables. Based on this data, the client can perform fine-grained, distance-based streaming loading scheduling on massive scene resources, with the smallest physical unit of its decision being the scene block.

[0110] Specifically, during game execution, the client can continuously and periodically (e.g., every frame or every few frames) execute loading decision logic for each scene chunk defined in the resource package. For a scene chunk currently being evaluated, the client first calculates the instantaneous spatial distance from the current virtual camera to the reference point of that scene chunk (usually its spatial center point), called the real-time observation distance of that scene chunk. This distance directly reflects the spatial proximity between the camera and the geographical area represented by that chunk.

[0111] Simultaneously, the client needs to determine the load trigger threshold used for comparison with this real-time observation distance, i.e., the effective streaming distance. The effective streaming distance is calculated based on metadata preset for that scene chunk in the resource package. In a typical embodiment, the client reads the preset (default) streaming distance for that scene chunk from the resource package. This distance is set based on the maximum visible distance among the scene objects contained within the chunk, calculated during the preprocessing stage. Next, the client may obtain a runtime dynamically adjusted global scaling factor. This factor is used to uniformly scale the default streaming distance based on the device's real-time performance, current network conditions, player image quality settings, or specific game modes to achieve the best balance between performance and visual quality. The final effective streaming distance is the product of the default streaming distance for that scene chunk and this global scaling factor. In another, simpler embodiment, if dynamic scaling is not enabled, the effective streaming distance can be directly equal to the default streaming distance.

[0112] During loading decisions, the system checks whether the real-time viewing distance from the virtual camera to the scene chunk is within (i.e., less than or equal to) the calculated effective streaming distance for that scene chunk. If the comparison result is yes, meaning the real-time viewing distance is less than or equal to the effective streaming distance, then the scene chunk is determined to be within the effective loading range, and its associated simplified model resources (and any original high-precision object resources that may be included) should be loaded into system memory for rendering. Conversely, if the real-time viewing distance is greater than the effective streaming distance, it means the camera is still too far away, and there is no need to load the chunk's resources at this time.

[0113] The decision-making process can be performed independently and in parallel for each scene tile. This decouples the loading timing of scene tiles with different spatial locations and different visual importance (determined by the visible distance of their contained objects). For example, a scene tile containing a distant castle with a large default streaming distance will be triggered to load when the player is still far away; while a scene tile containing nearby flowers and plants with a small default streaming distance will only be loaded when the player is very close. Through this loading decision based on precise spatial distance comparison and granularity at the scene tile level, a leap from coarse loading of the entire area to fine-grained scheduling of the spatial grid is achieved, ensuring that the timing of resource loading is closely matched with the actual visual presentation requirements of each spatial unit.

[0114] Step S5200: For a loaded scene block, determine the model that each scene object in the scene block should be rendered in the current rendering according to the mapping relationship recorded in the detail model mapping table, and render it.

[0115] After successfully loading one or more scene chunks into memory, the game client obtains the basic model resources needed to render the current view. These resources mainly consist of two types: first, a high-precision original scene object model associated with the loaded near-field chunk (if the scene chunk is in the nearest proximity tier); and second, uniform models of varying simplification levels generated for each loaded chunk. To correctly render the entire scene, the client needs to determine the exact model that should be rendered for each scene object within the current view, based on the detailed model mapping table.

[0116] Specifically, for each loaded scene chunk, the client needs to process the visual content within its spatial range. However, the unit of rendering is not directly the chunk model, but rather the scene objects that constitute the world. The detail model mapping table plays a crucial role in parsing and indexing here. This mapping table records which (or which scenes chunk's) simplified model each scene object's visual content was ultimately merged into after iterative degeneracy during the preprocessing stage, and the corresponding relationships at different levels.

[0117] The client's rendering logic can be executed efficiently in one of the following ways based on the mapping table: In an embodiment prioritizing smooth model switching, the client can determine a dominant viewing distance level based on the overall viewing position of the current virtual camera. For a loaded scene tile, if its distance level matches the current dominant viewing level, the simplified model corresponding to that tile is rendered directly. Simultaneously, using a detail model map, original high-precision scene object models at closer levels whose content is completely covered by the currently rendered tile model are hidden to avoid duplicate rendering. When camera movement causes a change in the dominant viewing level, the rendering switches to the tile model at the corresponding level, and the visibility of the original objects is controlled accordingly. This achieves distance-based macro-level switching between the original scene object group and the simplified aggregate model.

[0118] In another, more refined implementation, specific scene objects that are important or nearby within the field of view can be processed individually. The client determines the scene tile model to which the object is mapped under the current viewing conditions (typically determined by its distance from the camera or the loading state of its scene tile) by querying a detail model mapping table. The client then renders this mapped tile model. For the same tile model, it simultaneously represents the aggregate form of multiple spatially adjacent scene objects, thus rendering multiple objects in a single draw call, greatly improving rendering efficiency.

[0119] Regardless of the specific strategy employed, the rendering requests for scene objects are correctly directed to the loaded scene chunk model to which their content belongs through the detailed model mapping table data structure. This means that at a distance, multiple scene objects are represented by a highly simplified aggregate model; at medium distance, by another moderately simplified model; and at very close distances, independent high-precision models may be rendered directly. The rendering system automatically selects the most appropriate model version based on the mapping relationship.

[0120] Through this rendering mechanism based on a detail model mapping table, the game client achieves intelligent and efficient matching between rendered content and viewing distance. It ensures that the scene is presented with the most appropriate level of visual detail and optimal rendering performance at any viewing distance, maintaining high visual fidelity while minimizing unnecessary draw calls and geometric complexity. This significantly improves the overall rendering frame rate and visual smoothness of large-scale scenes.

[0121] Referring to the internal structure and metadata design of the scene resource package generated by this application as disclosed above, this application can also provide a corresponding game scene rendering control method. This method is specifically designed for calling such structured scene resource packages. By parsing and utilizing the core metadata such as the pre-defined distance tiers, spatial range and scheduling parameters of scene blocks, and detail model mapping tables within the resource package during game runtime, it achieves refined, on-demand streaming loading and high-fidelity rendering of massive scene objects in the game world.

[0122] In a typical embodiment, the method comprises two logically interconnected core stages. First, based on the spatial distance from the virtual camera to each scene block, a comparison is made with the effective streaming distance set for that scene block based on metadata within the resource package. This allows for an independent and precise decision to load scene blocks and their associated model resources that fall within the effective loading range. Second, for loaded scene blocks, the model to be rendered for each scene object within the current field of view is determined and rendered according to the mapping relationship recorded in the detail model mapping table. This mapping relationship clarifies which specific scene block's simplified model each scene object's visual content is ultimately merged into at different viewing levels, thereby guiding the rendering system to correctly call the corresponding block aggregation model or original object model.

[0123] This method is built upon the rich data provided by the scene resource package generated in this application. The scene resource package includes a preset default streaming distance for each scene chunk, the value of which is scientifically set based on the visual attributes (maximum visible distance) of scene objects within that chunk, providing a reasonable and adjustable benchmark for loading decisions. The detailed model mapping table constructed within the resource package establishes a direct and unambiguous index relationship from scene objects to the specific scene chunk models they belong to at different levels. The runtime method continuously calculates real-time spatial distances and uses these preset chunk parameters and mapping relationships for querying and comparison, transforming the static resource package into a dynamic scheduling system capable of intelligently responding to changes in the player's perspective and position. This transforms the traditionally complex spatial calculations or heavy-coded loading and rendering decisions required at runtime into efficient data querying, simple numerical comparisons, and model switching operations based on the mapping table.

[0124] After applying the game scene rendering control method of this application, the game client can manage the lifecycle of scene resources with unprecedented precision at the scene chunk level. This allows distant areas to be loaded in time before their content becomes visible, while a large number of near-field details are prevented from being loaded prematurely, thus optimizing memory usage and I / O pressure at the source. Simultaneously, by intelligently associating objects with chunk models through a detail model mapping table, it ensures that the scene is automatically rendered at the most appropriate level of visual detail (high-precision independent objects or chunk aggregation models with different degrees of simplification) at any viewing distance, maximizing rendering batch processing efficiency while maintaining high visual fidelity. Ultimately, this collaborative mechanism, driven by preprocessed structured data and executed efficiently at runtime, achieves smooth, stutter-free, and visually continuous high-quality presentation of large-scale game scenes, significantly improving the overall performance and user experience of open-world and other game types.

[0125] Please see Figure 6According to one aspect of this application, a scene resource package generation device includes a tiered partitioning module 3100, a logical segmentation module 3200, a degeneracy generation module 3300, and a resource encapsulation module 3400. The tiered partitioning module 3100 is configured to, for a scene map of a game world, determine the target distance tier in the distance tier sequence to which each scene object belongs based on the visible distance of each scene object in the scene map, and define scene objects belonging to the same distance tier as a logical object set of that distance tier. The logical segmentation module 3200 is configured to, according to the corresponding tiered partitioning specifications of each distance tier, divide the area where the logical object set corresponding to the distance tier is distributed into multiple scene blocks in the spatial dimension, wherein each scene block contains elements falling within its spatial range. The original models of scene objects belonging to the logical object set; the degeneracy generation module 3300 is configured to generate models of scene objects in scene blocks for each distance tier in the distance tier sequence from near to far, wherein the model of any distance tier is obtained by spatially degenerated based on the original model of the scene object that falls within the spatial range of the scene block and is unique to that distance tier, and the models generated by all preceding distance tiers that overlap with the scene block in space; the resource encapsulation module 3400 is configured to construct scene resource packages for the game program running on the client to call, wherein the scene resource package contains a detailed model mapping table for recording the mapping relationship between each scene object in the scene block and the model used in the corresponding scene block of each distance tier.

[0126] Based on any embodiment of the device in this application, the tiered segmentation module 3100 includes: a relationship determination module, configured to traverse the visually visible elements in the scene map and determine the spatial dependency relationship of each visually visible element; a grouping processing module, configured to package visually visible elements with spatial dependencies into scene objects corresponding to the same group, and treat visually visible elements without spatial dependencies as independent scene objects; and a viewing distance determination module, configured to determine the visible distance of each scene object and store the visible distance as the metadata of the scene object, wherein the visible distance is the maximum value among the visible distances of each visually visible element within the scene object.

[0127] Based on any embodiment of the device in this application, the viewing distance determination module includes: a size acquisition module, configured to acquire the bounding box size of each visually visible element contained in the scene object in the game world; a viewing distance calculation module, configured to substitute the bounding box size, a preset minimum screen space ratio, and the field of view angle of a standard virtual camera into a preset geometric projection formula to calculate the visible distance of each visually visible element; and a viewing distance setting module, configured to determine the maximum value among the visible distances of all visually visible elements of the scene object as the visible distance of the scene object.

[0128] Based on any embodiment of the device in this application, the tier segmentation module includes: a tier setting module, configured to acquire a pre-set distance tier sequence to determine multiple distance tiers, wherein each distance tier is associated with a distance upper limit defined relative to a scene object; an object partitioning module, configured to compare the visible distance of each scene object sequentially with the distance upper limit of each distance tier, and partition the scene object into the distance tier to which its visible distance falls, wherein the partitioned distance tier is the first distance tier among the multiple distance tiers whose distance upper limit is greater than or equal to the visible distance of the scene object; and a logical association module, configured to add each scene object in the scene map to the logical object set corresponding to the distance tier to which the scene object belongs, according to the distance tier to which the scene object belongs.

[0129] Based on any embodiment of the apparatus in this application, the degeneracy generation module 3300 includes: a first-level generation module, configured to determine the original models contained in each scene block of the first distance level in the distance level sequence as the model of the first distance level; a further-level generation module, configured to geometrically merge and simplify the original models of the scene objects unique to each scene block of the next further distance level in the distance level sequence with the models generated for the previous distance level that overlap with the scene block in space, to generate the model of the current distance level; and an iterative decision module, configured to iteratively execute the above operations for the next further distance level in the order of distance from near to far, to generate a model for each distance level.

[0130] Based on any embodiment of the device in this application, prior to the resource packet module 3400, it includes: a default distance setting module, configured to set a default streaming distance for each scene block of each distance tier, the default streaming distance being set based on the maximum visible distance among the scene objects contained in the scene block; and a data storage module, configured to store the default streaming distance as metadata associated with the corresponding scene block.

[0131] Based on any embodiment of the device in this application, the resource packaging module 3400 includes: a data construction module, configured to serialize the identifiers and segmentation specifications of each distance tier defined in the scene map, the spatial range definition of each scene block and the associated default streaming distance, and the detailed model mapping table into structured description data; a compression and packaging module, configured to compress and package the structured description data and the model data generated for each scene block; and a file output module, configured to generate and output a scene resource package file corresponding to the scene map that can be loaded and parsed by the game client.

[0132] Based on any embodiment of the device in this application, prior to the resource packet module 3400, a distance setting module is included, configured such that each scene block has a preset streaming distance and an unloading distance; wherein, the streaming distance is used to trigger loading of the scene block when the real-time observation distance from the virtual camera to the scene block reaches the streaming distance during game execution; the unloading distance is used to trigger unloading of the scene block when the real-time observation distance from the virtual camera to the scene block exceeds the unloading distance during game execution; and the settings of the streaming distance and the unloading distance satisfy the following relationship: for any scene block, its streaming distance is greater than the maximum visible distance among all scene objects contained in the scene block, and its unloading distance is greater than its streaming distance.

[0133] Based on any embodiment of the device in this application, the scene resource package is configured to allow the game client to activate the following modules during runtime: a loading application module, configured to load the scene block and its associated model for each scene block when the real-time observation distance from the virtual camera to the scene block does not exceed the effective streaming distance set based on the scene block; and a rendering application module, configured to determine the model that should be rendered for each scene object in the scene block and render it according to the mapping relationship recorded in the detail model mapping table for the loaded scene block.

[0134] Another embodiment of this application also provides an electronic device. For example... Figure 7 The diagram shows the internal structure of an electronic device. This electronic device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable, non-volatile storage medium stores an operating system, a database, and computer-readable instructions. The database can store information sequences, and when executed by the processor, the computer-readable instructions enable the processor to implement a method for generating a scene resource package.

[0135] The processor of this electronic device provides computing and control capabilities to support the operation of the entire device. The memory of this electronic device can store computer-readable instructions, which, when executed by the processor, cause the processor to perform the scene resource package generation method of this application. The network interface of this electronic device is used for communication with a terminal.

[0136] Those skilled in the art will understand that Figure 7 The 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 electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0137] In this embodiment, the processor is used to execute... Figure 6 The specific functions of each module are described, and the memory stores the program code and various data required to execute the above modules or sub-modules. The network interface is used to realize data transmission between user terminals or servers. The non-volatile readable storage medium in this embodiment stores the program code and data required to execute all modules in the scene resource package generation device of this application, and the server can call the server's program code and data to execute the functions of all modules.

[0138] This application also provides a non-volatile readable storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the scene resource package generation method of any embodiment of this application.

[0139] This application also provides a computer program product, including a computer program / instructions that, when executed by one or more processors, implement the steps of the method described in any embodiment of this application.

[0140] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a computer-readable storage medium such as a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM).

Claims

1. A method for generating a scene resource package, characterized in that, include: For the scene map of the game world, based on the visible distance of each scene object in the scene map, determine the target distance level in the distance level sequence to which each scene object belongs, and define the scene objects belonging to the same distance level as the logical object set of that distance level. According to the corresponding tier segmentation specifications for each distance tier, the area where the logical object set corresponding to the distance tier is distributed is divided into multiple scene blocks in the spatial dimension. Each scene block contains the original model of the scene objects belonging to the logical object set that fall within its spatial range. Along the distance ladder sequence from near to far, a model of the scene object in its scene block is generated for each distance ladder. The model of any distance ladder is obtained by spatially simplifying the original model of the scene object that falls within the spatial range of the scene block and is unique to that distance ladder, with the models generated by all preceding distance ladders that overlap with the scene block in space. A scene resource package is constructed for the game program running on the client to call. The scene resource package contains a detailed model mapping table for recording the mapping relationship between each scene object in the scene plot and the model used in the corresponding scene block at each distance level.

2. The method for generating scene resource packages according to claim 1, characterized in that, Before determining the target distance tier and corresponding logical object set in the distance tier sequence to which each scene object belongs, based on the visible distance of each scene object in the scene map, the process includes: Traverse the visually visible elements in the scene map and determine the spatial dependencies of each visually visible element; Visually visible elements with spatial dependencies are grouped into scene objects corresponding to the same group, while visually visible elements without spatial dependencies are treated as independent scene objects. Determine the visible distance of each scene object and store the visible distance as the metadata of the scene object, wherein the visible distance is the maximum value among the visible distances of all visually visible elements within the scene object.

3. The method for generating scene resource packages according to claim 2, characterized in that, Determine the visible distance for each scene object, including: Get the bounding box size of each visually visible element contained in the scene object in the game world; The visible distance of each visually visible element is calculated by substituting the bounding box size, the preset minimum screen space ratio, and the field of view of the standard virtual camera into the preset geometric projection formula. The maximum value among the visible distances of all visually visible elements of the scene object is determined as the visible distance of the scene object.

4. The method for generating scene resource packages according to claim 1, characterized in that, Based on the visible distance of each scene object in the scene map, determine the target distance tier and corresponding logical object set in the distance tier sequence to which each scene object belongs, including: Obtain a pre-defined sequence of distance levels to determine multiple distance levels, where each distance level is associated with a relative upper limit of distance defined with reference to the scene object; The visible distance of each scene object is compared with the upper limit of each distance tier in turn, and the scene object is divided into the distance tier to which its visible distance falls. The distance tier to which it falls is the first distance tier among the plurality of distance tiers that satisfies that its upper limit is greater than or equal to the visible distance of the scene object. Based on the distance tier to which the scene object belongs, add each scene object in the scene map to the logical object set corresponding to the distance tier to which the scene object belongs.

5. The method for generating scene resource packages according to claim 1, characterized in that, Following the distance hierarchy sequence from nearest to farthest, generate a model of the scene objects in the scene chunk for each distance hierarchy, including: For the first distance step in the distance step sequence that is closest to the first distance step, the original models contained in each scene block of that first distance step are determined as the models of that first distance step; For the next more distant distance step in the distance step sequence, the original model of the scene object unique to each scene block in that distance step is geometrically merged and simplified with the model generated for the previous distance step that overlaps with that scene block in space, to generate the model of the current distance step. The above operations for the next, more distant distance level are performed iteratively, generating a model for each distance level.

6. The method for generating scene resource packages according to claim 1, characterized in that, Before constructing the scene resource package for the game program running on the client, the following steps are included: A default streaming distance is set for each scene block of each distance tier, and the default streaming distance is set based on the maximum visible distance of the scene objects contained in the scene block; The default streaming distance is stored as metadata associated with the corresponding scene blocks.

7. The method for generating scene resource packages according to claim 1, characterized in that, Construct scene resource packages for the game program running on the client to call, including: For the scene map, the identifiers and segmentation specifications of each distance level, the spatial range definition of each scene block and the associated default streaming distance, and the detailed model mapping table are serialized together into structured descriptive data. The structured description data and the model data generated for each scene block are compressed and packaged. Generate and output a scene resource package file corresponding to the scene map, which can be loaded and parsed by the game client.

8. The method for generating scene resource packages according to any one of claims 1 to 7, characterized in that, Before constructing the scene resource package for the game program running on the client, the following steps are included: For each scenario segment, a first-order delivery distance and a first-order unloading distance are preset; The streaming distance is used to trigger loading of the scene segment when the real-time observation distance from the virtual camera to the scene segment reaches the streaming distance during game runtime; the unloading distance is used to trigger unloading of the scene segment when the real-time observation distance from the virtual camera to the scene segment exceeds the unloading distance during game runtime. Furthermore, the settings for the streaming distance and the unloading distance satisfy the following relationship: for any scene block, its streaming distance is greater than the maximum visible distance among all scene objects contained in that scene block, and its unloading distance is greater than its streaming distance.

9. The method for generating a scene resource package according to any one of claims 1 to 7, characterized in that, The scene resource package is configured to allow the game client to perform the following operations at runtime, including: For each scene block, when the real-time observation distance from the virtual camera to that scene block does not exceed the effective streaming distance set based on that scene block, the scene block and its associated model are loaded. For a loaded scene block, based on the mapping relationship recorded in the detailed model mapping table, determine the model that each scene object in the scene block should be rendered and render it.

10. A scene resource package generation device, characterized in that, include: The tier division module is set to target the scene map of the game world. Based on the visible distance of each scene object in the scene map, it determines the target distance tier in the distance tier sequence to which each scene object belongs, and defines the scene objects belonging to the same distance tier as the logical object set of that distance tier. The logical segmentation module is configured to divide the area where the logical object set corresponding to each distance step is distributed into multiple scene blocks in the spatial dimension according to the corresponding step segmentation specification. Each scene block contains the original model of the scene object belonging to the logical object set that falls within its spatial range. The degeneracy generation module is configured to generate a model of the scene object in the scene block for each distance step in the distance step sequence from near to far. The model of any distance step is obtained by spatially degenerated based on the original model of the scene object that falls within the spatial range of the scene block and is unique to that distance step, and the models generated by all preceding distance steps that overlap with the scene block in space. The resource package module is configured to construct scene resource packages for the game program running on the client to call. The scene resource package contains a detailed model mapping table for recording the mapping relationship between each scene object in the scene plot and the model used in the corresponding scene block at each distance level.

11. An electronic device comprising a central processing unit and a memory, characterized in that, The central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 9.

12. A non-volatile readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 9, which, when invoked by a computer, executes the steps included in the corresponding method.

Images