Game scene rendering control method and device, equipment and medium

Abstract

The application relates to a game scene rendering control method and device, equipment and a medium. The method comprises the following steps: calling a scene resource package containing multiple layers of scene blocks, the multiple layers of scene blocks are divided based on distance steps, and multiple scene blocks belonging to different distance steps exist in the same space range, each block is provided with a streaming distance and is associated with a model of a scene object adapting to the distance step of the block; continuously acquiring a space position of a virtual camera, determining a scene observation distance to each scene block based on the space position; determining and loading a target scene block and a model associated with the target scene block from the multiple layers of scene blocks according to the scene observation distance and the streaming distance of each scene block; and for the target scene block, querying a detailed model mapping table in the scene resource package according to an object observation distance of the virtual camera to a scene object, and determining a model called by the scene object for rendering. The application realizes fine on-demand loading of scene objects, and can optimize memory and rendering efficiency.

Description

Technical Field

[0001] This application relates to the field of game image processing technology, and in particular to a game scene rendering control method, apparatus, device, and medium thereof. Background Technology

[0002] In game development, especially in the rendering practice of large-scale open-world games, the game map is often loaded using a streaming method. This allows for the efficient scheduling and presentation of massive scene objects within the field of view of the player, i.e., the virtual camera in the game scene, while avoiding memory overflow and performance lag caused by loading all resources at once.

[0003] In widely used traditional techniques, the game world is pre-divided into multiple relatively independent scene tiles. During game runtime, the spatial distance between the virtual camera's position and the boundary of each scene tile is continuously calculated and compared with a pre-set loading distance threshold for the entire scene tile. Once the camera's distance does not exceed the threshold, a loading command is triggered, loading all scene object resources associated with that scene tile, including high-precision models, textures, lighting information, etc., from storage devices into memory for use by the rendering pipeline. Conversely, when the camera moves away and the distance exceeds the threshold, the entire tile is unloaded to free up memory.

[0004] However, this traditional approach, which loads scenes at the granular level and relies on a single distance threshold, has significant limitations in practical applications. The fundamental reason is that a scene typically contains a large number of visually diverse objects. For example, a scene might simultaneously contain a distant, towering castle, mid-ground trees, and nearby flowers, grass, and pebbles. The visual importance of these objects and their effective recognition distance on the screen vary greatly. A castle, due to its massive size, might be clearly visible from thousands of meters away, while a blade of grass might be difficult to distinguish even within tens of meters.

[0005] However, traditional solutions often have to adopt a compromise or a strategy based on the most conspicuous objects when setting a single loading distance threshold for the entire plot. If a higher threshold is set based on the most conspicuous objects, many secondary objects that should only be loaded at close range will be loaded into memory prematurely, resulting in wasted memory resources and redundant data loading. Conversely, if a higher threshold is set based on less conspicuous objects, some important distant objects may be missing from the player's field of vision because the loading conditions have not been met, creating visual voids or abrupt pop-up effects.

[0006] Therefore, the granularity of traditional technology loading decisions is too coarse, and it is impossible to manage the scene objects in a differentiated and refined manner according to their own visual characteristics. As a result, it is difficult to achieve the optimal balance between memory and input / output load while ensuring visual continuity, which affects the smoothness of the game. Summary of the Invention

[0007] The purpose of this application is to solve the above-mentioned problems by providing a game scene rendering control method and its corresponding apparatus, device, non-volatile readable storage medium, and computer program product.

[0008] According to one aspect of this application, a game scene rendering control method is provided, comprising: Call a scene resource package containing multi-level scene blocks. The multi-level scene blocks are divided based on a preset distance tier. For the same spatial range in the scene map, there are multiple scene blocks belonging to different distance tiers. Each scene block has a preset streaming distance and is associated with a model of a scene object that is adapted to its respective distance tier. The scene object belongs to the corresponding distance tier according to its visible distance. Continuously acquire the spatial position of the virtual camera in the game scene, and determine the scene observation distance from the virtual camera to each scene block based on the spatial position; Based on the comparison between the scene observation distance and the streaming distance of each scene block, the target scene block and its associated model are determined and loaded from the multi-layer scene blocks; For the loaded target scene block, based on the object observation distance from the virtual camera to the scene object, the detail model mapping table in the scene resource package is queried to determine the model that the scene object should call for rendering.

[0009] According to another aspect of this application, a game scene rendering control device is provided, comprising: The resource invocation module is configured to invoke a scene resource package containing multi-level scene blocks. The multi-level scene blocks are divided based on a preset distance tier, and there are multiple scene blocks belonging to different distance tiers in the same spatial range in the scene map. Each scene block has a personalized preset streaming distance and is associated with a model of a scene object that is adapted to its respective distance tier. The scene object belongs to the corresponding distance tier according to its visible distance. The observation distance module is set to continuously acquire the spatial position of the virtual camera in the game scene, and determine the scene observation distance from the virtual camera to each scene block based on the spatial position; The segmented loading module is configured to determine and load the target scene segment and its associated model from the multi-layer scene segments based on the comparison result between the scene observation distance and the streaming distance of each scene segment. The object rendering module is configured to, for the loaded target scene blocks, query the detail model mapping table in the scene resource package based on the object observation distance from the virtual camera to the scene object, and determine the model that the scene object should call for rendering.

[0010] 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.

[0011] According to another aspect of this application, a non-volatile readable storage medium is provided, which stores a computer program implemented according to the game scene rendering control 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.

[0012] 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.

[0013] This application utilizes a unique scene resource package. Scene objects within this package are pre-divided into different distance tiers based on their visible distance, constructing multi-layered scene blocks. This fundamentally refines the granularity of loading and rendering scheduling, completely abandoning the coarse-grained approach of traditional techniques that treats entire plots as units. Instead, it uses scene blocks directly related to visual perception as the smallest decision-making unit. During runtime, the game program can independently set streaming distances for scene blocks at different distance tiers. This allows distant tier scene blocks containing far-view objects to be pre-loaded promptly due to their larger streaming distance, while near-view tier blocks containing close-view objects are precisely delayed in loading due to their smaller streaming distance. This significantly reduces redundant data transmission and memory usage at the source, optimizing input / output load. During the rendering phase, by querying the detail model mapping table associated with the loaded target scene blocks, the application can quickly match and call ready-made models adapted to the corresponding distance tier based on the real-time object viewing distance from the virtual camera to each scene object, ensuring that scene objects are always presented with the most appropriate visual precision. This approach effectively eliminates visual gaps and pop-ups caused by untimely resource loading or improper model switching, achieving a dynamic and precise balance between rendering load and visual fidelity. Ultimately, this application significantly improves memory usage efficiency and smoothness in large-scale game scenes while ensuring seamless, high-quality visual continuity, providing a systematic solution for high-performance rendering of open-world games. Attached Figure Description

[0014] Figure 1 This is an exemplary network architecture used in this application to run the game; Figure 2 A flowchart illustrating one embodiment of the game scene rendering control 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 game scene rendering control device of this application. Figure 7 This is a schematic diagram of the structure of an electronic device used in this application. Detailed Implementation

[0015] The technical solution of this application can be deployed on client computing devices that run large-scale 3D games, such as open-world games. Figure 1 This diagram illustrates a typical runtime architecture, in which a terminal device 80 (e.g., a personal computer, game console, or mobile device) is the primary carrier for executing the game scene rendering control method of this application. The terminal device 80 connects to the game server 81 via a network to obtain global game state and logic information, but the core of its local rendering process is to load and parse a scene resource package with a specific structure, and autonomously and finely schedule rendering resources accordingly.

[0016] This application is particularly applicable to building high-performance client-side rendering systems for open-world games with vast geographical spaces and massive visual details. In such applications, the entire game world is treated as a unified scene map. This application aims to provide a method that can dynamically, efficiently, and finely schedule and render massive objects within the scene map based on the real-time position of the virtual camera during game client runtime, thereby maintaining a smooth experience with high frame rates, high image quality, and visual continuity under limited memory and computing resources.

[0017] The game scene rendering control method described in this application can be implemented collaboratively by hardware components such as the central processing unit (CPU), graphics processing unit (GPU), memory, and network interface included in the terminal device 80. Specifically, the CPU is responsible for executing core logic tasks, including parsing scene resource packages, continuously tracking the virtual camera position, calculating spatial observation distance, performing streaming distance comparisons to decide on the loading and unloading of scene chunks, and managing asynchronous loading queues. The GPU is specifically responsible for performing rendering pipeline tasks such as vertex processing, rasterization, shading, and final pixel drawing on the loaded scene chunk models. The memory is used to store scene resource packages loaded from storage media, parsed metadata, scene chunk models loaded into memory, and various runtime state lists (such as loading queues and unloading lists). Through the network interface, the client can obtain the initial scene resource package or incremental updates.

[0018] Through specific programming and collaboration of the aforementioned hardware components, the method of this application transforms the traditionally coarse-grained streaming loading and rendering process based on fixed geographical plots into a refined, automated control process driven by distance-level and multi-layered scene block data structures. This process deeply optimizes memory and video memory usage (on-demand loading and releasing of block models), reduces redundant storage I / O traffic (avoiding bundled loading), and improves the rendering efficiency of graphics processing units (reducing drawing calls through scene block aggregation models), thereby significantly improving the smoothness and energy efficiency of game operation at the physical level.

[0019] To facilitate understanding of subsequent embodiments, some basic concepts involved in this application are uniformly explained here. A scene map refers to the complete game world geographic space to be rendered and is the overall unit for integrated scheduling processing in this application's method. A scene object is a basic element or logical combination constituting the visual content of the scene map, such as an independent model or a group of spatially and logically related models. Visible distance is a theoretical value calculated or predefined for each scene object, representing the limit of spatial distance at which an observer (virtual camera) can clearly see the object when the pixel proportion occupied by the object in the screen space is lower than a preset threshold. Distance tiers are preset levels for logically classifying scene objects based on visible distance. Each distance tier corresponds to a distance range, which is jointly defined by the upper limit of the current distance tier and the upper limit of the next closer distance tier. A scene block is an area with a regular geographic range (such as a cube) divided in the scene map according to the specific tier division specifications of its respective distance tier. It is the smallest physical unit for streaming loading scheduling and resource binding in this application. Multi-level scene chunking refers to a set of multiple scene chunks that overlap or contain each other spatially, divided according to different distance tiers for the same spatial range. Streaming distance is a preset critical distance threshold for each scene chunk, used to trigger its loading behavior at runtime. The detailed model mapping table is a key data structure that records the mapping relationship between each scene object within the scene map and the model used in its corresponding scene chunk at each distance tier.

[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 2 The game scene rendering control method of this application can be installed and run on a computer program product on an electronic device used by a player as a client. In some embodiments, it includes the following steps: Step S3100: Call the scene resource package containing multi-level scene blocks. The multi-level scene blocks are divided based on a preset distance tier. For the same spatial range in the scene map, there are multiple scene blocks belonging to different distance tiers. Each scene block has a preset streaming distance and is associated with a model of a scene object that is adapted to its respective distance tier. The scene object belongs to the corresponding distance tier according to its visible distance. The game world, as a complete scene map, contains a vast and diverse array of visual elements, namely scene objects. These scene objects vary significantly in visual importance, geometric complexity, and spatial distribution. For example, a magnificent castle or tower, due to its immense size, can be recognized by players from thousands of meters away, possessing an extremely long visibility distance. A forest or thicket at a medium distance may become clear within a range of hundreds of meters. However, nearby flowers, gravel, or ground texture details may only be visible at a distance of tens of meters. To scientifically manage these objects, during the preprocessing stage of generating scene resource packages, each scene object is logically categorized into a preset distance hierarchy based on this key visual attribute of visibility distance.

[0022] In this application, the distance hierarchy is a logical sequence ordered from near to far based on the observation distance, with each hierarchy associated with a defined upper distance limit. (Reference) Figure 3 As shown, three distance levels, L0, L1, and L2, can be set, with upper limits of 100 meters, 500 meters, and 2000 meters, respectively. A nearby rock with a visible distance of 80 meters would be assigned to level L0, a mid-ground tree with a visible distance of 350 meters would be assigned to level L1, and a distant castle with a visible distance of 1500 meters would be assigned to level L2. The calculation of visible distance can be implemented in various ways. In one embodiment, it can be based on the bounding box size of the scene object, the minimum pixel ratio expected to occupy on the screen (screen space ratio), and the field of view of a standard virtual camera, through methods such as... Figure 5 The geometric projection principle shown automatically calculates the theoretical value in a formulaic way.

[0023] Based on the above logical division, the preprocessing process further constructs physical management units, i.e., scene blocks, for each distance level in the spatial dimension. This is achieved by determining the spatial grid size by applying its own unique level segmentation specification to each distance level. For example... Figure 4 As shown, for the L0 level closest to the observation point, a fine-grained small grid is used to divide the scene, generating numerous small scene blocks 101 to support extremely high-precision local scheduling. For the mid-distance L1 level, a medium-sized grid is used to generate fewer but larger scene blocks 10. For the farthest L2 level, the coarsest large grid is used to generate large scene blocks 1 covering a wide area. As a result, for the same geographic area in the scene map, such as an area containing castles, trees, and rocks, multiple scene blocks belonging to the three different distance levels (L0, L1, and L2) will exist simultaneously, forming a spatially overlapping relationship. These blocks together constitute a multi-layered scene block data structure.

[0024] Each scene tile is associated with key metadata and model data upon creation. The streaming distance is a preset distance threshold used to trigger loading of that scene tile. In one embodiment, the streaming distance is conservatively set, with a value greater than or equal to the maximum visible distance of all scene objects contained within the scene tile, ensuring that the resources of any object within the tile are loaded before it can theoretically become visible. Each scene tile is also associated with a scene object model adapted to its corresponding distance level. This means that objects falling into scene tile 101 corresponding to distance level L0 (such as nearby rocks) are associated with high-detail precision models prepared for very close-up viewing; objects falling into scene tile 10 corresponding to distance level L2 (such as distant castles) are associated with highly simplified, low-polygon aggregate models to outline their contours from a distance. Model adaptation can be achieved through various specific techniques, including but not limited to manually creating multiple model versions with different levels of detail for the same scene object and assigning them according to the tier, or processing the high-definition original model of the scene object through an automated geometric simplification algorithm to generate a simplified model that meets the visual requirements of each distance tier.

[0025] The scene resource package, comprising all data including the aforementioned multi-layered scene segmentation definition information, the streaming distance of each scene segment, the adapted models associated with each scene segment, and a detailed model mapping table recording the mapping relationship between each scene object and the segment model to which it belongs at each distance level, is serialized and packaged to form the scene resource package invoked in this application. This package can be uploaded to a server for the client of this application to download on demand, or it can be pre-installed in the client of this application for invocation by the game program of the client. Invoking this scene resource package means that the client reads the corresponding package file from the storage medium, parses the structured data within, and reconstructs the multi-layered spatial index, model references, and scheduling parameters of the scene map in memory, thus preparing all the data for subsequent real-time calculations and decisions. In one embodiment, the entire scene map corresponds to one scene resource package; in another embodiment focusing on dynamic updates, a large scene map may be divided into multiple resource packages, which the client loads on demand.

[0026] Step S3200: Continuously acquire the spatial position of the virtual camera in the game scene, and determine the scene observation distance from the virtual camera to each scene block based on the spatial position; After successfully calling and parsing the scene resource package and constructing an in-memory data structure containing multi-layered scene blocks and their metadata (including the spatial range and streaming distance of each block), this step initiates a continuous spatial monitoring and calculation loop during game runtime. Its goal is to provide real-time, quantified distance input for subsequent loading decisions. To this end, the dynamic spatial position of the virtual camera representing the player's viewpoint is continuously tracked, and based on this, the instantaneous spatial interval between this spatial position and each scene block defined in the scene resource package is calculated. This interval is defined as the scene observation distance.

[0027] One method for obtaining the spatial position of a virtual camera is to directly read its position information in real time from the core module of the game engine or the camera component interface. This position is typically a three-dimensional vector represented in the game world coordinate system. In another embodiment, the virtual camera's position can be calculated and predicted by the local client based on player input (such as keyboard, mouse, or gamepad operations), and can also be corrected by receiving authoritative position updates from the game server to ensure spatial consistency in a multi-player environment. The frequency of position updates can be synchronized with the game's logical frame rate or rendering frame rate, for example, updating once per frame, or an independent, fixed sampling frequency can be used based on performance considerations.

[0028] Based on the acquired spatial position of the virtual camera, the scene observation distance to each scene block is calculated, specifically according to the spatial range of the scene block defined in the preprocessing stage. One efficient calculation method is to use the geometric center point (or bounding box center point) of each scene block as its spatial representative point. The calculation process involves solving the Euclidean distance between the current position of the virtual camera and this representative point. This method has low computational overhead and is suitable for performing large-scale distance calculations per frame or periodically on a massive number of scene blocks. In another embodiment with higher accuracy requirements, the scene observation distance can be defined as the closest distance from the virtual camera position to the surface of the geometric bounding box of that scene block. This calculation more accurately reflects the instant of entering the influence range of the scene block. Regardless of the representative point or calculation method used, the goal is to generate a scalar value to quantify the spatial proximity between the virtual camera and the geographical area managed by each scene block.

[0029] The calculation of scene observation distance can be scheduled over time using various strategies. In one embodiment, a global calculation strategy is employed, where all scene blocks in the scene resource package are traversed within each decision cycle, and their scene observation distances to the current virtual camera are calculated uniformly. This strategy is simple to implement, but the computational load increases linearly with the total number of scene blocks. In another embodiment focused on performance optimization, incremental calculation or spatial index filtering strategies can be used. For example, by utilizing the spatial hierarchy of scene blocks (such as quadtrees, octrees, or grid spatial indexes), scene blocks that are obviously too far from the current position of the virtual camera and have no chance of meeting the loading conditions (i.e., their scene observation distance is much greater than their streaming distance) can be quickly eliminated, and only the remaining possible candidate scene blocks are subjected to precise distance calculation. This can significantly reduce unnecessary computational overhead. Furthermore, the calculation frequency itself can also be adjustable. For example, for distant scene blocks with large streaming distances, the calculation update frequency of their scene observation distances can be appropriately reduced; while for near scene blocks with small streaming distances, high-frequency calculation synchronized with the rendering frame rate is used to ensure timely loading response.

[0030] Step S3300: Based on the comparison result between the scene observation distance and the streaming distance of each scene block, determine and load the target scene block and its associated model from the multi-layer scene blocks; After continuously calculating the scene observation distance from the virtual camera to each scene block, the target scene block that should be loaded into memory can be selected from the multi-layer scene blocks based on the numerical comparison between the scene observation distance and the predefined streaming distance of each scene block, and the loading process of its associated model can be started.

[0031] The comparison operation is the basis of decision-making. In one embodiment, the comparison logic uses a threshold judgment, that is, when the calculated scene observation distance is less than or equal to the streaming distance of the scene segment, the scene segment is determined to meet the loading condition. In another more conservative or hysteresis-designed embodiment, a start distance slightly smaller than the streaming distance can be introduced, and loading is only triggered when the scene observation distance is less than or equal to the start distance, to provide a certain pre-loading buffer. The comparison can be performed in real time or periodically. Under the real-time strategy, the comparison is performed on all relevant scene segments immediately after each virtual camera position update or scene observation distance recalculation. Under the periodic strategy, a fixed time interval (such as every 0.1 seconds) or frame interval can be set to process all scene segments to be decided in batches to smooth out performance overhead.

[0032] Determining target scene chunks based on comparison results involves managing and filtering the set of states that meet the loading conditions. In one embodiment, all scene chunks whose scene observation distance is less than or equal to their streaming distance are directly determined as target scene chunks in the current frame or current decision cycle. However, in actual deployments, loading behavior is constrained by system resources (such as memory and I / O bandwidth), so further control can be applied to the set of target scene chunks. One embodiment is to introduce a loading priority mechanism. Priorities can be set based on various factors, including but not limited to: the ratio of scene observation distance to streaming distance, where a smaller ratio indicates that the virtual camera is closer to the chunk, resulting in higher priority; the distance tier to which the scene chunk belongs, where chunks in closer distance tiers have a greater impact on the visual experience due to their higher detail models, and can be given higher priority; or the historical access frequency of the scene chunk and the predicted player movement direction. After determining the priority, the loading tasks of target scene chunks can be added to an asynchronous loading queue according to the priority order.

[0033] Once the target scene chunk is determined, the loading process of its associated models is triggered. The essence of loading is to transfer and decode model data stored in persistent media such as hard drives, solid-state drives, or network servers to volatile memory such as system memory or video memory, making it accessible to the rendering pipeline. In one embodiment, loading can be performed asynchronously; the main logic thread continues running after submitting the loading task to the I / O thread or a dedicated loading thread, without blocking game logic and rendering. The model data itself can include geometric mesh data, texture maps, material properties, and shader programs. The amount of data varies significantly for models adapted to different distance levels. For example, a target scene chunk adapted to the L0 distance level may be associated with a collection of independent, high-precision models containing millions of triangles, resulting in a long loading time; while a distant scene chunk adapted to the L2 distance level may be associated with a single, highly merged and simplified aggregate model containing only a few thousand triangles, resulting in extremely fast loading.

[0034] The loading process also requires handling dependencies and state management between models. Once the model data for a target scene chunk is successfully loaded into memory, the state of that scene chunk is updated from "never loaded" to "loaded." To address this, a list of loaded scene chunks can be maintained, ensuring that the binding relationship between the model and the rendering pipeline is correctly established for each loaded scene chunk, such as registering rendering instances and updating scene graph nodes. If loading fails, errors can be detected and retry or rollback strategies can be implemented, such as attempting to load a backup model with a lower level of detail, or at least logging the error to prevent game crashes. For scene chunks that were previously loaded but no longer meet the loading conditions based on new comparison results (i.e., the scene observation distance is greater than the streaming distance), their unloading is not directly processed. The unloading logic can be handled by a separate resource management module in subsequent steps, but the decision result of this step can also be an important input to trigger the unloading judgment.

[0035] Through the above comparison, decision-making, and loading process, the game program can dynamically and precisely select the most urgently needed visual content from the multi-layered scene block structure based on the player's (virtual camera's) real-time position, and start loading its resources to prepare for the final high-quality rendering. At the same time, through priority queues and asynchronous loading mechanisms, the impact of I / O operations on the smoothness of game operation is effectively smoothed out.

[0036] Step S3400: For the loaded target scene block, based on the object observation distance from the virtual camera to the scene object, query the detail model mapping table in the scene resource package to determine the model that the scene object should call for rendering.

[0037] After determining the target scene blocks and loading the models, the basic visual resources required to present the current view are available. Based on this, for each target scene block successfully loaded into memory, the most suitable model under the current viewing conditions can be accurately determined and invoked for rendering each scene object managed within it, thus completing the final transformation from resource readiness to screen pixels. In this application, this process is not a simple traversal and rendering of all models within the block, but rather implemented based on a refined matching logic. Specifically, it relies on a data structure—the detailed model mapping table—built in the scene resource package during the preprocessing stage.

[0038] The detailed model mapping table records the mapping relationship between each scene object in the scene map and its corresponding scene tile model generated in the preprocessing pipeline, located at different distance levels. This mapping relationship clarifies which generated concrete model should be responsible for rendering the visual representation of a specific scene object under specific viewing distance conditions. This design enables the rendering system to go beyond simple geospatial containment relationships and achieve precise model addressing based on the logical identity and visual hierarchy of scene objects.

[0039] To achieve the above matching, a key distance parameter needs to be calculated for each scene object within the target scene block: the object viewing distance from the virtual camera to that scene object. The calculation basis for the object viewing distance is similar to that of the scene viewing distance, both stemming from the real-time spatial position of the virtual camera. During calculation, a spatial reference point of the scene object itself can be selected, such as its geometric center, the center point of its axially aligned bounding box, or a preset anchor point, as the endpoint for distance calculation. Subsequently, the Euclidean distance between the current position of the virtual camera and this reference point is solved, and the result is the object viewing distance. Unlike the scene viewing distance, which serves block-level loading decisions, the object viewing distance is used for object-level rendering detail selection, allowing for a more focused calculation frequency and scope. In one embodiment, the object viewing distance can be calculated only for scene objects currently within the virtual camera's view frustum clipping range, thus avoiding unnecessary calculations for invisible objects.

[0040] After obtaining the object's viewing distance, the detail model mapping table is queried to determine the model that should be invoked for the scene object. The query process uses the scene object's unique identifier as the key. The detail model mapping table returns a series of data items associated with the scene object, indicating the specific model resources corresponding to the scene object at different viewing levels. These model resources can be independent copies of the scene object, or aggregated models of specific scene blocks to which its visual content is merged or simplified at different distance levels. Therefore, the mapping table essentially returns a set of mapping relationships, indicating which L0, L1, or L2 scene block model contains the object's visual form at distance levels L0, L1, and L2.

[0041] When determining the model to be invoked, the calculated object observation distance is compared with the upper limit of the distance ladder to determine the specific distance ladder level to which the object observation distance currently falls. Then, the model reference corresponding to that falling distance ladder level from the aforementioned mapping query results is determined as the target model to be invoked. For example, referencing again... Figure 3The example shown assumes a scene object belonging to the L1 distance tier, with a calculated viewing distance of 400 meters. This distance is greater than the L0 distance limit of 100 meters but less than or equal to the L1 distance limit of 500 meters, therefore it is determined to fall into the L1 distance tier. By querying the detailed model mapping table, it is found that the model content of this object at the L1 level is merged into the aggregate model of an L1 scene block identified as "Block_L1_A". If this "Block_L1_A" block has been loaded in step S3300, then it can be determined that the corresponding model of the scene object in this scene block will be called to render this scene object.

[0042] Once the model is determined, the graphics application interface (API) binds the called model data to the rendering pipeline, including submitting its geometric mesh, associated texture and material parameters, and issuing drawing commands. When rendering scene objects, the model of that scene object in the corresponding target scene chunk can be called and drawn independently. In some embodiments, since the aggregated model of a scene chunk often contains simplified models of multiple spatially adjacent scene objects, a single drawing call can also be applied to the entire aggregated model of the entire scene chunk to present the aggregated appearance of multiple scene objects. Compared to submitting drawing commands separately for each object, this significantly reduces the communication overhead between the central processing unit and the graphics processing unit and the number of graphics interface calls, thereby improving rendering efficiency. For the same area, when the player observes from a distance, the low-detail L2 chunk model covering that area is rendered; as the player gradually approaches, it can automatically switch to rendering the more detailed L1 chunk model, and finally render the L0 chunk content composed of independent high-precision models at very close range, or directly render the original high-precision object model that has not been merged. The detail model mapping table ensures that each scene object is mapped to the correct, loaded detail level model throughout the continuous change of viewing distance, achieving a seamless transition in visual representation.

[0043] The matching and invocation logic described above has several implementable variations to adapt to different runtime requirements and robustness needs. In one embodiment, a direct matching strategy is employed, which strictly follows the distance tier that the object's observation distance falls into to call the corresponding model in the mapping table. If the model is unavailable due to loading failure of its scene chunk, loading delay, or incomplete loading, a fallback strategy can be executed. One fallback method is to query the mapping table and attempt to use a model mapped at a more distant distance tier. This model is typically coarser in detail, but because its chunk has a larger streaming distance, it is more likely to have already been loaded. Another fallback method is to temporarily use a globally unified, minimalist placeholder model until the target model is ready to load. These strategies ensure that the rendering system remains stable even when resource streaming experiences momentary fluctuations, avoiding rendering errors or program interruptions caused by the absence of a single model.

[0044] Furthermore, dynamically changing scenes, such as dynamic scene objects newly created and added during game runtime, also require handling. In one embodiment, the visible distance of a dynamic scene object is calculated or specified based on its geometric properties upon creation, and its corresponding distance tier and scene block are dynamically determined accordingly. The game program can generate an adapted model for this object and register and update it in the detail model mapping table, enabling it to be correctly indexed by subsequent rendering query processes. This allows the rendering control method of this application to efficiently handle both pre-processed static scene objects and dynamically generated scene objects at runtime.

[0045] As can be seen from the above embodiments, this application fundamentally revolutionizes the streaming loading and rendering paradigm for large-scale game scenes. This application abandons the traditional approach of setting a single, fixed loading threshold for the entire geographical area, replacing it with a refined, multi-layered scene block data system automatically constructed based on the visual attributes (visible distance) of scene objects, along with its corresponding runtime scheduling logic. During game runtime, the client does not determine whether the virtual camera is close to a general area, but continuously calculates the scene observation distance from the camera to each specific scene block and compares it with the personalized streaming distance preset for that block, thereby independently and accurately triggering the loading of each block. During rendering, the detailed model mapping table is queried to dynamically match and call the model in the loaded block that is adapted to the current object's observation distance for each scene object. Therefore, this application effectively overcomes the inherent defects of traditional streaming loading schemes, bringing a series of significant technical advantages, including but not limited to: First, this application achieves a fundamental leap in loading decision granularity and scheduling precision, significantly optimizing the efficiency of memory and I / O resource utilization. Traditional solutions use the entire scene block as the smallest indivisible loading unit, resulting in a single loading operation having to include all objects with vastly different visual distances within that block, leading to significant memory waste and redundant I / O. This application refines the smallest physical unit of loading and unloading into scene blocks, with multiple blocks corresponding to different viewing distances (distance tiers) existing within the same spatial range. This allows the game program to set a larger streaming distance for distant tier blocks containing far-view objects, achieving pre-loading; while setting a smaller streaming distance for near-view tier blocks containing close-view objects, achieving precise delayed loading. This independent scheduling based on block visual hierarchy completely solves the dilemma in traditional technologies where a single threshold compromise leads to visual voids caused by loading far-view objects too late or resource waste by loading close-view objects too early. The amount of data loaded becomes highly focused, closely matching the player's real-time visual needs, thereby significantly reducing peak memory usage and average usage time, and significantly smoothing the I / O load of the storage system, avoiding sudden bandwidth pressure.

[0046] Secondly, while ensuring visual continuity and high image quality, this application optimizes rendering performance through intelligent model matching and an efficient rendering submission mechanism. During the rendering phase, instead of simply rendering all the original models within the loaded blocks, this application introduces a detail model mapping table data structure. Based on the real-time object viewing distance from the virtual camera to each scene object, this mapping table is consulted to quickly and accurately determine the appropriate, loaded, and compatible model to be invoked. This ensures that scene objects are rendered at the most suitable level of visual detail at any viewing distance: at extremely far distances, a highly simplified distant block aggregation model is invoked to outline the macroscopic contours with extremely low geometric complexity; at medium distances, a medium-detail mid-range block model is switched to; and at extremely close distances, a high-precision close-up block model or an independent object model is rendered. This dynamic and seamless model switching completely avoids abrupt screen pop-ups or missing objects caused by unprepared resources. More importantly, since a scene-block model (especially a mid-to-far view aggregation model) often integrates the simplified forms of multiple spatially adjacent objects, a large number of objects can be rendered in a single drawing call. This greatly reduces the overhead of drawing command submission and the number of state switching between the central processing unit and the graphics processing unit, thereby significantly improving the overall rendering frame rate and running smoothness while maintaining high visual fidelity.

[0047] Furthermore, this application constructs a complete and standardized technical pipeline from automated preprocessing to adaptive runtime, significantly improving the standardization and maintainability of large-scale game content production. The construction of scene chunks, the division of distance tiers, the calculation of streaming distance, the generation of adaptation models, and the establishment of detailed model mapping tables all originate from the automated analysis (e.g., calculating visible distance based on bounding boxes and projection formulas) and processing (e.g., iterative geometric merging and simplification) of the original scene map data. This forms a highly automated, batch-executable preprocessing pipeline. This pipeline completely changes the inefficient and error-prone mode of traditional development, which relies on manual experience to set parameters for massive objects and regions, and to create and associate multi-level detailed models. By scientifically associating key scheduling parameters (e.g., streaming distance) with the inherent visual attributes (visible distance) of objects and solidifying them in structured resource packages, this application ensures high consistency and predictability of runtime behavior globally. This not only greatly liberates developer productivity and reduces the risk of human error, but also provides a solid, reliable, and efficient technical foundation for the construction, iteration, and continuous performance optimization of ultra-large-scale open-world games.

[0048] Based on any embodiment of the method in this application, querying the detailed model mapping table to determine the model that the scene object should call includes: Step S3310: Obtain from the detailed model mapping table multiple candidate models associated with the scene object and their respective effective distance tiers; During the game's runtime rendering process, determining the model to be invoked for scene objects within the loaded target scene chunks involves querying and utilizing a pre-defined detail model mapping table in the scene resource package. This detail model mapping table, acting as a pre-defined query index, records the mapping relationship between the unique identifier of each scene object within the scene map and a set of model references. Each model reference is explicitly associated with an effective distance tier. This effective distance tier indicates that when the virtual camera's viewing distance from the scene object falls within the distance range defined by this tier, the associated model is the candidate model to be invoked. These candidate models are not necessarily independent copies of the scene object; in one embodiment, they can be aggregated models of scene chunks at different distance tiers, to which the scene object's visual content has been merged after preprocessing.

[0049] The first step in determining the model to be invoked for a scene object is to retrieve all candidate model information associated with it from the detail model mapping table based on the scene object's unique identifier. In one specific embodiment, the detail model mapping table can be organized using a key-value pair data structure, where the key is the scene object identifier and the value is a list or array. Each element in the list contains a model resource identifier (such as a file path, memory address, or resource handle) and an identifier that explicitly indicates its effective distance level (such as "L0", "L1", "L2"). During a query, using the scene object identifier as input, an efficient lookup operation is performed to return all candidate models corresponding to that object and their effective distance level information. The obtained information constitutes the set of models that the current scene object can select during rendering.

[0050] Step S3320: Match the distance tier into which the object's observation distance falls with the distance tiers where each candidate model is effective, and determine the candidate model associated with the successfully matched distance tier as the model that the scene object should currently call.

[0051] After obtaining the candidate model set, a matching decision needs to be made to select the unique target model suitable for rendering the current frame. The matching benchmark is the real-time object observation distance from the virtual camera to the scene object. The calculated object observation distance is compared sequentially with the upper limit of each preset distance tier to determine which distance tier the object observation distance falls into. For example, using the example set earlier, if the object observation distance is 400 meters, and the upper limits of distance tiers L0, L1, and L2 are 100 meters, 500 meters, and 2000 meters respectively, then by comparison, 400 meters is greater than the upper limit of L0 (100 meters) and less than or equal to the upper limit of L1 (500 meters), so it is determined that it falls into distance tier L1. After determining the falling distance tier, the candidate model list obtained from the detail model mapping table is traversed, and the effective distance tier identifier associated with each candidate model is precisely matched with the currently determined falling tier identifier. The matching operation can use simple string or enumeration value comparison. In one embodiment, when the first candidate model whose effective distance tier identifier completely matches the falling tier identifier is found, the matching is successful, and this model is determined to be the model that the current scene object should call. In another embodiment that considers model availability, the matching logic can also perform secondary verification based on the actual loading state of the model, but the core tier matching principle remains unchanged.

[0052] The above embodiment, from retrieving the candidate set from the mapping table to determining the final model based on distance matching, constitutes a clear and repeatable model selection mechanism. This mechanism precisely binds the visual representation of scene objects at different viewing distances to pre-computed and optimized model resources. This allows the rendering system to break free from direct dependence on the original high-poly model of the scene object, and in most viewing situations, especially at medium to long distances, instead call the small-data-volume, high-rendering-efficiency block aggregation model. Simultaneously, because the matching decision is strictly based on real-time spatial distance calculation, it can seamlessly respond to any movement of the player (virtual camera), achieving smooth, automatic transitions at the model detail level and avoiding visual abrupt changes. By transforming complex model selection logic into efficient data table queries and simple numerical comparisons, this embodiment achieves an intelligent balance between rendering accuracy and performance with extremely low runtime overhead.

[0053] Based on any embodiment of the method in this application, the candidate model associated with the successfully matched distance tier is determined as the model that should be invoked by the scene object, including: Step S3311: The model in the detail model mapping table that is directly associated with the distance ladder to which the object's observation distance falls is taken as the first candidate model; Building upon the direct matching process for determining the model to be invoked for a scene object, this embodiment further introduces a more robust model determination strategy that includes availability checks and fallback mechanisms. This strategy recognizes that in complex game runtime environments, the theoretically optimal model to be invoked (i.e., the model directly related to the object's viewing distance falling within a tier) may be temporarily unavailable for rendering due to its scene chunk still loading, loading failure, or other resource management strategies. To maintain rendering stability and visual continuity even under instantaneous fluctuations or anomalies in resource streaming, this embodiment further provides a layered model determination logic.

[0054] The first step of this strategy is to directly locate and retrieve the associated model reference from the detail model mapping table based on the distance tier to which the object's viewing distance falls. This model is defined as the first candidate model. In one specific implementation, after matching the object's viewing distance with the distance tier, the corresponding model resource handle is immediately searched in the candidate model list previously obtained for the current scene object, using the identifier of the successfully matched distance tier as an index. This model represents, ideally, the most suitable level of visual detail prepared for the current viewing distance. However, retrieving the model reference only indicates that the model should logically be used; it does not guarantee that its data is ready.

[0055] Step S3312: Determine whether the first candidate model has been loaded into memory along with its scene block and is available. If the first candidate model is available, determine it as the model that the scene object should currently call. Therefore, an availability check is then performed, which checks whether the first candidate model has been successfully loaded into volatile memory (such as system memory or dedicated video memory of the graphics processing unit) and is in a state that is safe for the rendering pipeline to access. In one embodiment, this can be achieved by checking the loading status flag of the scene chunk associated with the model. If the scene chunk is in a loaded state, the model it contains is considered available. In another, more refined embodiment, an independent availability flag can be maintained for each model resource, which is set after the model data has been decoded, uploaded to the graphics processor memory, and all initializations have been completed. During the check, if the first candidate model is detected to be available, it is immediately identified as the final model that the scene object should call in the current frame, and preparations are made to submit it for rendering. This process achieves optimal path selection when resources are ready.

[0056] Step S3313: If the first candidate model is unavailable, then search the detail model mapping table for other candidate models that are associated with the scene object and have been loaded and are available, use them as fallback models and determine which model to call.

[0057] If the first candidate model is found to be unavailable, a fallback search process is initiated. The goal is to find a currently loaded and usable alternative model (the fallback model) among other candidate models associated with the scene object, as recorded in the detail model mapping table. In one embodiment, the fallback search follows a preset priority order; for example, it prioritizes searching for models associated with stages farther away in the staircase sequence than the stage to which the first candidate model belongs. This is because models at more distant stages are usually associated with scene chunks with larger streaming distances, and these chunks have a higher probability of being loaded due to earlier loading triggers. The search iterates through the candidate model list, skipping the first candidate model, and sequentially checks the availability status of the scene chunks or the model itself associated with each of the remaining candidate models. Once a usable model is found, the search terminates, and that model is designated as the fallback model for current rendering. In another embodiment, the fallback strategy may not strictly follow the distance order, but rather be based on a predefined fallback priority list that comprehensively considers model quality and loading probability. Once the fallback model is determined, it is used for rendering to ensure that the visual presentation is not interrupted due to the absence of a single model.

[0058] The above embodiments significantly enhance the robustness and fault tolerance of the entire rendering system under real-world runtime conditions such as asynchronous loading, network latency, or instantaneous performance pressure. By systematically downgrading to a usable, visually acceptable alternative model when the ideal model is unavailable, rendering errors, object disappearances, or program crashes caused by resource loading timing issues are fundamentally eliminated, ensuring the basic stability of the game experience. Simultaneously, falling back to a loaded model (usually a coarser model) instead of waiting or blocking perfectly aligns with the stringent requirements of determinism and low latency for real-time rendering, ensuring smooth frame rates. This mechanism, combined with the aforementioned fine-grained loading scheduling and detailed model mapping query, constitutes a complete and robust streaming rendering solution that provides optimal visual accuracy and performance under normal conditions while maintaining stable system operation under abnormal boundary conditions. This reliably achieves a high-order balance between memory efficiency, rendering performance, and visual quality in complex real-world application environments.

[0059] Based on any embodiment of the method in this application, after determining and loading the target scene block and its associated model from the multi-layer scene blocks according to the comparison result between the scene observation distance and the streaming distance of each scene block, the method includes: Step S4100: In response to the object creation event of the dynamic scene object, determine its visible distance based on the geometric dimensions of the dynamic scene object; During game runtime, new scene objects are often dynamically created, such as non-player character generation triggered by game logic, visual effects generated by player skills, or dynamic fragments simulated by the physics system. These dynamic scene objects are not included in the pre-baked scene resource package. If they are not incorporated into the unified management system of this application, their rendering scheduling will become disconnected from static objects, potentially causing local performance fluctuations or visual inconsistencies. This embodiment aims to solve this problem by providing an automated integration process for dynamic scene objects, ensuring that all visual content in the game world follows the same set of scientific management rules based on distance and visual importance.

[0060] Specifically, this embodiment responds to object creation events of dynamic scene objects. Object creation events can be triggered by various game runtime logics, including but not limited to function calls in game scripts, instantiation instructions from resource management systems, the fulfillment of conditions in specific game states, or network synchronization events. Once such an event occurs, the integration process of this embodiment is initiated. The first step of the process is to determine the visible distance of the dynamic scene object based on its geometric dimensions. The visible distance characterizes the theoretical furthest distance at which the object can be effectively recognized on the screen and is a key basis for determining its corresponding visual hierarchy (distance tier).

[0061] The parameters and methods used for calculating the visible distance can be consistent with those used for static scene objects in the scene resource package during the preprocessing stage to ensure standardization. In one embodiment, the bounding box size of the dynamic scene object in the game world coordinate system can be obtained. If the model of the dynamic scene object is fully loaded in the frame of its creation, its axially aligned bounding box can be calculated immediately, and its maximum axial dimension (the maximum value of length, width, and height) can be taken as a representative size. In another embodiment where the initial state of the object may be incomplete, the calculation can be delayed for several frames until the model resources of the dynamic scene object are fully loaded and the spatial transformation is stable, to ensure the accuracy of the size data. After obtaining the size, it is substituted into a preset geometric projection formula along with a preset minimum screen space ratio parameter and the field of view parameter of the current virtual camera (or a preset standard reference camera for calculation). This geometric projection formula establishes a mathematical relationship between the object size, screen pixel ratio, camera field of view, and theoretical maximum visible distance; its specific form can be derived based on the principle of perspective projection. For example, one implementation formula is: Visible distance D = (scene object bounding box size) / (2 * k * tan(FOV / 2)), where k is the linearized screen space occupancy threshold, and FOV is the vertical field of view. This calculation assigns a quantified visual importance metric to dynamic scene objects.

[0062] Step S4200: Based on the visible distance, determine the target distance tier and the corresponding target scene block to which the dynamic scene object belongs; After determining the visible distance of a dynamic scene object, the target distance tier and corresponding target scene block to which the dynamic scene object belongs are determined based on this calculated visible distance. The determination logic involves comparing the visible distance of the dynamic scene object with the upper limit of each distance tier preset and fixed within the scene resource package during the preprocessing stage. In one embodiment, a sequential traversal or binary search algorithm is used to find the first tier in the distance tier sequence (e.g., L0, L1, L2, ...) whose upper limit is greater than or equal to the visible distance of the dynamic scene object. This tier is then determined as the target distance tier to which the dynamic scene object belongs. Simultaneously, the target scene block corresponding to this target distance tier and the current position of the dynamic scene object needs to be determined. This can be done by querying the spatial index structure recorded in the scene resource package, locating the specific scene block where the dynamic scene object's position falls within the target distance tier based on its spatial location at the time of creation. This block is the target scene block that the dynamic scene object should currently be associated with.

[0063] Step S4300: Generate a model adapted to the target distance tier for the dynamic scene object, add the model to the model associated with the target scene block, and update the detail model mapping table synchronously.

[0064] Once the attribution relationship is determined, a model adapted to the target distance tier can be generated for the dynamic scene object, and this model can be added to the model associated with the target scene block, while simultaneously updating the detail model mapping table. Generating an adapted model means creating or specifying a model that matches the target distance tier requirement at the level of visual detail. In one embodiment, the original high-precision model that comes with the dynamic scene object when it is instantiated can be directly used as the model adapted to the nearest distance tier (highest detail). For medium to long distance tiers, a mesh simplification algorithm needs to be called at runtime to simplify the original model in real time based on the visual detail level requirements corresponding to the target distance tier (e.g., the number of target triangles or screen error threshold), generating a simplified version of the model. In another embodiment that focuses on runtime performance, several sets of models with different levels of detail can be pre-made for common types of dynamic scene objects (such as a certain type of monster or special effect). In this case, generating an adapted model becomes selecting the version with the corresponding precision from the pre-made multi-level models based on the target distance tier.

[0065] After generating the model, an addition operation needs to be performed. This addition mainly refers to logical association and data integration, rather than direct geometric merging of already loaded model data. The game program registers the unique identifier of the dynamic scene object and the reference to its generated adaptable model in the management data structure of the associated target scene block, so that the block can be aware of this new object in subsequent scheduling and rendering logic. At the same time, the detail model mapping table is updated synchronously. The update operation includes adding a record to the detail model mapping table or modifying an existing record by appending, to establish the mapping relationship between the identifier of the dynamic scene object and the model associated with it at the target distance level (i.e., the model that has been added to the target scene block). This ensures that the subsequent rendering process can correctly find and call the adaptable model for this dynamic scene object when querying the detail model mapping table.

[0066] The dynamic scene object integration mechanism described in the above embodiments seamlessly extends this application from optimizing static, pre-baked content to the unified management of runtime dynamically generated content. It ensures that all visual entities in the game world, whether pre-placed or generated in real-time, can be automatically and consistently incorporated into the same refined management and scheduling system based on visible distance, distance tiers, and multi-layered scene segmentation. This eliminates the control gap between static content streaming optimization and dynamic game logic, enabling the maintenance of stable overall rendering performance and high consistency in visual presentation even in complex game environments containing numerous real-time events, interactions, and generated content. This is a key manifestation of the completeness and practicality of the method in this application.

[0067] Based on any embodiment of the method in this application, according to the comparison result between the scene observation distance and the streaming distance of each scene block, the target scene block and its associated model are determined and loaded from the multi-layer scene blocks, including: Step S3210: For all scene blocks that satisfy the condition that the scene observation distance is less than or equal to their streaming distance, determine the ratio of the scene observation distance to the streaming distance; During game runtime, especially when the player moves or turns quickly, multiple scene chunks may simultaneously meet the loading conditions. Loading all target chunks concurrently without differentiation could instantly exhaust input / output bandwidth and memory, leading to loading delays. Furthermore, resource contention could cause the most urgently needed chunks to load slowly. This embodiment aims to optimize this concurrent loading process by intelligently prioritizing loading tasks, ensuring that limited system resources are used to serve the scene chunks most critical to the current visual experience. This further improves the smoothness of the loading process and the user experience, building upon the already implemented refined loading decisions.

[0068] Specifically, firstly, for all scene segments where the scene observation distance is less than or equal to their streaming distance, the ratio of the scene observation distance to the streaming distance is determined. This condition is a logical prerequisite for a scene segment to enter the loading state. When calculating the ratio, the precisely calculated scene observation distance from the virtual camera to the scene segment is used as the numerator, and the preset streaming distance of the scene segment is used as the denominator, and a division operation is performed. This ratio has a clear physical meaning; it quantifies the proximity or urgency of the virtual camera's current position relative to the loading trigger boundary of the scene segment. The closer the ratio is to 0, the deeper the virtual camera's position is into the loading influence range of the segment, and the more urgent the need for the visual content managed by the segment to become visible to the player or to require higher detail rendering. Conversely, the larger the ratio (maximum 1), the more the virtual camera has just touched the loading boundary, and the relatively lower the urgency. In one embodiment, this ratio is calculated as a floating-point number between 0 and 1. In another embodiment, for the edge case where the scene observation distance is exactly equal to the streaming distance, the ratio is counted as 1 to clearly indicate that it is at the outermost edge of the loading trigger.

[0069] Step S3220: Based on the ratio, set the loading priority for each scene block; the smaller the ratio, the higher the priority. After obtaining the urgency ratio of each candidate scene chunk, a loading priority is assigned to each scene chunk based on the magnitude of the ratio. The principle is that the smaller the ratio, the higher the priority. This ensures that scene chunks where players have already entered their loading range and whose content is almost certain to be seen in the next moment receive the highest priority loading rights. In one embodiment, the priority is directly quantified as a value negatively correlated with the ratio, for example, priority score = 1 - ratio. In another embodiment, a continuous range of ratios is mapped to several discrete priority levels, for example, chunks with ratios in the range [0, 0.3) are set as "urgent" priority, those in the range [0.3, 0.7) are set as "high" priority, and those in the range [0.7, 1.0] are set as "medium" priority.

[0070] The loading priority setting can also take into account other factors. In one embodiment, when the ratios are the same or similar, the distance tier to which the scene block belongs can be further considered, and blocks with closer distance tiers can be given a fine-tuned higher priority, because they contain models with higher details and have a greater impact on image quality.

[0071] Step S3230: According to the loading priority from high to low, add the model data of each scene block to the asynchronous loading queue in sequence and execute the loading.

[0072] After setting clear loading priorities, the model data of each scene block is added to the asynchronous loading queue and loaded sequentially according to the loading priority from high to low. The asynchronous loading queue is a data structure that manages resource loading tasks in the background. Each scene block to be loaded is encapsulated as a loading task descriptor, which contains the resource identifier of the block in the scene resource package, its associated model data path, a callback function pointer after loading is complete, and its calculated priority flag. Subsequently, these task descriptors are inserted into the asynchronous loading queue in strict order of priority from high to low.

[0073] In one embodiment of a multi-threaded architecture, the main logic thread is responsible for computation and task encapsulation, while one or more independent resource loading threads continuously retrieve tasks from the head of the queue for execution. The loading and execution process includes reading compressed model data blocks from storage devices, decompressing them in memory, decoding geometry and texture data, uploading them to GPU-accessible video memory, and finally initializing the rendering state. High-priority tasks, due to their earlier position in the queue, are prioritized and processed by the loading threads, ensuring that their model data can be loaded and ready as quickly as possible. Once a chunk of model data has been loaded, the loading thread notifies the main rendering thread that the chunk has become loaded and is available for use by the rendering pipeline via a callback mechanism or by updating shared state variables.

[0074] The priority loading mechanism based on urgency ratio disclosed in the above embodiments elevates the streaming loading process of this application from a simple condition-based loading to an intelligent and predictable resource scheduling strategy. By quantifying spatial proximity into comparable priority values ​​and strictly enforcing an execution order based on these priorities in concurrent loading scenarios, it ensures that the player's visual focus area always receives the fastest resource supply when system input / output resources are limited. This significantly reduces the slow loading or stuttering of critical scene content directly in front of the player due to resource contention, making the scene flow smoother, more immediate, and less noticeable to the player. Combined with a multi-layered scene segmentation structure, this mechanism enables the entire streaming loading system to not only know what to load (by comparing distance and streaming distance) but also which loading order is most efficient (by priority sorting). This maximizes memory and input / output bandwidth utilization in complex open-world dynamic exploration and provides underlying resource guarantees for a stable, high-frame-rate gaming experience.

[0075] Based on any embodiment of the method in this application, after determining and loading the target scene block and its associated model from the multi-layer scene blocks according to the comparison result between the scene observation distance and the streaming distance of each scene block, the method includes: Step S5100: For each loaded scene block, continuously determine whether its scene observation distance exceeds the preset unloading distance for that scene block, wherein the unloading distance is greater than the streaming distance of that scene block; Timely resource unloading is just as important as efficient loading. An inappropriate unloading strategy can lead to two adverse consequences: first, scene chunks that are no longer in the player's view continue to occupy valuable memory and video memory, causing memory pressure and affecting the loading of new resources; second, unloading triggers are too sensitive, causing frequent loading and unloading of the same scene chunk when the virtual camera makes slight back-and-forth movements near the loading boundary, resulting in significant performance jitter and wasted input / output, the so-called resource jitter phenomenon. This embodiment introduces an unloading decision mechanism with hysteresis characteristics to achieve stable and smooth reclamation of memory resources, ensuring the robust performance of the game over long periods.

[0076] Specifically, for each loaded scene block, the scene observation distance can be continuously checked to see if it exceeds the preset unloading distance for that scene block. Here, the unloading distance is a safety distance threshold, independent of the streaming distance, specifically used to trigger unloading behavior. The unloading distance is greater than the streaming distance of the scene block to create a buffer or hysteresis interval between the loading and unloading boundaries to maintain loading. In one embodiment, the unloading distance can be calculated by multiplying the streaming distance by an unloading hysteresis coefficient greater than 1.0, for example, unloading distance = streaming distance * 1.5. In another embodiment, the unloading distance can be set to the streaming distance plus a fixed distance constant.

[0077] During game runtime, the latest scene observation distance from the virtual camera to each loaded scene tile is continuously calculated. For each loaded tile, this latest scene observation distance is compared with the preset unloading distance for that scene tile. The decision logic is to check whether the latest scene observation distance exceeds the unloading distance, i.e., whether it is greater than the unloading distance. Only when the virtual camera moves away from the scene tile and crosses this farther, safer unloading boundary is it considered that the visual content contained in that tile is no longer needed in the foreseeable future (at least the time required for the camera to move back to the buffer), and thus it can be safely considered for unloading.

[0078] Step S5200: Divide the scenes whose observation distance has exceeded their unloading distance into blocks and add them to the unloading list; When it is determined that the scene observation distance of a loaded scene chunk has exceeded its unloading distance, the scene chunk is immediately added to the unloading list. The unloading list is a data structure maintained in memory, used to centrally manage all scene chunks that have been marked as unloadingable but have not yet undergone actual resource release operations. Adding chunks directly to the list instead of immediately unloading them has several advantages. First, it decouples the unloading decision (a lightweight logical judgment) from the unloading execution (a relatively heavyweight operation that may involve complex resource unbinding and memory reclamation). This allows the unloading decision to be completed efficiently in the main logic thread without causing stuttering due to synchronous unloading operations. Second, the list provides a buffer, allowing for batch processing, priority sorting, or centralized scheduling of unloading operations within a specific time window before final execution. In one embodiment, the unloading list is a simple first-in-first-out queue, with chunks waiting for processing in the order they were added. In another, more complex embodiment, the list can be a priority queue, where the unloading priority can be set based on factors such as chunk size, distance tier, or memory usage, to ensure that the unloading of large or critical chunks is handled more prudently or delayed.

[0079] Step S5300: Schedule resource reclamation tasks to release the memory resources occupied by each scene block in the list to be unloaded.

[0080] Finally, by scheduling resource reclamation tasks, the memory resources occupied by each scene block in the unloading list are released. Scheduling refers to selecting the appropriate time and method to execute the actual resource release operation. In one embodiment, resource reclamation is handled by a separate, low-priority background thread. This thread is periodically woken up to check the unloading list. If the list is not empty, one or more block identifiers are retrieved from the list, and the unloading process is executed sequentially. The unloading process includes: disconnecting all bindings between the model associated with the scene block and the graphics rendering pipeline (such as removing the corresponding node from the scene graph and unregistering the rendering instance), releasing the graphics processor memory and system memory occupied by the model, updating the status of the scene block to "unloaded", and removing its reference from the internally managed list of loaded blocks. In another embodiment, the resource reclamation task can be bound to the main loop frame of the game. For example, during the idle time period after each frame's rendering submission is completed, a fixed number (e.g., a maximum of 5 per frame) of unloading list items are processed, thereby evenly distributing the performance overhead of unloading across multiple frames and avoiding significant performance spikes within a single frame. In this way, the resources occupied by the marked blocks can be safely and orderly released back to the system, freeing up the necessary memory space for subsequent possible new block loading requests.

[0081] The delayed unloading mechanism based on independent unloading distance disclosed in the above embodiments creates a stable loading state interval for each loaded scene block by setting an unloading safety boundary farther than the loading trigger point. This fundamentally eliminates the frequent loading and unloading jitter of resources caused by the slight movement of the virtual camera near the streaming distance threshold, ensuring the effectiveness of loading decisions and the stability of system input and output. Combined with the preceding fine-grained loading strategy, this embodiment enables the memory usage of the entire game client to dynamically expand and contract closely and smoothly with the player's exploration trajectory: when the player enters a new area, adjacent blocks are loaded first; when the player moves away from the old area, the corresponding blocks are steadily recycled after crossing the safety boundary. This mechanism not only significantly improves the long-term stability and efficiency of memory usage, but also provides a solid guarantee for the long-term stable operation of the game in complex movement modes, enabling the streaming rendering system of large-scale scenes to have high robustness and predictability while pursuing high performance.

[0082] Based on any embodiment of the method in this application, before determining and loading the target scene block and its associated model from the multi-layer scene blocks according to the comparison result between the scene observation distance and the streaming distance of each scene block, the method includes: Step S2100: Read the default streaming distance predefined for each scene block in the scene resource package. The default streaming distance is set based on the maximum visible distance among all scene objects contained in the scene block. The default streaming distance set for each scene chunk during the preprocessing stage, while scientifically calculated based on the visual attributes of its internal scene objects, is static and sometimes unable to flexibly adapt to changes in hardware performance, player preferences, or real-time system load. Using this default value directly may not fully realize its potential to provide a wider field of view on high-performance devices, while on low-performance devices it may cause memory and I / O pressure due to excessive loading range. Therefore, a unified adjustment mechanism can be introduced at runtime to dynamically transform the static default parameters into effective parameters adapted to the current operating environment, thereby improving the universality and adaptability of this solution.

[0083] Specifically, the system first reads the predefined default streaming distance for each scene block from the scene resource package. This default streaming distance is an important component of the scene resource package metadata and is set during the preprocessing stage based on the maximum visible distance among all scene objects contained within the scene block. The setting rule is conservative, ensuring that any object within the block (even the one with the furthest visible distance) is loaded before its block becomes theoretically visible. The read operation occurs after the client successfully loads and parses the scene resource package. The system traverses all scene block metadata defined in the resource package, extracts the default streaming distance value associated with each block identifier, and stores this mapping relationship in a data structure in memory for subsequent calculation and comparison. These default values ​​form the baseline for loading decisions.

[0084] Step S2200: Multiply the determined global scaling factor by the default streaming distance of each scene block to obtain the effective streaming distance currently in effect for each scene block; After obtaining the default streaming distance baseline values ​​for all scene chunks, it is necessary to calculate the threshold at which they take effect during actual runtime. To this end, this step multiplies the determined global scaling factor by the default streaming distance of each scene chunk to obtain the currently effective streaming distance for each scene chunk. The global scaling factor is a single scalar value that is dynamically determined at runtime, and it applies to all scene chunks to achieve global and consistent adjustment of loading behavior. In one embodiment, the global scaling factor can be actively set by the player through the game settings interface, such as a "view distance" or "detail distance" slider, with a value range, for example, between 0.5 and 2.0, allowing the player to intuitively weigh performance against visual range. In another embodiment that emphasizes adaptation, the global scaling factor can be automatically calculated and dynamically adjusted by the game engine based on real-time monitored performance metrics (such as frame rate and memory usage). When performance is below the target threshold, the factor is reduced to shrink the loading range; when performance is sufficient, the factor is increased to expand the view. Multiplication is simple and efficient. It combines the personalized visual requirements of each scene block (reflected by the default streaming distance) with the current global running strategy (reflected by the global scaling factor) to produce an adaptive trigger threshold for each block.

[0085] Step S2300: Compare the scene observation distance with the effective transmission distance to determine the corresponding comparison result.

[0086] After determining the effective streaming distance currently in effect for each scene block, the final step is to compare the scene observation distance with the effective streaming distance to determine the corresponding comparison result. This comparison serves as the logical input for the loading decision in step S3300. When executing the loading decision loop, the game program no longer uses the static default streaming distance but instead uses the effective streaming distance adjusted by global scaling. For each scene block, the calculated real-time scene observation distance from the virtual camera to that block is numerically compared with the effective streaming distance calculated for that block. The comparison operation typically employs a threshold judgment, i.e., determining whether the scene observation distance is less than or equal to the effective streaming distance. The comparison produces a Boolean result (true or false), which directly determines whether the scene block meets the conditions for being marked as a target scene block in the current frame. In this way, the trigger boundary for loading decisions is no longer fixed but can dynamically scale with changes in the global scaling factor, thereby achieving global control over the aggressiveness of loading.

[0087] The dynamic streaming distance calculation mechanism disclosed in the above embodiments is a key component in achieving cross-platform adaptation and runtime adaptive optimization in this application. It combines statically optimal parameters scientifically preset based on visual attributes with dynamic adjustment factors reflecting real-time environmental conditions to generate an effective decision threshold that is both objectively reasonable and environmentally adaptable. This mechanism enables the same refined streaming loading scheme to seamlessly adapt to devices with different performance levels, from mobile terminals to high-end personal computers. It allows end users to personalize the balance between visual immersion and smooth operation according to their own needs, and also provides a direct control dimension for game clients to achieve closed-loop adaptive optimization based on performance feedback.

[0088] Based on any embodiment of the method in this application, before multiplying the determined global scaling factor by the default streaming distance of each scene block to obtain the currently effective streaming distance of each scene block, the process includes: Step S2310: Monitor the performance metrics of the game in real time, including frame rate and memory usage. Static global scaling factors are difficult to adapt to dynamic changes in hardware load during game operation, such as drastic fluctuations in scene complexity, background tasks competing for resources, or multiple applications running in parallel. If the factor is set too high, it may lead to frame rate drops or memory overflows under performance pressure; if it is set too low, it may not be able to fully utilize hardware capabilities to provide a better visual experience when performance is sufficient. This embodiment aims to achieve automated closed-loop adjustment of the global scaling factor, so that the aggressiveness of the entire streaming loading system can match the actual performance capacity of the current hardware in real time, thereby dynamically optimizing the visual presentation range while ensuring basic operational stability.

[0089] Specifically, the first step is to monitor the game's performance metrics in real time. These metrics are direct quantitative indicators for assessing the system's current load and health. Monitored metrics include, but are not limited to, frame rate and memory usage. Frame rate, typically measured in frames rendered per second, is a core metric for evaluating the smoothness of game interaction. Memory usage reflects the proportion of system physical memory occupied by all game resources, including the loaded scene chunk model managed in this application, and is crucial for assessing resource pressure and potential overflow risks. Monitoring needs to be performed continuously at a certain frequency. In one embodiment, the monitoring logic is integrated at the end of each frame rendering cycle to obtain the most timely performance snapshot. In another embodiment focusing on reducing overhead, a separate timer thread can be used to periodically sample at intervals of tens of milliseconds. The collected raw performance data (such as instantaneous frame time and current memory commits) typically needs to be smoothed, for example, by calculating a moving average, to filter out instantaneous fluctuations and obtain performance trend values ​​that better represent the recent stable state.

[0090] Step S2320: When the frame rate is lower than the first threshold or the memory usage is higher than the second threshold, the global scaling factor is automatically reduced. After obtaining the processed performance metrics, the global scaling factor is adjusted according to preset logical rules. The adjustment decision is divided into two main directions: performance-protective downscaling and experience-enhancing upscaling. The triggering condition for the downscaling operation is relatively direct, aiming to quickly respond to performance degradation. Specifically, when the frame rate is monitored to be lower than a preset first threshold, or the memory usage is monitored to be higher than a preset second threshold, the global scaling factor can be automatically reduced. The first threshold is the minimum acceptable frame rate baseline to ensure smoothness, such as 30 frames per second. The second threshold is a safety line to prevent memory exhaustion, such as 80% of the system's physical memory. Meeting either condition indicates that the system is under significant pressure and needs to shrink the resource loading range to reduce the load. The downscaling operation means reducing the effective streaming distance of all scene chunks, making fewer chunks meet the loading conditions, thereby reducing concurrent loading tasks, lowering the expected future memory usage growth, and reducing pressure on the graphics rendering pipeline. The magnitude of the downscaling can be designed as follows: in one embodiment, a discrete step-down adjustment is used, such as multiplying the current coefficient by 0.8; in another embodiment, a linear proportional downscaling can be performed based on the severity of the performance metrics exceeding the threshold.

[0091] Step S2330: When the frame rate is consistently higher than the third threshold for a preset duration and the memory usage is lower than the fourth threshold, the global scaling factor is automatically increased.

[0092] The triggering conditions for scaling up are more stringent and conservative, aiming to ensure that the experience is gradually improved only when the system performance is truly sufficient and stable. Specifically, when the frame rate is consistently above a third threshold for a preset duration and the memory usage is consistently below a fourth threshold, the global scaling factor is automatically increased. The third threshold is typically higher than the first threshold, representing a good performance standard, such as 60 frames per second. The fourth threshold is lower than the second threshold, representing a state of ample memory, such as 60% memory usage. Furthermore, the sustained preset duration is a crucial prerequisite; for example, it requires that the frame rate and memory usage consistently meet the above conditions for the past 5 seconds. This latency requirement avoids accidental scaling up due to instantaneous performance fluctuations, ensuring the system is in a persistent, stable, high-performance state. When these conditions are simultaneously met, the system automatically increases the global scaling factor. This increase expands the effective streaming distance, allowing more distant scene chunks to be loaded, thereby expanding the player's field of view and reducing loading latency and visual pop-ups for distant content. The scaling factor can also be designed as a step (such as multiplying by 1.1) or a proportional one, and usually an upper limit is set for the global scaling factor to prevent it from growing indefinitely and causing the system to enter a stress state again.

[0093] The performance-adaptive global scaling factor determination mechanism described in the above embodiments directly couples runtime performance feedback with pre-load decision parameters, forming a dynamic adjustment loop. This mechanism transforms the streaming loading system of this application from an open-loop, fixed-parameter solution into an intelligent agent capable of sensing its own operational state and adjusting its behavior. When performance is limited, the system automatically operates conservatively, prioritizing smoothness and stability; when performance is sufficient, it actively maximizes the use of hardware capabilities to enhance the immersive visual experience. This adaptive capability significantly reduces reliance on manual configuration by players, providing an out-of-the-box optimized experience, and ensuring that the system automatically finds and maintains the optimal balance between performance and image quality when applied to hardware devices of different performance levels and when facing dynamic load changes during operation on the same device. This significantly enhances the robustness, universality, and adaptive consistency of the user experience of the entire technical solution in complex deployment environments.

[0094] Based on any embodiment of the method in this application, the scene resource package is generated through the following preprocessing stages, including: Step S1100: For the scene map, based on the visible distance of each scene object, divide each scene object into a corresponding distance tier to form a logical object set for each distance tier; This step involves dividing the scene objects into corresponding distance tiers based on the visible distance of each scene object in the game world's corresponding scene map when creating the scene resource package, thus forming a logical object set for each distance tier.

[0095] The preprocessing of the scene resource package begins with a global analysis of the game world, i.e., the complete scene map. The scene map contains all the basic elements that constitute its visual content, i.e., scene objects. Each scene object is associated with a key visual attribute—visible distance. This distance represents the theoretical furthest distance at which an observer can clearly see the object when its pixel proportion in screen space is below a preset threshold. In preprocessing, a distance hierarchy sequence needs to be preset for the scene map, such as L0, L1, L2, with each hierarchy defining a distance upper limit. For example... Figure 3 As shown, the maximum distances for L0, L1, and L2 can be 100 meters, 500 meters, and 2000 meters, respectively. Next, each scene object in the scene map is traversed, and its visible distance is compared sequentially with the maximum distance for each level. It is then assigned to the first distance level where its visible distance is less than or equal to the maximum distance for that level. For example, a tree with a visible distance of 350 meters is assigned to level L1. All scene objects assigned to the same distance level collectively constitute the logical object set for that level. This logical grouping provides the basis for subsequent spatial organization.

[0096] Step S1200: According to the preset segmentation specifications for each distance level, the area where the logical object set of each distance level is distributed is spatially segmented to form multiple scene blocks under that distance level. Each scene block is associated with the original model of the scene object belonging to this level that falls within its spatial range. Furthermore, according to the preset segmentation specifications for each distance level, the area where the logical object set of each distance level is distributed is spatially segmented to form multiple scene blocks under that distance level. Each scene block is associated with the original model of the scene object belonging to this level that falls within its spatial range.

[0097] After completing the logical grouping, physical management units need to be established for each distance level in the spatial dimension. To this end, each distance level has a preset level division specification, which defines the grid size for spatial division within that level. Generally, the closer the level is to the observation point, the smaller its level division specification, resulting in a finer division; the farther the level is, the larger the specification, resulting in a coarser division. For example... Figure 4As shown, for level L0, a small grid is used to divide the scene into numerous small-sized scene blocks 101; for level L1, a medium grid is used to divide the scene into larger scene blocks 10; and for level L2, a large grid is used to divide the scene into scene blocks 1 covering a wide area. For a certain distance level, the grid defined by its level division specifications is used to uniformly divide the area (usually the entire map) where the logical object set of that level is distributed in the entire scene map, resulting in a series of scene blocks under that level. Subsequently, the logical object set of that level is traversed, and each scene object is assigned to the scene block it falls into based on its spatial location (such as the center point). At this point, each scene block is still associated with the original, high-precision models of those scene objects within its range that belong to this level. The above process completes the transformation from a logical object set to a spatial block organization.

[0098] Step S1300: Generate models for each scene block in each distance step in order from near to far. When generating a model for any scene block, the original model of the scene object that falls within the spatial range of the block and is unique to this step is geometrically merged and simplified with the models generated by all previous distance steps that overlap with the block in space. When generating models for scene objects, the generation of models strictly follows the order of distance from level to level (e.g., L0 -> L1 -> L2). First, the nearest L0 level is processed. For each scene block of L0, its model can directly use the original model set of the associated L0 scene objects within that block, or these original models can be slightly optimized and used as the L0 model. Next, models are generated for the next, more distant L1 level. For a target scene block in L1, its model generation requires combining two parts: first, the original model specific to this level, i.e., the original models of scene objects that were assigned to L1 in step S1100 and fall into this L1 block in step S1200; second, the spatially overlapping preceding level models, i.e., the (optimized) models generated from all L0 scene blocks that overlap with this L1 target block in 3D space. These two parts of model data are logically integrated, and then a degeneracy operation is performed.

[0099] In this application, degeneracy specifically refers to geometric merging and simplification. For example, multiple model meshes are merged into one, and mesh simplification algorithms (such as edge folding) are applied to significantly reduce the number of triangles. Texture downsampling is also performed to ultimately generate a unified, simplified aggregated model as the model for the L1 block. This model visually represents both the newly added L1 object and the simplified form of all L0 objects in that region. This process iterates. When generating a model for the L2 block, all L1 block models that overlap with L2-specific objects (which are already simplified aggregated models themselves) are merged and further simplified. Through this iterative degeneracy, a hierarchical pyramid of detailed models is automatically constructed.

[0100] Step S1400: Construct a scene resource package containing the multi-layer scene blocks, the models generated for each scene block, and the detailed model mapping table that records the mapping relationship between each scene object and the model used in the corresponding scene block at each distance level.

[0101] Finally, all preprocessed outputs are systematically encapsulated. This includes: spatial definitions and metadata (such as center coordinates, size, and streaming distance) for all scene blocks generated for each distance level; simplified model files and associated resources generated for each scene block; and most importantly, a detailed model mapping table. This mapping table records the precise relationships established during the iterative simplification process: that is, for each scene object in the scene map, at each distance level, its visual content is ultimately merged into the simplified model of that specific scene block. For example, a tree object at L1 level is mapped to the model of the "Block_L1_A" block. All this structured metadata and model asset data, after serialization (e.g., conversion to JSON or binary format) and compression, ultimately generates a single, complete scene resource package file. This resource package is the object directly invoked in this application; it carries the rendering and scheduling information of the entire scene map after automated and structured preprocessing, providing a complete data foundation for the client to achieve high-performance, refined streaming rendering.

[0102] The preprocessing process described in the above embodiments systematically solves the key problem of transforming raw, disordered scene data into a structured resource package that can be efficiently invoked at runtime. It constructs an internally unified and hierarchically distinct scene representation system through automated logical layering based on visible distance, spatial block division according to tiered specifications, and iterative degeneracy model generation from near to far. The detail model mapping table produced by this system serves as a bridge connecting preprocessed objects and runtime model calls, allowing runtime rendering to be entirely based on this mapping relationship without needing to concern itself with the complex underlying degeneracy process. This preprocessing workflow transforms the traditionally highly manual and difficult-to-maintain large-scale scene data preparation work into a rule-driven, batch-executable automated pipeline. This not only greatly improves content production efficiency and consistency but also fundamentally provides the necessary and optimized data foundation for runtime to achieve refined streaming loading, visually flawless detail switching, and high-performance aggregate rendering. This is a prerequisite guarantee for the establishment and efficient operation of the overall technical solution of this application.

[0103] Based on any embodiment of the method in this application, for the scene map, according to the visible distance of each scene object therein, each scene object is divided into a corresponding distance tier, forming a logical object set for each distance tier, including: Step S1110: Traverse each visually visible element 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 trunks, branches, and leaves, or a vehicle composed of 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 subsequent streaming scheduling would result in overly fragmented management and potential 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.

[0104] Specifically, the preprocessing flow first traverses all basic visually visible elements within the current scene map. Visually visible elements are the smallest rendering units that constitute the visual 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 relationship between a group of visually visible elements that are tightly bound together 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 (such as 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 usually defined relative to the parent object. Another type of spatial dependency can be determined through predefined grouping labels or physical constraints (such as hinges or 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 flow identifies dependencies by reading this label.

[0105] Step S1120: Pack visually visible elements with spatial dependencies into scene objects corresponding to the same group, and treat visually visible elements without spatial dependencies as scene objects in independent groups. After determining spatial dependencies, the preprocessing flow performs a packaging operation, logically combining a group of visually visible elements with spatial dependencies and defining 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 packaging 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, regardless of the complexity of the original data structure, it is normalized into a set of discrete, logically independent scene objects, each representing a visual entity that should be uniformly processed.

[0106] Step S1130: Determine the visible distance of each scene object, wherein the visible distance is the maximum value among the visible distances of each visually visible element within the scene object.

[0107] 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 as described previously, based on the bounding box of the visually visible element, its screen space occupancy, and the field of view of a standard virtual camera, using a predefined geometric trigonometric function formula. 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 a conservative and reasonable rule, ensuring 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, used for subsequent processing such as dividing distance tiers and generating detailed models.

[0108] 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 (such as visible distance and distance tier division) 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, a conservative and reliable design principle is adhered to, guaranteeing the visual integrity of streaming loading 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.

[0109] Based on any embodiment of the method in this application, determining the visible distance of each scene object includes: Step S1111: 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 element, its spatial bounding box size in the game world coordinate system needs to be obtained. A spatial 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).

[0110] Step S1112: 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.

[0111] Please refer to Figure 5 Similar to the aforementioned setting of the visible distance for dynamic scene objects, a mathematical relationship is established between object size, minimum screen space ratio, field of view, and visible distance through a preset geometric projection formula. Based on the principle of similar triangles, this formula can be expressed as: Visible distance D = (Representative size of scene object) / (2 * k * tan(Standard field of view / 2)). Here, k is the linear screen space 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 linear. When the preset parameter itself is a linear threshold, k can be used directly. The representative size of a scene object usually refers to the projected size of its bounding box in the viewing direction. To simplify the calculation, 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.

[0112] 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.

[0113] Step S1113: 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.

[0114] 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.

[0115] 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 construction but, more importantly, provides solid and reliable input data for all subsequent automated processing (such as distance tier division and streaming distance setting). 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.

[0116] Based on any embodiment of the method in this application, models are generated sequentially for each scene block at each distance level, following the order from near to far distance, including: Step S1210: For the first distance level that is closest, directly determine the original model of the scene object contained in each scene block as the model of the first distance level. Model generation strictly follows the order of distance steps from closest to furthest. The first distance step closest to the observation point, such as L0, is processed first. Since L0 is the closest step and has no preceding distance steps, the basis for generating a model for a scene block within L0 is relatively straightforward. In one implementation, the original models (i.e., their highest-precision, unmerged and unsimplified versions) of the scene objects belonging to the L0 logical object set contained within the scene block can be directly determined as the model corresponding to that L0 block at the first distance step. This means that generating a model for an L0 step essentially establishes a direct association between the scene block and its internal list of original object models. Each L0 scene block possesses a set of high-precision models of its internal original objects. These models will serve as one of the input components when generating a simplified model for the next, more distant distance step.

[0117] Step S1220: 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 the model generated for the previous distance step that overlaps with the scene block in space, and the model of the current distance step is simplified to generate the model of the current distance step. After determining the model for the first distance level (L0), the process enters the iterative phase, starting to generate models for each scene block of the next, more distant distance level (e.g., L1). For a specific target scene block in L1, model generation requires integrating two parts of input. The first part is the original model of the scene objects unique to that target scene block itself—that is, the original models of scene objects that were assigned to the L1 level during preprocessing and fall within the spatial range of this specific L1 scene block. These are new contents that become theoretically visible for the first time at the L1 observation distance. The second part is the model of the spatially overlapping previous level. Due to the greater observation distance, the area represented by the current L1 block is usually covered by multiple smaller L0 scene blocks in the closer L0 level. Therefore, it is necessary to collect the models corresponding to all L0 scene blocks that spatially overlap with the current L1 target block. These two parts of input—the set of original models unique to the current L1 block and the set of models for all spatially overlapping L0 blocks—are logically integrated into a single process. Next, geometric merging and mesh simplification operations are performed on this integrated dataset. The merging operation combines multiple independent model meshes into a single mesh; the simplification operations (such as edge collapsing and vertex clustering) significantly reduce the number of triangles in the mesh and downsample the texture, based on the lower visual detail requirements corresponding to the L1 distance gradient compared to L0. 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.

[0118] Step S1230: Iteratively execute the above model generation operation for the next more distant distance level in order of distance from near to far, until the corresponding model is generated for all distance levels.

[0119] The processing logic defined in step S1220 constitutes an iterable template. Based on this, after generating models for all scene blocks in the L1 level, the process continues to serve the next, more distant level (e.g., L2). For the L2 level, the above operations are iteratively performed for each scene block: determining the original model of the L2-specific scene object falling within the L2 block; finding the (simplified) models generated by all L1 scene blocks that spatially overlap with the L2 block; merging and simplifying these two parts (the L2-specific original model + the overlapping L1 simplified models), and generating the final, further simplified aggregate model of the L2 block based on the lower detail requirements of the L2 level. This iterative process continues, strictly following the order from closest to furthest distance, generating models corresponding to all scene blocks for each level in the distance hierarchy sequence. Each iteration adds new distance-specific objects, which are then merged and further simplified with the already generated simplified models representing all closer visual content. Ultimately, the model generated for the farthest distance is the ultimate simplified representation of a massive number of objects within a very large theoretical region. The amount of data is extremely small, but sufficient to outline the macroscopic landscape at a very far distance.

[0120] The above embodiments automatically construct a hierarchical, spatially aligned pyramid of detail models by using scene chunks as processing units and following an iterative simplification process from near to far. The beneficial effect of this process is that it systematically generates multi-level detail models that precisely match the multi-layered scene chunk structure. Higher-level (far-distance) models visually encompass and simplify the areas represented by lower-level (near-distance) models, ensuring the continuity and consistency of visual presentation at different viewing distances. Automated geometric merging and mesh simplification replace the arduous task of manually creating multi-level detail models for massive amounts of objects in traditional methods, greatly improving content production efficiency and ensuring a scientific match between model accuracy and distance requirements. The generated hierarchical model system, combined with the detail model mapping table, provides a direct and optimized data foundation for efficient and smooth switching of detail levels and high-performance spatial streaming rendering scheduling at runtime. This allows the game client to intelligently and seamlessly transition between chunked aggregation models of different accuracies based on real-time viewing distance, thereby maximizing rendering efficiency while ensuring visual quality.

[0121] Please see Figure 6According to one aspect of this application, a game scene rendering control device includes a resource calling module 3100, an observation and distance fixing module 3200, a block loading module 3300, and an object rendering module 3400. The resource calling module 3100 is configured to call a scene resource package containing multiple layers of scene blocks. These multiple layers of scene blocks are divided based on preset distance tiers, and for the same spatial range in the scene map, multiple scene blocks belonging to different distance tiers exist. Each scene block has a personalized preset streaming distance and is associated with a model of a scene object adapted to its respective distance tier. The scene object belongs to the corresponding distance tier according to its visible distance. The observation and distance-fixing module 3200 is configured to continuously acquire the spatial position of the virtual camera in the game scene and determine the scene observation distance from the virtual camera to each scene block based on the spatial position; the block loading module 3300 is configured to determine and load the target scene block and its associated model from the multi-layer scene blocks based on the comparison result between the scene observation distance and the streaming distance of each scene block; the object rendering module 3400 is configured to, for the loaded target scene block, query the detail model mapping table in the scene resource package based on the object observation distance from the virtual camera to the scene object, and determine the model that the scene object should call for rendering.

[0122] Based on any embodiment of the apparatus in this application, the object rendering module 3400 includes: a lookup module, configured to obtain multiple candidate models associated with the scene object and their respective effective distance tiers from the detail model mapping table; and a matching processing module, configured to match the distance tier into which the object's observation distance falls with the effective distance tiers of each candidate model, and determine the candidate model associated with the successfully matched distance tier as the model that the scene object should currently call.

[0123] Based on any embodiment of the device in this application, the matching processing module includes: a hit determination module, configured to use models directly associated with the distance ladder to which the object's observation distance falls in the detail model mapping table as first candidate models; an availability processing module, configured to determine whether the first candidate model has been loaded into memory along with its scene block and is available, and if the first candidate model is available, determine it as the model that the scene object should currently call; and an exception handling module, configured to search for other candidate models associated with the scene object and already loaded and available from the detail model mapping table if the first candidate model is unavailable, use them as fallback models and determine which to call.

[0124] Based on any embodiment of the device in this application, following the block loading module 3300, the device further includes: a creation response module, configured to respond to an object creation event of a dynamic scene object and determine its visible distance based on the geometric dimensions of the dynamic scene object; a target matching module, configured to determine the target distance tier to which the dynamic scene object belongs and the corresponding target scene block based on the visible distance; and a model addition module, configured to generate a model adapted to the target distance tier for the dynamic scene object, add the model to the model associated with the target scene block, and synchronously update the detail model mapping table.

[0125] Based on any embodiment of the device in this application, the block loading module 3300 includes: a ratio determination module, configured to determine the ratio of the scene observation distance to the streaming distance for all scene blocks that satisfy the condition that the scene observation distance is less than or equal to its streaming distance; a level setting module, configured to set a loading priority for each scene block according to the size of the ratio, wherein the smaller the ratio, the higher the priority; and an asynchronous loading module, configured to add the model data of each scene block to the asynchronous loading queue in descending order of loading priority and execute loading.

[0126] Based on any embodiment of the device in this application, the block loading module 3300 further includes: an unloading identification module, configured to continuously determine whether the scene observation distance of each loaded scene block exceeds the preset unloading distance for that scene block, wherein the unloading distance is greater than the streaming distance of that scene block; an unloading enqueue module, configured to add scene blocks whose scene observation distance has exceeded their unloading distance to a list to be unloaded; and a task scheduling module, configured to schedule resource reclamation tasks to release the memory resources occupied by each scene block in the list to be unloaded.

[0127] Based on any embodiment of the device in this application, prior to the segmented loading module 3300, it includes: a distance reading module, configured to read the default streaming distance predefined for each scene segment in the scene resource package, wherein the default streaming distance is set based on the maximum visible distance among all scene objects contained in the scene segment; a distance correction module, configured to multiply the determined global scaling factor by the default streaming distance of each scene segment respectively to obtain the currently effective streaming distance of each scene segment; and a result determination module, configured to compare the scene observation distance with the effective streaming distance to determine the corresponding comparison result.

[0128] Based on any embodiment of the device in this application, prior to the distance correction module, the device further includes: an indicator monitoring module, configured to monitor the performance indicators of the game in real time, the performance indicators including frame rate and memory usage; a coefficient reduction module, configured to automatically reduce the global scaling coefficient when the frame rate is lower than a first threshold or the memory usage is higher than a second threshold; and a coefficient increase module, configured to automatically increase the global scaling coefficient when the frame rate is higher than a third threshold for a continuously preset duration and the memory usage is lower than a fourth threshold.

[0129] Based on any embodiment of the device in this application, the device further includes the following modules for generating the scene resource package through the following preprocessing stages: a tiered division module, configured to divide each scene object into a corresponding distance tier based on the visible distance of each scene object in the scene map, forming a logical object set for each distance tier; and a logical segmentation module, configured to spatially segment the area where the logical object set of each distance tier is distributed according to a preset tier segmentation specification for each distance tier, forming multiple scene blocks under that distance tier, wherein each scene block is associated with scene objects belonging to that tier that fall within its spatial range. The original model; the degeneracy generation module is configured to generate models for each scene block in each distance tier in order from near to far distance. When generating a model for any scene block, the original model of the scene object that falls within the spatial range of the block and is unique to this tier is geometrically merged and simplified with the models generated by all previous distance tiers that overlap with the block in space; the resource encapsulation module is configured to construct a scene resource package containing the multi-layer scene blocks, the models generated for each scene block, and the detailed model mapping table that records the mapping relationship between each scene object and the model used in the corresponding scene block of each distance tier.

[0130] Based on any embodiment of the device in this application, the tiered division module includes: a relationship determination module, configured to traverse each visually visible element 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 to treat visually visible elements without spatial dependencies as scene objects in independent groups; and a viewing distance determination module, configured to determine the visible distance of each scene object, wherein the visible distance is the maximum value among the visible distances of each visually visible element within the scene object.

[0131] 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.

[0132] Based on any embodiment of the device in this application, the degeneracy generation module includes: a first-level generation module, set as the first distance level with the closest distance, which directly determines the original models of the scene objects contained in each scene block as the model of the first distance level; a further distance generation module, set to perform geometric merging and mesh simplification on the original models of the scene objects unique to each scene block of the next further distance level in the distance level sequence, and 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, set to iteratively execute the above model generation operation for the next further distance level in the order of distance from near to far, until corresponding models are generated for all distance levels.

[0133] 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 game scene rendering control method.

[0134] 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 execute the game scene rendering control method of this application. The network interface of this electronic device is used for communication with a terminal.

[0135] 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.

[0136] 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 game scene rendering control device of this application, and the server can call the server's program code and data to execute the functions of all modules.

[0137] 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 game scene rendering control method of any embodiment of this application.

[0138] 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.

[0139] 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 controlling game scene rendering, characterized in that, include: Call a scene resource package containing multi-level scene blocks. The multi-level scene blocks are divided based on a preset distance tier. For the same spatial range in the scene map, there are multiple scene blocks belonging to different distance tiers. Each scene block has a preset streaming distance and is associated with a model of a scene object that is adapted to its respective distance tier. The scene object belongs to the corresponding distance tier according to its visible distance. Continuously acquire the spatial position of the virtual camera in the game scene, and determine the scene observation distance from the virtual camera to each scene block based on the spatial position; Based on the comparison between the scene observation distance and the streaming distance of each scene block, the target scene block and its associated model are determined and loaded from the multi-layer scene blocks; For the loaded target scene block, based on the object observation distance from the virtual camera to the scene object, the detail model mapping table in the scene resource package is queried to determine the model that the scene object should call for rendering.

2. The game scene rendering control method according to claim 1, characterized in that, Query the detailed model mapping table to determine the model that the scene object should call, including: From the detailed model mapping table, obtain multiple candidate models associated with the scene object and their respective effective distance tiers; The distance level into which the observed distance of the object falls is matched with the distance level in which each candidate model is effective. The candidate model associated with the successfully matched distance level is determined as the model that the scene object should currently call.

3. The game scene rendering control method according to claim 2, characterized in that, The candidate models associated with the successfully matched distance tiers are determined as the models that should be invoked by the scene object, including: The model directly associated with the distance ladder into which the object's observation distance falls in the detailed model mapping table is taken as the first candidate model; Determine whether the first candidate model has been loaded into memory and is available along with its scene block. If the first candidate model is available, determine it as the model that the scene object should currently call. If the first candidate model is unavailable, then other candidate models that are associated with the scene object and are already loaded and available are searched from the detailed model mapping table, used as fallback models, and determined for invocation.

4. The game scene rendering control method according to claim 1, characterized in that, Based on the comparison between the scene observation distance and the streaming distance of each scene block, after determining and loading the target scene block and its associated model from the multi-layer scene blocks, the process includes: In response to the object creation event of a dynamic scene object, determine its visible distance based on the geometry of the dynamic scene object; Based on the visible distance, determine the target distance tier to which the dynamic scene object belongs and the corresponding target scene block; Generate a model adapted to the target distance tier for the dynamic scene object, add the model to the model associated with the target scene block, and update the detailed model mapping table synchronously.

5. The game scene rendering control method according to claim 1, characterized in that, Based on the comparison between the scene observation distance and the streaming distance of each scene block, the target scene block and its associated model are determined and loaded from the multi-layer scene blocks, including: For all scene blocks that satisfy the condition that the scene observation distance is less than or equal to its streaming distance, determine the ratio of the scene observation distance to the streaming distance; Based on the ratio, a loading priority is assigned to each scene block; the smaller the ratio, the higher the priority. According to the loading priority from high to low, the model data of each scene block are added to the asynchronous loading queue in sequence and loaded.

6. The game scene rendering control method according to claim 1, characterized in that, Based on the comparison between the scene observation distance and the streaming distance of each scene block, after determining and loading the target scene block and its associated model from the multi-layer scene blocks, the process includes: For each loaded scene block, continuously determine whether its scene observation distance exceeds the preset unloading distance for that scene block, where the unloading distance is greater than the streaming distance of that scene block; Scenes whose observation distance has exceeded their unloading distance are divided into blocks and added to the unloading list; Schedule resource reclamation tasks to release the memory resources occupied by each scene block in the list to be unloaded.

7. The game scene rendering control method according to claim 1, characterized in that, Before determining and loading the target scene block and its associated model from the multi-layer scene blocks, based on the comparison result between the scene observation distance and the streaming distance of each scene block, the process includes: Read the default streaming distance predefined for each scene block in the scene resource package. The default streaming distance is set based on the maximum visible distance among all scene objects contained in the scene block. Multiply the determined global scaling factor by the default streaming distance of each scene block to obtain the effective streaming distance currently in effect for each scene block; The scene observation distance is compared with the effective transmission distance to determine the corresponding comparison result.

8. The game scene rendering control method according to claim 7, characterized in that, Before multiplying the determined global scaling factor by the default streaming distance of each scene block to obtain the currently effective streaming distance for each scene block, the following steps are taken: Real-time monitoring of game performance metrics, including frame rate and memory usage; When the frame rate is lower than the first threshold or the memory usage is higher than the second threshold, the global scaling factor is automatically reduced. When the frame rate is consistently higher than the third threshold for a preset duration and the memory usage is lower than the fourth threshold, the global scaling factor is automatically increased.

9. The game scene rendering control method according to any one of claims 1 to 8, characterized in that, The scene resource package is generated through the following preprocessing stages, including: For the scene map, based on the visible distance of each scene object, each scene object is divided into a corresponding distance tier, forming a logical object set for each distance tier; According to the preset segmentation specifications for each distance level, the area where the logical object set of each distance level is distributed is spatially divided to form multiple scene blocks under that distance level. Each scene block is associated with the original model of the scene object belonging to this level that falls within its spatial range. In order of increasing distance, the scene blocks of each distance level are generated sequentially. When generating a model for any scene block, the original model of the scene object that falls within the spatial range of the block and is unique to this level is geometrically merged and simplified with the models generated by all previous distance levels that overlap with the block in space. Construct a scene resource package that includes the multi-layered scene blocks, the models generated for each scene block, and the detailed model mapping table that records the mapping relationship between each scene object and the model used in the corresponding scene block at each distance level.

10. The game scene rendering control method according to claim 9, characterized in that, For the aforementioned scene map, based on the visible distance of each scene object, the scene objects are divided into corresponding distance tiers, forming logical object sets for each distance tier, including: Traverse each visually visible element in the scene map and determine the spatial dependencies between 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 grouped into scene objects that are independent. Determine the visible distance for each scene object, where the visible distance is the maximum value among the visible distances of all visually visible elements within the scene object.

11. The game scene rendering control method according to claim 10, 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.

12. The game scene rendering control method according to claim 9, characterized in that, Models are generated sequentially for each scene segment at each distance level, from nearest to farthest, including: For the first distance level that is closest, the original models of the scene objects contained in each scene block are directly determined as the models of the first distance level. 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 meshed 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. The above model generation operations for the next, more distant distance level are iteratively executed in order of increasing distance, until corresponding models are generated for all distance levels.

13. A game scene rendering control device, characterized in that, include: The resource invocation module is configured to invoke a scene resource package containing multi-level scene blocks. The multi-level scene blocks are divided based on a preset distance tier, and there are multiple scene blocks belonging to different distance tiers in the same spatial range in the scene map. Each scene block has a personalized preset streaming distance and is associated with a model of a scene object that is adapted to its respective distance tier. The scene object belongs to the corresponding distance tier according to its visible distance. The observation distance module is set to continuously acquire the spatial position of the virtual camera in the game scene, and determine the scene observation distance from the virtual camera to each scene block based on the spatial position; The segmented loading module is configured to determine and load the target scene segment and its associated model from the multi-layer scene segments based on the comparison result between the scene observation distance and the streaming distance of each scene segment. The object rendering module is configured to, for the loaded target scene blocks, query the detail model mapping table in the scene resource package based on the object observation distance from the virtual camera to the scene object, and determine the model that the scene object should call for rendering.

14. 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 12.

15. 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 12, which, when invoked by a computer, executes the steps included in the corresponding method.

Images