Object rendering method and device of virtual scene, computer device, storage medium and program product

Abstract

This application relates to a method, apparatus, computer device, storage medium, and program product for object rendering in a virtual scene. The method includes: obtaining the current position unit of the current viewpoint in the virtual scene; obtaining visible set data corresponding to the current position unit, the visible set data including a first type of data and a second type of data, the first type of data used to record other position units visible from the current position unit, and the second type of data used to record information about static objects visible from the current position unit; determining the object type of the target object to be rendered in the virtual scene, the object type including dynamic objects or static objects; determining the visibility state of the target object based on the object type using the second type of data or the first type of data, wherein static objects correspond to the second type of data, and dynamic objects correspond to the first type of data; if the target object is determined to be visible, then performing a rendering operation on the target object. Using this application can improve the smoothness of rendering and the efficiency of resource scheduling.

Description

Technical Field

[0001] This application relates to the field of virtual scene rendering technology, and in particular to a method, apparatus, computer device, storage medium and program product for rendering objects in a virtual scene. Background Technology

[0002] With the rapid development of 3D rendering, virtual reality, and open-world games, the complexity of real-time rendering scenes is constantly increasing. To improve rendering efficiency, frustum culling and occlusion culling techniques are commonly used. Frustum culling removes completely invisible objects within the camera's frustum range, while occlusion culling removes completely occluded objects based on occlusion relationships between objects. In this context, culling methods based on the latent visible set (PVS) have become a common approach. These methods pre-calculate the set of visible objects in different regions of the scene, allowing for rapid determination of objects to be rendered at runtime.

[0003] Traditional PVS implementations primarily include: static query-based storage of visible unit sets, where a fixed set of visible objects is pre-stored for each query condition; and spatial non-uniform region storage, which reduces storage overhead by dividing the space into regions of varying sizes. Furthermore, related solutions often employ a unified storage structure to centrally store all PVS data and utilize a single thread to complete the entire PVS data generation process.

[0004] However, traditional technologies have low smoothness and resource scheduling efficiency in real-time rendering in dynamic scenes. Summary of the Invention

[0005] Therefore, it is necessary to provide a virtual scene object rendering method, apparatus, computer equipment, storage medium, and program product that can improve rendering smoothness and resource scheduling efficiency in response to the above-mentioned technical problems.

[0006] Firstly, this application provides a method for rendering objects in a virtual scene, the method comprising:

[0007] Obtain the current position unit of the current viewpoint in the virtual scene, where the virtual scene is pre-divided into multiple position units; Obtain the visible set data corresponding to the current position unit. The visible set data includes: a first type of data and a second type of data. The first type of data is used to record other position units visible from the current position unit, and the second type of data is used to record information about static objects visible from the current position unit. Determine the object type of the target object to be rendered in the virtual scene. The object type includes dynamic objects or static objects. Based on the object type, determine the visibility state of the target object using the second type of data or the first type of data. Static objects correspond to the second type of data, and dynamic objects correspond to the first type of data. If the target object is determined to be visible, then a rendering operation is performed on the target object.

[0008] In one embodiment, determining the visibility state of a dynamic object using the first type of data includes: Obtain at least one location unit occupied by a dynamic object in a virtual scene; If at least one location unit occupied by a dynamic object intersects with other location units of a first-class data record, then the dynamic object is determined to be visible.

[0009] In one embodiment, determining the visibility state of a static object using the second type of data includes: Get the unique identifier of a static object; If the unique identifier exists in the second type of data, then the static object is determined to be visible.

[0010] In one embodiment, the method further includes: Obtain the region type flag for each location unit. The region type flag is used to indicate whether the location unit allows dynamic objects to enter. For location units marked as allowing dynamic objects to enter, generate the first type of data; For location cells marked as not allowing dynamic objects to enter, generate the second type of data.

[0011] In one embodiment, the region type marker is generated by receiving manually generated markers through a scene editor; And / or, when there is no object in a location cell whose position change exceeds a preset threshold, the location cell is marked as not allowing dynamic objects to enter.

[0012] In one embodiment, the method further includes: The visible set data of multiple location units is stored in segments according to spatial regions. Each segment corresponds to a continuous spatial region containing a preset number of location units.

[0013] In one embodiment, the method further includes: During runtime, based on the current position of the virtual camera or virtual character, the visible set data fragments corresponding to the spatial area within a preset range around the current position are loaded; Unload the visible collection data fragments corresponding to the spatial region that exceeds the preset range.

[0014] In one embodiment, unloading the visible set data fragments corresponding to spatial regions exceeding a preset range includes: Get the first distance between the spatial region and the current position of the virtual camera or virtual character, as well as the number of currently loaded fragments; If the first distance exceeds the preset first distance threshold, and the number of currently loaded fragments exceeds the preset number threshold, then the space set corresponding to the space region is unloaded.

[0015] In one embodiment, the method further includes: Predict the future location of a virtual camera or virtual character; Load the visible set data fragments corresponding to the spatial region within a preset range around the future location.

[0016] In one embodiment, predicting the future location of a virtual camera or virtual character includes: Obtain the current movement direction vector and current movement speed of the virtual camera or virtual character; Calculate the future position based on the current movement direction vector, the current movement speed, and the preset time step.

[0017] In one embodiment, predicting the future location of a virtual camera or virtual character includes: Detect the movement skill release operation of virtual cameras or virtual characters; The final position of the movement skill is used as the future position.

[0018] In one embodiment, obtaining the visible set data corresponding to the current location unit includes: Starting from the location unit, perform a ray casting or occlusion query operation; Based on the results of the ray projection or occlusion query operation, determine other position cells or static objects that are visible to the current position cell.

[0019] In one embodiment, the method further includes: A multi-threaded task system and / or a distributed computing system are used to generate visible set data for each location unit in parallel.

[0020] In one embodiment, before determining the visibility state of the target object, the method further includes: Obtain the second distance between the current viewpoint and the target object. If the second distance is less than the preset second distance threshold, the target object is determined to be visible.

[0021] In one embodiment, the multiple position units are regular 3D grids of equal size. Obtaining the current position unit of the current viewpoint in the virtual scene includes: Obtain the spatial coordinates of the current viewpoint, normalize the spatial coordinates according to the preset unit size, and obtain the index of the current position.

[0022] In one embodiment, obtaining the visible set data corresponding to the current location unit includes: Obtain the direction information of the current viewpoint; Based on the current position unit and orientation information, determine the visible set data corresponding to the current position unit and orientation information.

[0023] Secondly, this application also provides an object rendering apparatus for a virtual scene, the apparatus comprising: The viewpoint position acquisition module is used to acquire the current position unit of the current viewpoint in the virtual scene, wherein the virtual scene is pre-divided into multiple position units; The visible set acquisition module is used to acquire the visible set data corresponding to the current position unit. The visible set data includes: a first type of data and a second type of data. The first type of data is used to record other position units visible from the current position unit, and the second type of data is used to record information about static objects visible from the current position unit. The visibility determination module is used to determine the object type of the target object to be rendered in the virtual scene. The object type includes dynamic objects or static objects. Based on the object type, the visibility state of the target object is determined using the second type of data or the first type of data. Static objects correspond to the second type of data, and dynamic objects correspond to the first type of data. The rendering execution module is used to perform rendering operations on the target object if it is determined that the target object is visible.

[0024] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.

[0025] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0026] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0027] The object rendering method, apparatus, computer device, storage medium, and program product for virtual scenes provided in this application pre-divide the virtual scene into multiple location units and configure two types of visible set data for each current location unit. The first type of data records other visible location units, and the second type of data records visible static object information. During runtime, based on the type of the target object to be rendered (dynamic object or static object), the corresponding data class (dynamic objects correspond to the first type of data, and static objects correspond to the second type of data) is adaptively selected for visibility determination, and the rendering is determined based on the determination result. Thus, even in dynamic scenes where a large number of dynamic and static objects coexist, this application selects pre-stored differentiated data (location unit set or object identifier set) driven by object type, enabling dynamic objects to be quickly determined based on the intersection of spatial regions and static objects to be directly matched with identifiers. This avoids unnecessary computation and storage overhead, thereby improving the smoothness of real-time rendering and resource scheduling efficiency in dynamic scenes. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 A flowchart illustrating an object rendering method for a virtual scene provided in an embodiment of this application; Figure 2 A flowchart illustrating the steps of loading and unloading visible collection data streams, provided for an embodiment of this application; Figure 3 A flowchart illustrating a visible set data preloading step based on motion prediction, provided for an embodiment of this application; Figure 4 A schematic diagram of a PVS occlusion determination scenario provided in an embodiment of this application; Figure 5 This is a schematic diagram illustrating the result of dividing a virtual scene space into equal-sized cubic meshes, as provided in an embodiment of this application. Figure 6 A flowchart illustrating an object removal method based on visible set data provided in this application embodiment; Figure 7 This is a schematic diagram of the structure of an object rendering device for a virtual scene provided in an embodiment of this application; Figure 8 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0031] In one exemplary embodiment, Figure 1 This is a flowchart illustrating a virtual scene object rendering method provided in an embodiment of this application, as shown below. Figure 1 As shown, a method for object rendering in a virtual scene is provided. This example illustrates the method's application to a terminal; however, it can also be applied to a server, or a system including both a terminal and a server, and implemented through interaction between the terminal and the server. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, and tablets. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. In this embodiment, the method includes the following steps S101 to S104: S101. Obtain the current position unit of the current viewpoint in the virtual scene, wherein the virtual scene is pre-divided into multiple position units.

[0032] Here, "current viewpoint" refers to the observation position of a virtual camera or virtual character within a virtual scene. "Virtual scene" refers to a 3D computer graphics environment, such as a game world or virtual reality space. "Position unit" refers to a basic spatial unit obtained by dividing the virtual scene according to preset rules; each position unit has a defined spatial range. Multiple position units can collectively cover the entire active area of ​​the virtual scene.

[0033] For example, the terminal can obtain the spatial coordinates of the current virtual camera or control character in the virtual scene, and calculate the position unit to which the spatial coordinates belong according to the preset spatial division rules, and use it as the current position unit.

[0034] As an example, the virtual scene can be uniformly divided into a grid of cubes with equal side lengths, with each cube representing a position cell. The terminal obtains the 3D coordinates (x, y, z) of the current viewpoint, and obtains the index (ix, iy, iz) of the current position cell by dividing the coordinate components by the side length of the cube and rounding them down.

[0035] S102. Obtain the visible set data corresponding to the current position unit. The visible set data includes: a first type of data and a second type of data. The first type of data is used to record other position units visible from the current position unit, and the second type of data is used to record information about static objects visible from the current position unit.

[0036] The visible set data refers to a set of objects or spatial units that can be observed from a specific viewpoint, either pre-calculated or determined at runtime. The first type of data refers to a data structure used for querying the visibility of dynamic objects, which records the identification information of other visible location units. The second type of data refers to a data structure used for querying the visibility of static objects, which records the identification information of visible static objects. Static objects refer to objects whose positions remain fixed in the virtual scene, such as buildings and terrain.

[0037] For example, the terminal can read data corresponding to the current location unit from a pre-stored visible set data file. This data can contain two types: one records the indices of other location units visible from this location unit, and the other records the unique identifiers of static objects visible from this location unit.

[0038] As an example, for regions marked as reachable by dynamic objects, their visible set data stores a set of grid indices of other visible location units; for regions marked as purely static, their visible set data stores a set of globally unique identifiers of visible static objects. The terminal can directly index to the corresponding data block using the index of the current location unit.

[0039] S103. Determine the object type of the target object to be rendered in the virtual scene. The object type includes dynamic objects or static objects. Based on the object type, determine the visibility state of the target object using the second type of data or the first type of data. Static objects correspond to the second type of data, and dynamic objects correspond to the first type of data.

[0040] Here, the target object refers to any virtual object that may need to be rendered in the current frame. Dynamic objects refer to objects whose position can change within the virtual scene, such as virtual characters, movable props, and special effects. Static objects refer to objects whose position remains fixed. Visibility refers to whether the target object can be observed from the current viewpoint; visible objects require rendering, while invisible objects can be discarded.

[0041] For example, the terminal obtains the type tag of the object to be rendered and determines whether the object is a dynamic object or a static object. If it is a static object, the second type of data can be used for visibility determination; if it is a dynamic object, the first type of data can be used for visibility determination.

[0042] As an example, each virtual object can be marked as movable during the pre-computation phase. At runtime, for objects with static tags, the terminal directly queries the second type of data (the set of visible static object identifiers). If the object's unique identifier exists in the set, it is determined to be visible. For dynamic objects without static tags, the terminal queries the first type of data (the set of visible position units) and performs an intersection judgment based on the position unit currently occupied by the object.

[0043] S104. If the target object is determined to be visible, then a rendering operation is performed on the target object.

[0044] Rendering operations refer to the process of converting the geometric data and texture data of a three-dimensional object model into a two-dimensional image and outputting it to a display device.

[0045] For example, when the terminal determines that the target object is visible in the current viewpoint, it submits the target object to the rendering pipeline and executes the drawing instructions.

[0046] As an example, the terminal generates drawing instructions (such as a draw call) for the target object, which are then drawn by the graphics processor to display the object on the game screen.

[0047] In this embodiment, the location unit of the current viewpoint is obtained, and then the visible set data containing two types of data corresponding to that location unit is obtained. Next, different data types are selected for visibility determination based on whether the target object is dynamic or static. Finally, rendering can be performed only on visible objects. This enables differentiated and precise visibility queries for dynamic and static objects, avoiding the problems of dynamic objects not being effectively removed or low query efficiency. Therefore, it can effectively improve the rendering efficiency of the virtual scene, reduce memory overhead, and improve resource scheduling efficiency.

[0048] In one exemplary embodiment, determining the visibility state of a dynamic object using a first type of data includes: Obtain at least one location unit occupied by a dynamic object in a virtual scene; If at least one location unit occupied by a dynamic object intersects with other location units of a first-class data record, then the dynamic object is determined to be visible.

[0049] Here, the location unit occupied by a dynamic object can refer to the set of location units mapped to based on the spatial extent covered by the bounding box of the dynamic object in the virtual scene. Intersection refers to the existence of at least one identical element in two sets.

[0050] For example, the terminal can obtain the axis-aligned bounding box of the dynamic object and calculate the set of indices of all positional units covered by the bounding box. Then, it compares this set with the set of visible positional units recorded in the first type of data. If there are common units, the dynamic object is determined to be visible.

[0051] As an example, for a dynamic character, its bounding box covers three adjacent positional units with indices (3,4,5), (3,4,6), and (3,5,5). The visible positional units recorded in the first set of data for the current viewpoint include (3,4,6) and (4,4,5). Since (3,4,6) exists in both sets, the character is determined to be visible.

[0052] Alternatively, the location cell where the center point of a dynamic object falls can be used as the unique cell it occupies, in order to reduce the amount of computation.

[0053] In this embodiment, the visibility query of dynamic objects no longer depends on their identity identifiers, but is judged by the intersection of the position unit occupied by the dynamic object and the first type of data. This allows the dynamic object to be adapted to any movement of the dynamic object while maintaining a query complexity of O(1), thereby improving rendering efficiency.

[0054] In one exemplary embodiment, determining the visibility state of a static object using a second type of data includes: Get the unique identifier of a static object; If the unique identifier exists in the second type of data, then the static object is determined to be visible.

[0055] Among them, the unique identifier can refer to a globally unique code that can distinguish different static objects, such as a globally unique identifier or a numeric identifier.

[0056] For example, the terminal reads the pre-assigned unique identifier of the static object, and then searches in the second type of data (i.e., the set of static object identifiers visible from the current viewpoint). If a match is found, the static object is determined to be visible.

[0057] As an example, a building is uniquely identified as "Building_001". The second type of data in the current viewpoint contains identifiers such as "Building_001" and "Tree_045", so the building is determined to be visible. If another building is identified as "Building_002" and is not in the set, it is determined to be invisible.

[0058] Optionally, the second type of data can be stored as a hash set or a Bloom filter to accelerate existence queries.

[0059] In this embodiment, the second type of data is directly queried through a unique identifier. The visibility determination of static objects only requires one set lookup operation, without the need for spatial calculation, thereby improving the culling efficiency of static objects and reducing rendering overhead.

[0060] In one exemplary embodiment, the method further includes: Obtain the region type flag for each location unit. The region type flag is used to indicate whether the location unit allows dynamic objects to enter. For location units marked as allowing dynamic objects to enter, generate the first type of data; For location cells marked as not allowing dynamic objects to enter, generate the second type of data.

[0061] Among them, the region type label can refer to the attribute label that is pre-assigned to each location unit, which is used to distinguish whether the location unit belongs to the reachable region of a dynamic object or a purely static region.

[0062] For example, during the pre-computation phase, the terminal or server obtains the region type tag for each location unit. For location units that allow dynamic objects to enter (i.e., dynamically reachable regions), their visible set data is generated as first-class data (the set of other visible location units); for location units that do not allow dynamic objects to enter (i.e., purely static regions), their visible set data is generated as second-class data (the set of visible static object identifiers).

[0063] As an example, the scene editor can be used to manually mark areas on the ground of the virtual scene that the character can walk on. The corresponding location units of these areas are marked as "allowed for dynamic objects to enter". For these location units, the first type of data is pre-calculated and generated. The location units corresponding to virtual areas that the character cannot reach, such as virtual cliffs and virtual rooftops, are marked as "not allowed for dynamic objects to enter", generating the second type of data.

[0064] In this embodiment, dynamic reachable regions and purely static regions are distinguished by region type tags, and visible set data with different structures are generated accordingly. This allows the runtime to select the optimal query path based on the object type, thereby maximizing query efficiency and reducing memory overhead while ensuring correctness.

[0065] In one exemplary embodiment, the region type markers are generated by receiving manually generated markers via a scene editor; And / or, when there is no object in a location cell whose position change exceeds a preset threshold, the location cell is marked as not allowing dynamic objects to enter.

[0066] The scene editor can refer to a visual editing tool used by artists or designers. The preset threshold can refer to a distance value used to determine whether an object has undergone significant positional movement.

[0067] For example, on the one hand, region type labels can be manually set for each location unit in the scene editor. On the other hand, the system can also automatically analyze scene data: if within a certain location unit, no dynamic object's position change exceeds a preset distance (e.g., the side length of a location unit) during the game's execution, then the location unit is automatically marked as a static region.

[0068] As an example, in a gameplay map of a virtual scene, the editor can mark the surface units of each floating island as "allowed for dynamic objects to enter". However, for the empty area below the island, since no movable objects can reach it, the system can automatically mark it as "disallowed for dynamic objects to enter".

[0069] Optionally, the preset threshold for automatic labeling can be set in multiple dimensions according to the scene's accuracy requirements. For example, in a scene where micro-movement needs to be strictly judged, the preset threshold can be set to 0.5 times the side length of the position unit; in an open scene where the size fluctuation of the object itself needs to be tolerated, the preset threshold can be set to the maximum diagonal length of the bounding box of the dynamic object; in a scene with normal terrain, the preset threshold can be set to 1.5 times the side length of the position unit to tolerate a certain degree of position fluctuation.

[0070] In this embodiment, the region type labels are generated by a combination of manual and automatic methods, which not only ensures the accuracy of key region labels but also reduces the workload of manual labeling, thereby improving the data generation efficiency in the pre-computation stage.

[0071] In one exemplary embodiment, the method further includes: The visible set data of multiple location units is stored in segments according to spatial regions. Each segment corresponds to a continuous spatial region containing a preset number of location units.

[0072] In this context, fragmented storage refers to splitting a large block of data into multiple independent smaller files based on spatial continuity. The preset number of location units refers to the number of location units contained in each fragment, such as N×N×N location units.

[0073] For example, after pre-calculation, the terminal or server divides the visible set data of all location units in the virtual scene into multiple data slices according to spatial regions. Each slice corresponds to a cubic spatial region, which consists of a fixed number (e.g., 8×8×8) of location units, and saves the slice as an independent file.

[0074] As an example, the virtual scene is divided into multiple 16m x 16m x 16m regions, each containing 8 x 8 x 8 location units with sides of 2m. The visible set data of all location units within each region is stored as a separate PVS data file, with the file name including the spatial index of that region.

[0075] Optionally, the size of the slices can be dynamically adjusted based on scene size and memory limitations.

[0076] In this embodiment, by storing the visible set data in segments according to spatial regions, local data can be loaded on demand during runtime, avoiding loading the entire scene's visible set data into memory at once, thereby effectively reducing runtime memory overhead.

[0077] In one exemplary embodiment, Figure 2 This application provides a flowchart illustrating the steps of loading and unloading visible collection data streams, as shown in the embodiments. Figure 2 As shown, the method also includes: S201. During runtime, based on the current position of the virtual camera or virtual character, load the visible set data fragments corresponding to the spatial area within a preset range around the current position. S202. Unload the visible set data fragments corresponding to the spatial area that exceeds the preset range.

[0078] The preset range can refer to a radius of a region defined in space, centered on the current location.

[0079] For example, when running a virtual scene such as a game, the terminal can monitor the current position of a virtual camera or virtual character, determine all spatial regions within a preset distance around that position, and asynchronously load the visible set data fragments corresponding to these regions. Simultaneously, for fragments that have already been loaded but whose current distance has exceeded the preset range, an unloading operation is performed to release memory.

[0080] As an example, the preset range is set to a cube centered on the current location with a radius of 3 spatial regions (each region being 16 meters). When the character moves, the terminal dynamically calculates the regions that need to be loaded and the regions that can be unloaded, loads the new PVS file through an asynchronous IO thread, and unloads the files for the regions that are far away.

[0081] Optionally, the preset range can be dynamically adjusted based on the available memory size of the current device.

[0082] In this embodiment, by dynamically loading and unloading visible set data fragments at runtime, only the current and surrounding areas of the data are always retained in memory. No matter how large the entire virtual scene is, the memory usage can be kept at a low level, thereby improving resource scheduling efficiency and memory utilization.

[0083] In an exemplary embodiment, unloading the visible set data fragment corresponding to a spatial region that exceeds a preset range includes: Get the first distance between the spatial region and the current position of the virtual camera or virtual character, as well as the number of currently loaded fragments; If the first distance exceeds the preset first distance threshold, and the number of currently loaded fragments exceeds the preset number threshold, then the space set corresponding to the space region is unloaded.

[0084] Here, the first distance can refer to the spatial distance between the current location of the virtual camera or virtual character and the center point or boundary of the spatial region. The first distance threshold can refer to a boundary value used to determine whether a spatial region is too far from the current location; spatial regions exceeding this first distance threshold can be considered no longer necessary to be retained in memory. The quantity threshold can refer to the maximum number of fragments allowed to be retained in memory.

[0085] For example, when determining whether to unload a loaded visible data fragment, the terminal needs to simultaneously meet two conditions: the distance from the spatial region corresponding to the fragment to the current location is greater than a preset distance threshold, and the total number of currently loaded fragments is greater than a preset quantity threshold. This design can reserve a certain amount of cache space and avoid frequent loading and unloading due to minor changes in location.

[0086] As an example, let's set a distance threshold of 50 meters and a quantity threshold of 8. When a character moves, if an area is 55 meters away from the character and currently has 10 shards loaded (more than 8), then the shards in that area will be unloaded. If only 6 shards are currently loaded, even if an area is more than 50 meters away, it can be temporarily left unloaded.

[0087] In this embodiment, by setting dual unloading judgment conditions, a balance is achieved between memory usage and loading jitter. This ensures that memory is not excessively consumed and avoids frequent I / O operations caused by position fluctuations, thereby improving the smoothness of rendering and the efficiency of resource scheduling.

[0088] In one exemplary embodiment, the method further includes: Predict the future location of a virtual camera or virtual character; Load the visible set data fragments corresponding to the spatial region within a preset range around the future location.

[0089] The future location refers to the location that a virtual camera or character will arrive at in the near future, which can be inferred from the current motion state or known transmitted information.

[0090] For example, the terminal can predict the possible location of a virtual camera or character in the future based on the current motion trend or game logic, and preload the visible set of data slices around the future location to achieve smoother data switching.

[0091] As an example, when a character moves in a positive direction at a speed of 5 meters per second, the terminal predicts its position 0.5 seconds later and preloads the area fragments around that position.

[0092] Alternatively, predictions can be made based on preset game storylines or quest teleportation points.

[0093] In this embodiment, by predicting future locations and loading the corresponding data fragments in advance, the loading latency at runtime can be effectively reduced, and screen stuttering caused by unprepared data can be avoided, thereby improving the continuity of rendering and the foresight of resource scheduling.

[0094] In one exemplary embodiment, Figure 3 A flowchart illustrating a visible set data preloading step based on motion prediction, as provided in this application embodiment, is shown below. Figure 3 As shown, predicting the future location of a virtual camera or virtual character includes: S301. Obtain the current movement direction vector and current movement speed of the virtual camera or virtual character; S302. Calculate the future position based on the current movement direction vector, the current movement speed, and the preset time step.

[0095] Here, the current movement direction vector can refer to a three-dimensional vector representing the character's orientation. The current movement speed can refer to the character's movement rate. The time step can refer to the future time interval used for prediction.

[0096] For example, the terminal can obtain the character's current movement direction vector V and current movement speed s, set a prediction time step Δt, and then the future position can be determined according to the expression, for example: P_future = P_current + V ×(s × Δt), where P_future is the future position and P_current is the current position.

[0097] As an example, if the character's current position is (10,0,10), the movement direction is the positive X-axis, the speed is 5 meters per second, and the time step is 0.5 seconds, then the future position will be (12.5,0,10).

[0098] Optionally, the time step can be dynamically adjusted according to the current frame rate; the higher the frame rate, the smaller the step size.

[0099] In this embodiment, a simple and fast-response prediction of future position can be achieved through velocity-direction prediction based on a kinematic model, providing a reliable basis for preloading and thus improving resource scheduling efficiency.

[0100] In one exemplary embodiment, predicting the future location of a virtual camera or virtual character includes: Detect the movement skill release operation of virtual cameras or virtual characters; The final position of the movement skill is used as the future position.

[0101] The "displacement skill release" refers to a skill action triggered by a player (game account or account) or AI that allows the character to instantly move to another location. The destination location refers to the new location to which the character will be teleported after the displacement skill takes effect.

[0102] For example, the terminal can listen to skill events in the game logic. When it detects that a character has released a skill with a displacement effect, it can extract the endpoint coordinates defined by the skill and preload them as the future position.

[0103] As an example, in a game, a virtual character might use a skill such as "Flash," and the skill data includes the endpoint coordinates (100,0,50). The terminal directly uses these coordinates as the future position and preloads PVS data fragments around that position.

[0104] Optionally, for skills with multiple displacements or cancelable movements, multiple possible endpoints can be predicted.

[0105] In this embodiment, by detecting displacement skills and directly obtaining the endpoint position, accurate prediction of discontinuous and jump-like position changes can be achieved, avoiding the failure of speed-based prediction, ensuring that data can be in place in a timely manner in skill transmission scenarios, and improving the continuity of rendering.

[0106] In an exemplary embodiment, obtaining the visible set data corresponding to the current location unit includes: Starting from the location unit, perform a ray casting or occlusion query operation; Based on the results of the ray projection or occlusion query operation, determine other position cells or static objects that are visible to the current position cell.

[0107] Ray casting refers to the method of emitting a virtual ray from a starting point along a specific direction and detecting the intersection of the ray with objects in the scene. Occlusion query refers to the process of determining whether there is an obstacle between two spatial points.

[0108] For example, in the pre-computation stage, for each location unit, multiple rays are emitted in various directions or occlusion queries are performed starting from the sampling point at the center or inside the location unit, and other location units or static objects that can be reached without occlusion are recorded. These results are used as the visible set data of the location unit.

[0109] like Figure 4 As shown, starting from the viewpoint position (Pos) and direction (Dir), occlusion is determined by assessing the bounding box of the target object to ascertain its visibility. If the determination indicates occlusion, no update or rendering operations are performed on the target object in that frame to conserve CPU and GPU resources. If the determination indicates no occlusion, normal update and rendering operations are performed on the target object in that frame.

[0110] As an example, a ray is emitted from the center of location unit A to the center of location unit B. If the ray does not intersect any opaque object before reaching B, then location unit B is determined to be visible, and its index is added to the first type of data in A. For static objects, it is determined whether the sampling points on their bounding box are visible.

[0111] Alternatively, a visible set can be generated using hardware occlusion query or rasterization methods.

[0112] In this embodiment, visible set data is generated by ray casting or occlusion query, which ensures the accuracy of the pre-calculated results and provides a reliable data foundation for efficient culling at runtime, thereby improving rendering efficiency.

[0113] In one exemplary embodiment, the method further includes: A multi-threaded task system and / or a distributed computing system are used to generate visible set data for each location unit in parallel.

[0114] In this context, a multi-threaded task system refers to a scheduling framework that can break down a computational task into multiple subtasks and have them processed in parallel by multiple CPU cores. A distributed computing system refers to a system architecture that distributes computational tasks across multiple computers for collaborative completion.

[0115] For example, in the pre-computation stage, since the computation of the visible set data of each location unit is independent of each other, the computation tasks of all location units can be encapsulated into independent task units and executed in parallel on a single machine with multiple cores through a multi-threaded task system, or further distributed to multiple machines for parallel processing through a distributed computing system.

[0116] As an example, JobSystem can be used to distribute the PVS computation task of 100,000 location units in a virtual scene to 20 CPU cores for parallel execution, increasing the generation speed by about 15 times. If the scene is further partitioned and distributed to 5 machines, with each machine processing in multiple threads, the overall speed can be increased by about 70 times.

[0117] Optionally, cloud servers can be used for elastic scaling, increasing computing resources as needed.

[0118] In this embodiment, by employing multi-threading and distributed parallel computing, the pre-computation time for visible set data can be shortened, reducing the generation time of PVS for large-scale open-world scenes from tens of hours to hours or even minutes, thus improving the efficiency of resource preparation. Furthermore, since the computation of visible set data for each location unit is mathematically and logically independent, and there is no shared memory or state dependency between computational tasks, a near-linear speedup can be achieved during multi-threaded scheduling, significantly reducing the idle rate of multi-core processor resources. In distributed computing scenarios, by dividing the spatial region across different computing nodes, not only is the horizontal scaling of the computational load realized, but the capacity limitation of single-machine memory on large-scale scene datasets is also effectively overcome, making the generation of PVS data for ultra-large-scale virtual scenes scalable.

[0119] In one exemplary embodiment, before determining the visibility state of the target object, the method further includes: Obtain the second distance between the current viewpoint and the target object. If the second distance is less than the preset second distance threshold, the target object is determined to be visible.

[0120] The second distance refers to the spatial straight-line distance between the current viewpoint and the bounding box or center point of the target object. Specifically, it can be the distance from the current viewpoint to the nearest point, center point, or surface of the bounding box of the target object. The second distance threshold can be a configurable value used to determine whether the target object is close enough to the current viewpoint. Objects with a distance smaller than the second distance threshold are considered to be necessarily visible from the current viewpoint or do not require precise occlusion determination. Before determining the visibility status of the target object, this proximity determination is performed before performing a visibility query operation based on the potential visibility set data. If the condition is met, a visibility conclusion is directly obtained, and subsequent visibility query steps are not performed.

[0121] For example, before determining visibility, the terminal first calculates the distance between the current viewpoint and the target object. If the distance is less than a preset proximity threshold (e.g., 1 meter), the object is directly determined to be visible, and the subsequent PVS query process is skipped.

[0122] As an example, in a gameplay scenario with a virtual environment, a virtual character stands on a virtual floating island, and the camera is typically no more than two times the height difference between the character and the virtual island. Ground objects closest to the camera are almost always visible, and marking them as visible directly saves on PVS (Programme for Servers) query overhead.

[0123] Optionally, this optimization strategy can be an optional feature, which can be enabled or disabled depending on the specific game configuration of the scenario.

[0124] In this embodiment, by prioritizing proximity, complex visibility queries are skipped in specific scenarios, and visibility is directly determined, thereby reducing unnecessary computational overhead and further improving rendering efficiency.

[0125] In an exemplary embodiment, multiple position units are regular 3D grids of equal size. Obtaining the current position unit of the current viewpoint in the virtual scene includes: Obtain the spatial coordinates of the current viewpoint, normalize the spatial coordinates according to the preset unit size, and obtain the index of the current position.

[0126] The "regular 3D grid" refers to a grid structure formed by dividing a virtual scene in 3D space with uniform, equidistant steps. Each grid cell has the same size in the X, Y, and Z axes, and adjacent cells are seamlessly connected, forming a 3D checkerboard-like spatial division covering the entire scene or the active area of ​​the scene. The "preset cell size" refers to the pre-defined side length of each position cell in 3D space, which is equal in all dimensions. "Uniform division" refers to dividing the virtual scene into equal intervals in all three dimensions with the same step size, making each position cell a cube of identical size, and adjacent cells seamlessly connected. "Normalization operation" refers to the calculation process of mapping spatial coordinates from a continuous metric space to a discrete integer index space, specifically including the mathematical operation of dividing each coordinate axis component by the preset cell size and rounding. The current position index refers to an ordered triplet consisting of three integers, representing the grid number of the current viewpoint in the X, Y, and Z axes, used to uniquely identify the grid cell where the current viewpoint is located.

[0127] For example, during the pre-computation or scene initialization phase, the terminal or server can obtain the overall extent of the virtual scene in three-dimensional space (e.g., the minimum bounding box) and read the preset cell side length value. Then, starting from the scene boundary, the scene is divided at equal intervals along the X, Y, and Z axes, respectively, thereby regularly dividing the entire scene into multiple adjacent cubic meshes, each mesh being a position cell.

[0128] like Figure 5 As shown, the virtual scene space is schematically divided into equal-sized cubic grids using preset colored lines (such as blue), with each cubic grid corresponding to a position unit.

[0129] As an example, suppose the virtual scene has a range of 0 to 256 meters along the X-axis, 0 to 128 meters along the Y-axis, and 0 to 256 meters along the Z-axis. The default unit side length is 2 meters. Then, there are 128 units along the X-axis, 64 units along the Y-axis, and 128 units along the Z-axis, for a total of 128 × 64 × 128 = 1,048,576 position units. Each position unit is a 2m × 2m × 2m cube. For any point coordinate P(x, y, z) in the scene, its corresponding position unit index can be obtained directly through integer division: idx_x = floor(x / 2), idx_y = floor(y / 2), idx_z = floor(z / 2).

[0130] Optionally, the preset cell size can be dynamically configured based on the scene's scale, object density, and performance requirements. Smaller cell sizes can be used to improve accuracy in densely populated areas, while larger cell sizes can be used to save storage space in open areas. However, uniform division may require a fixed cell size, so this configuration can be determined before division.

[0131] In this embodiment, the virtual scene is uniformly divided according to a preset unit size, so that each location unit has a regular and predictable spatial position and index relationship. Therefore, when calculating the location unit to which a viewpoint belongs at runtime, only a simple division and rounding operation is required to directly locate the corresponding unit index, with an algorithm complexity of O(1). Compared with the O(N) complexity of non-uniform division requiring traversal or binary search, this embodiment significantly improves the query speed of location unit indexes, thereby providing an efficient and real-time spatial positioning foundation for subsequent visible set data loading and visibility determination, ultimately improving the rendering efficiency of the virtual scene, reducing memory overhead, and improving resource scheduling efficiency.

[0132] In an exemplary embodiment, obtaining the visible set data corresponding to the current location unit includes: Obtain the direction information of the current viewpoint; Based on the current position unit and orientation information, determine the visible set data corresponding to the current position unit and orientation information.

[0133] Directional information refers to the orientation angle of the viewpoint in space, which can include horizontal angles (e.g., rotation angles around the Y-axis) and pitch angles (e.g., vertical tilt angles). Visible set data refers to the set of objects or spatial units that can be observed from a specific viewpoint position and orientation angle. For the same location unit, its visible set may differ depending on the viewpoint's orientation; therefore, a unique corresponding visible set data can be determined based on both position and orientation.

[0134] For example, in addition to obtaining the current position cell of the current viewpoint, the terminal can also obtain the orientation of the viewpoint in world space, such as extracting the horizontal yaw angle and vertical pitch angle through the rotation Euler angles or orientation matrix of the virtual camera. Then, the terminal can use the index of the current position cell and the orientation information as a query key to retrieve the corresponding visible set data from a pre-stored visible set database. This database has already generated the corresponding visible set for different directional ranges of each position cell during the pre-computation stage.

[0135] As an example, during the pre-computation phase, for each location unit, 36 directional intervals are defined: horizontally, each interval is a sector (e.g., 0-30 degrees, 30-60 degrees, a total of 12 sectors); vertically, each interval is a level (e.g., -45-0 degrees, 0-45 degrees, a total of 3 levels). For each directional interval, the visible set originating from that location unit along typical directions within that interval is calculated. During runtime, if the current viewpoint's horizontal angle is 55 degrees and its pitch angle is 20 degrees, the horizontal angle is assigned to the 30-60 degree sector, and the pitch angle to the 0-45 degree level. The terminal uses the location unit index and the directional interval identifier as a union key to read the corresponding visible set data.

[0136] Optionally, the granularity of the orientation information can be adjusted according to accuracy requirements. For example, each sector can be divided into 15 degrees to improve orientation sensitivity, or it can be divided into only six directions: front, back, left, right, up, and down to reduce storage overhead. Alternatively, orientation information can be ignored and the set of all visible directions can be used as the default data.

[0137] In this embodiment, directional information is used as the query dimension for the visible set data, allowing the same location unit to correspond to different visible set data under different facing directions. This allows the runtime to accurately obtain the visible set for the current orientation based on the viewpoint's actual observation direction, avoiding over-visibility caused by using a full-directional visible set—that is, misjudgment resulting from anticipated visibility not actually being visible. Therefore, the accuracy of visibility determination is improved, unnecessary rendering object submissions are reduced, thereby further improving the rendering efficiency of the virtual scene, reducing memory overhead, and improving resource scheduling efficiency.

[0138] In some exemplary embodiments, multiple location units are obtained by uniformly dividing the virtual scene according to a preset unit size. Uniform division ensures that each location unit is an adjacent cube of equal size, allowing the location unit index to be directly calculated via coordinate division, achieving a query complexity of O(1). Specifically, let the side length of the location unit be L, and the viewpoint coordinates be (x, y, z), then the index is (floor(x / L), floor(y / L), floor(z / L)). floor() represents the floor function, which returns the largest integer not greater than the given value. The expression (floor(x / L), floor(y / L), floor(z / L)) as a whole means: calculate the ratio of each component of the spatial coordinate to the side length of the unit, and perform floor operation on each ratio, finally obtaining an ordered triplet consisting of three integer values, which is the three-dimensional index of the location unit to which the spatial coordinate belongs.

[0139] In some exemplary embodiments, obtaining the visible set data corresponding to the current position unit may further include: obtaining the direction information of the current viewpoint; and determining the visible set data corresponding to the current position unit and direction information based on the current position unit and direction information. That is, the visible set data depends not only on the viewpoint position but also on the viewpoint's orientation; different directions correspond to different visible sets. During pre-computation, for each position unit, it is further divided by direction (e.g., every 30 degrees is a directional sector), and the visible data under that direction is stored separately. During runtime, the corresponding visible set data is selected for querying based on the actual orientation of the current viewpoint.

[0140] In some exemplary embodiments, the information of static objects includes globally unique identifiers of the static objects; the information of other location units includes spatial indexes of the location units. The first type of data can be stored as a list of location unit indices or in the form of a compressed bitmap, and the second type of data can be stored as a hash set of unique identifiers.

[0141] In some exemplary embodiments, Figure 6 A flowchart illustrating an object removal method based on visible set data provided in this application embodiment is shown below. Figure 6 As shown, the method includes the following steps S601 to S607. Wherein: S601. Begin executing the visibility removal process for the target object.

[0142] S602. Perform a potential visible set culling step on the current viewpoint and the target object. The potential visible set culling step includes obtaining the corresponding visible set data based on the position unit and orientation information of the current viewpoint.

[0143] S603. Perform information transformation: convert the position coordinates of the current viewpoint into position unit indexes, convert the direction vector of the current viewpoint into direction indexes, and combine the two into a query key to locate the corresponding visible set from the visible set data.

[0144] S604. Query the pre-generated potential visible set data according to the query key to obtain the query results. The query results indicate whether the target object is visible from the current viewpoint.

[0145] S605. Determine the visibility status indicated by the query result: If it is determined to be visible, then execute the subsequent processing of the visible branch in S606; if it is determined to be invisible, then execute the subsequent processing of the invisible branch in S607.

[0146] Perform appropriate processing based on the visible state: S606. If the target object is visible, perform update and rendering operations on the target object. S607. If the target object is not visible, skip the update and rendering operations for the target object.

[0147] The potential visible set elimination step refers to the process of using pre-generated visible set data to determine whether an object is likely to be seen by the camera. Information transformation refers to the process of converting continuous spatial coordinates and orientation angles into discrete index values. The query key refers to a composite index used to uniquely identify a data record in the visible set database.

[0148] For example, for each target object to be rendered in the current frame, the terminal first calculates its corresponding position cell index and direction index based on the current viewpoint's position and direction, and combines them to generate a query key. Then, it uses this query key to search for the corresponding visible set from the pre-loaded visible set data. If the target object is a static object and its unique identifier exists in the queried second type of data, or if the target object is a dynamic object and its occupied position cell intersects with the queried first type of data, it is determined to be visible; otherwise, it is determined to be invisible. Based on the determination result, visible objects are submitted to the update queue and rendering pipeline, while invisible objects are discarded without consuming update and rendering resources.

[0149] As an example, during game runtime, for a building (static object) in the scene, the terminal obtains the current camera's location cell index (2,1,3) and direction index 5, combining them into a query key (2,1,3,5). The PVS data retrieves the static object identifier set corresponding to this key, which contains "Building_001". Since the building's identifier is also "Building_001", it is determined to be visible, and its update and rendering are performed. For another object completely obscured by a wall, its identifier is not in the retrieved set, so it is determined to be invisible, and subsequent updates and rendering are skipped.

[0150] Optionally, the potential visible set culling step in S602 can be cascaded with other culling methods (such as view frustum culling and distance culling) to perform coarse-grained culling first, followed by fine-grained culling based on PVS, in order to further improve performance.

[0151] In this embodiment, by means of... Figure 6 The complete culling process shown, from start to finish, organically combines information transformation, querying, conditional branching, and subsequent processing to form a standardized object visibility determination and processing workflow. This workflow utilizes pre-generated bimodal visibility set data that distinguishes between dynamic and static objects, ensuring the accuracy and efficiency of the determination. Invisible objects are promptly skipped from updates and rendering, effectively reducing the burden on the central processing unit and graphics processing unit, thereby improving the rendering efficiency of the virtual scene and reducing power consumption.

[0152] In some exemplary embodiments, when it is necessary to map spatial coordinates in the virtual scene to location cell indices during the pre-computation or runtime phases, the following steps can be taken: Obtain the preset cell size, denoted as the mesh edge length; obtain the 3D coordinates of any point; for the X-axis coordinate value of this point, perform a division operation by the mesh edge length, and round the quotient down to obtain the position cell index in the X-axis direction. Similarly, perform the same operation on the Y-axis and Z-axis coordinate values ​​respectively to obtain the position cell indices in the Y-axis and Z-axis directions. Thus, the 3D position cell index of this point is composed of these three integer values.

[0153] When it is necessary to recover the coordinates of the representative point of a cell from the cell index, the X-axis index is multiplied by the grid edge length to obtain the X coordinate value, the Y-axis index is multiplied by the grid edge length to obtain the Y coordinate value, and the Z-axis index is multiplied by the grid edge length to obtain the Z coordinate value. The coordinates obtained can represent the center point or corner point of the cell and are used for subsequent spatial calculations.

[0154] In some exemplary embodiments, when it is necessary to quantize the orientation of the current viewpoint to support direction-dependent visibility set queries, the following steps can be taken: Obtain the direction vector of the current viewpoint, which contains the horizontal X-axis and Z-axis components; call the arctangent function, with the Z-axis component as the first parameter and the X-axis component as the second parameter, to calculate the horizontal radian angle; the value range of this radian angle is from negative pi to pi; add pi to this radian angle to map it to the range of zero to twice pi.

[0155] Obtain the preset number of horizontal divisions, for example, 12 sectors. Multiply the mapped radian angle by this number of divisions, divide by twice pi, and round the result down to obtain the direction index. This direction index is used to uniquely identify the horizontal sector to which the current viewpoint is facing.

[0156] The X-axis index, Y-axis index, Z-axis index of the current position cell, and the direction index of the current viewpoint are combined into a quadruple, which serves as the query key. This query key is used to index the corresponding first-type or second-type data in the pre-generated visible set database.

[0157] In some exemplary embodiments, the visibility determination of dynamic objects at runtime can employ the following steps: Obtain the position coordinates and direction vector of the current viewpoint, as well as the center point and half-length vector of the axis-aligned bounding box of the dynamic object.

[0158] Calculate the spatial distance between the current viewpoint and the center point of the bounding box of the dynamic object. If this distance is less than a preset minimum detection distance threshold (e.g., 1 meter), the dynamic object is directly determined to be visible, and subsequent query steps are skipped. This threshold can be configured according to the scene size.

[0159] If the distance is not less than the threshold, then based on the position and direction of the current viewpoint, the position unit index and direction index of the current viewpoint are determined according to the aforementioned index calculation steps, and the two are combined into a query key.

[0160] Based on the query key, the corresponding set of visible location units is found from the pre-generated first type of data, and is denoted as the first set.

[0161] Based on the axis-aligned bounding box of the dynamic object, calculate the set of indices of all positional units covered by the bounding box in the virtual scene, denoted as the second set. Specifically, obtain the minimum and maximum corner points of the bounding box, calculate the positional unit indices of the two corner points respectively, and then take all integer index combinations between the two indices to form the coverage set.

[0162] Calculate the intersection of the first set and the second set. If the intersection is not empty, meaning there exists at least one location unit that belongs to both sets, then the dynamic object is considered visible; otherwise, it is considered invisible.

[0163] In some exemplary embodiments, the generated visible set data during the pre-computation phase can be stored in the following formats: For the overall storage method, all visible set data corresponding to position units and directions are stored in a single file. The first line of this file stores the total number of entries, indicating the number of visible set data entries contained in the file. Starting from the second line, each line corresponds to the visible set data for a query key. The record format of each line is as follows: first, the X-axis index, Y-axis index, Z-axis index, and direction index of the position unit are stored sequentially; then, the number of elements in that visible set is stored; finally, that number of elements are stored sequentially. When storing the first type of data, each element is a three-dimensional index of a position unit, which can be represented as a tuple of three integer values. When storing the second type of data, each element is a globally unique identifier for a static object.

[0164] For the fragmented storage method, the virtual scene is divided into spatial regions, each corresponding to a fixed-size cube (e.g., containing 8×8×8 location units). All visible set data within each spatial region is stored as a separate file, with the file name containing the spatial index information of that region. The internal storage format of each fragment file is the same as the overall storage file format, but it only contains the visible set data of the location units covered by that spatial region.

[0165] During runtime, the terminal calculates the spatial region index based on the current viewpoint position and loads only the fragment files within that region and its surrounding predetermined range. When viewpoint movement causes a change in the current region, the fragment files for the new region are dynamically loaded via asynchronous input / output threads, and fragment files for regions outside the specified range are unloaded.

[0166] In some exemplary embodiments, for static object visible collection data (i.e., the second type of data), the record format of each line in the storage file is as follows: the X-axis index, Y-axis index, Z-axis index and direction index of the position unit are stored in sequence, then the number of static object identifiers visible under the query key is stored, and finally the number of globally unique identifiers of static objects is stored in sequence.

[0167] At runtime, for a target object with a static tag, its pre-assigned globally unique identifier is obtained, and a query key is generated based on the current viewpoint's position unit and direction index. Then, the set of static object identifiers corresponding to this query key is searched from the second type of data. If the target object's unique identifier exists in this set, the static object is determined to be visible; otherwise, it is determined to be invisible.

[0168] In some exemplary embodiments, test results show that this application can effectively reduce the number of map drawing calls in different areas by 100 to 350, a reduction of about 20% to 70%, and can improve frame rate and reduce heat generation on mobile devices.

[0169] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0170] The following describes the virtual scene object rendering apparatus provided in the embodiments of this application. The virtual scene object rendering apparatus has the same inventive concept as the virtual scene object rendering method described above. The solution to the problem provided by the apparatus is similar to the solution described in the above method. Therefore, the specific limitations of one or more virtual scene object rendering apparatus embodiments provided below can be referred to the limitations of the virtual scene object rendering method above. The virtual scene object rendering apparatus described below and the virtual scene object rendering method described above can be referred to each other, and will not be repeated here.

[0171] In one exemplary embodiment, Figure 7 This is a schematic diagram of the structure of an object rendering device for a virtual scene provided in an embodiment of this application, as shown below. Figure 7 As shown, the object rendering device 70 for the virtual scene includes: a viewpoint position acquisition module 710, a visibility set acquisition module 720, a visibility determination module 730, and a rendering execution module 740, wherein: The viewpoint position acquisition module 710 is used to acquire the current position unit of the current viewpoint in the virtual scene, wherein the virtual scene is pre-divided into multiple position units.

[0172] The visible set acquisition module 720 is used to acquire the visible set data corresponding to the current position unit. The visible set data includes: a first type of data and a second type of data. The first type of data is used to record other position units visible from the current position unit, and the second type of data is used to record information about static objects visible from the current position unit.

[0173] The visibility determination module 730 is used to determine the object type of the target object to be rendered in the virtual scene. The object type includes dynamic objects or static objects. Based on the object type, the visibility state of the target object is determined using second type data or first type data. Static objects correspond to the second type data, and dynamic objects correspond to the first type data.

[0174] The rendering execution module 740 is used to perform rendering operations on the target object if it is determined that the target object is visible.

[0175] In an exemplary embodiment, the visibility determination module 730 is used to obtain at least one position unit occupied by a dynamic object in a virtual scene; if the at least one position unit occupied by the dynamic object intersects with other position units of the first type of data record, the dynamic object is determined to be visible.

[0176] In an exemplary embodiment, the visibility determination module 730 is used to obtain the unique identifier of the static object; if the unique identifier exists in the second type of data, the static object is determined to be visible.

[0177] In an exemplary embodiment, the visible set acquisition module 720 is used to acquire the region type marker of each location unit, the region type marker being used to indicate whether the location unit allows dynamic objects to enter; for location units marked as allowing dynamic objects to enter, a first type of data is generated; for location units marked as not allowing dynamic objects to enter, a second type of data is generated.

[0178] In one exemplary embodiment, the region type label is generated by receiving manually generated labels through the scene editor; and / or, when there is no object whose position change exceeds a preset threshold within a location unit, the location unit is marked as not allowing dynamic objects to enter.

[0179] In an exemplary embodiment, the apparatus further includes: a visible set storage module for storing visible set data of multiple location units in segments according to spatial regions, wherein each segment corresponds to a continuous spatial region containing a preset number of location units.

[0180] In one exemplary embodiment, the apparatus further includes: a visible set loading module for loading visible set data fragments corresponding to a spatial region within a preset range around the current position, based on the current position of the virtual camera or virtual character during runtime; and a visible set unloading module for unloading visible set data fragments corresponding to spatial regions exceeding the preset range.

[0181] In an exemplary embodiment, the visible set loading module is specifically used to obtain a first distance between the spatial region and the current position of the virtual camera or virtual character, as well as the number of currently loaded segments; if the first distance exceeds a preset first distance threshold, and the number of currently loaded segments exceeds a preset number threshold, then the spatial set corresponding to the spatial region is unloaded.

[0182] In an exemplary embodiment, the visible set loading module is further configured to predict the future location of a virtual camera or virtual character; and load visible set data fragments corresponding to a spatial region within a preset range around the future location.

[0183] In an exemplary embodiment, the visible set loading module is used to obtain the current movement direction vector and current movement speed of the virtual camera or virtual character; and calculate the future position based on the current movement direction vector, current movement speed and preset time step.

[0184] In one exemplary embodiment, the visible set loading module is used to detect the release operation of the displacement skill of a virtual camera or virtual character; and to obtain the endpoint position of the displacement skill as the future position.

[0185] In an exemplary embodiment, the visible set acquisition module 720 is used to perform a ray projection or occlusion query operation starting from the location unit; and to determine other location units or static objects visible to the current location unit based on the result of the ray projection or occlusion query operation.

[0186] In an exemplary embodiment, the visible set acquisition module 720 is further configured to generate visible set data for each location unit in parallel using a multi-threaded task system and / or a distributed computing system.

[0187] In an exemplary embodiment, the visibility determination module 730 is further configured to obtain a second distance between the current viewpoint and the target object, and if the second distance is less than a preset second distance threshold, the target object is determined to be visible.

[0188] In an exemplary embodiment, multiple position units are regular three-dimensional grids of equal size. The viewpoint position acquisition module 710 is specifically used to acquire the spatial coordinates of the current viewpoint, normalize the spatial coordinates according to the preset unit size, and obtain the index of the current position.

[0189] In an exemplary embodiment, the visible set acquisition module 720 is used to acquire the direction information of the current viewpoint; and determine the visible set data corresponding to the current position unit and direction information based on the current position unit and direction information.

[0190] The various modules in the aforementioned virtual scene object rendering device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0191] In one exemplary embodiment, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the object rendering method for any of the virtual scenes described above.

[0192] In one exemplary embodiment, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the object rendering method for any of the virtual scenes described in the above embodiments.

[0193] In one exemplary embodiment, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of an object rendering method for any of the virtual scenes described in the above embodiments.

[0194] Indicatively, such as Figure 8 As shown, Figure 8 This is a schematic diagram of the internal structure of a computer device 800 provided in an embodiment of this application. The computer device 800 can be provided as a server. (Refer to...) Figure 8 The computer device 800 includes a processor 802, which further includes one or more processors, and memory resources represented by memory 801 for storing instructions executable by the processor 802, such as a computer program. The computer program stored in memory 801 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processor 802 is configured to execute instructions to perform object rendering methods for virtual scenes in any of the above embodiments. The computer device 800 can operate on an operating system stored in memory 801, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0195] The computer device 800 may also include a power supply component 803 configured to perform power management of the computer device 800, a wired or wireless network interface 804 configured to connect the computer device 800 to a network, and an input / output (I / O) interface 805. Wireless operation may be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a virtual scene object rendering method. The display unit 807 of the computer device is used to form a visually visible image and may be a display screen, a projection device, or a virtual reality imaging device. The display screen may be an LCD screen or an e-ink display screen. The input device 806 of the computer device may be a touch layer covering the display screen, or buttons, a trackball, or a touchpad located on the computer device casing, or an external keyboard, touchpad, or mouse, etc.

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

[0197] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0198] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0199] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0200] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for rendering objects in a virtual scene, characterized in that, The method includes: Obtain the current position unit of the current viewpoint in the virtual scene, wherein the virtual scene is pre-divided into multiple position units; Obtain the visible set data corresponding to the current position unit. The visible set data includes: a first type of data and a second type of data. The first type of data is used to record other position units visible from the current position unit, and the second type of data is used to record information about static objects visible from the current position unit. The object type of the target object to be rendered in the virtual scene is determined, and the object type includes dynamic objects or static objects; according to the object type, the visibility state of the target object is determined using the second type of data or the first type of data, wherein the static object corresponds to the second type of data and the dynamic object corresponds to the first type of data; If the target object is determined to be visible, then a rendering operation is performed on the target object.

2. The method according to claim 1, characterized in that, Determining the visibility state of the dynamic object using the first type of data includes: Obtain at least one position unit occupied by the dynamic object in the virtual scene; If at least one location unit occupied by the dynamic object intersects with other location units of the first type of data record, then the dynamic object is determined to be visible.

3. The method according to claim 1, characterized in that, Determining the visibility state of the static object using the second type of data includes: Obtain the unique identifier of the static object; If the unique identifier exists in the second type of data, then the static object is determined to be visible.

4. The method according to claim 1, characterized in that, The method further includes: Obtain the region type marker for each of the location units, the region type marker being used to indicate whether the location unit allows dynamic objects to enter; For location units marked as allowing dynamic objects to enter, the first type of data is generated; For location units marked as not allowing dynamic objects to enter, the second type of data is generated.

5. The method according to claim 4, characterized in that, The region type marker is generated by receiving manually marked markers through the scene editor; And / or, when there is no object in a location unit whose position change exceeds a preset threshold, the location unit is marked as not allowing dynamic objects to enter.

6. The method according to claim 1, characterized in that, The method further includes: The visible set data of multiple location units is stored in segments according to spatial regions. Each segment corresponds to a continuous spatial region containing a preset number of location units.

7. The method according to claim 6, characterized in that, The method further includes: During runtime, based on the current position of the virtual camera or virtual character, the visible set data fragments corresponding to the spatial area within a preset range around the current position are loaded; Unload the visible set data fragments corresponding to the spatial regions that exceed the preset range.

8. The method according to claim 7, characterized in that, The unloading of visible set data fragments corresponding to spatial regions exceeding the preset range includes: Obtain the first distance between the spatial region and the current position of the virtual camera or virtual character, as well as the number of currently loaded segments; If the first distance exceeds a preset first distance threshold, and the number of currently loaded fragments exceeds a preset number threshold, then the spatial set corresponding to the spatial region is unloaded.

9. The method according to claim 7, characterized in that, The method further includes: Predict the future location of the virtual camera or the virtual character; Load the visible set data fragments corresponding to the spatial region within a preset range around the future location.

10. The method according to claim 9, characterized in that, Predicting the future location of the virtual camera or the virtual character includes: Obtain the current movement direction vector and current movement speed of the virtual camera or the virtual character; The future position is calculated based on the current movement direction vector, the current movement speed, and the preset time step.

11. The method according to claim 9, characterized in that, Predicting the future location of the virtual camera or the virtual character includes: Detect the movement skill release operation of the virtual camera or the virtual character; The endpoint of the displacement skill is obtained as the future position.

12. The method according to claim 1, characterized in that, The step of obtaining the visible set data corresponding to the current location unit includes: Starting from the location unit, perform a light projection or occlusion query operation; Based on the result of the light projection or occlusion query operation, other location units or static objects visible to the current location unit are determined.

13. The method according to claim 1, characterized in that, The method further includes: A multi-threaded task system and / or a distributed computing system are used to generate visible set data for each of the aforementioned location units in parallel.

14. The method according to claim 1, characterized in that, Before determining the visibility state of the target object, the method further includes: Obtain the second distance between the current viewpoint and the target object. If the distance is less than a preset second distance threshold, then determine that the target object is visible.

15. The method according to claim 1, characterized in that, The plurality of position units are regular three-dimensional grids of equal size. The step of obtaining the current position unit of the current viewpoint in the virtual scene includes: Obtain the spatial coordinates of the current viewpoint, normalize the spatial coordinates according to a preset unit size, and obtain the index of the current position.

16. The method according to claim 1, characterized in that, The step of obtaining the visible set data corresponding to the current location unit includes: Obtain the direction information of the current viewpoint; Based on the current position unit and the direction information, determine the visible set data corresponding to the current position unit and the direction information.

17. An object rendering device for a virtual scene, characterized in that, The device includes: The viewpoint position acquisition module is used to acquire the current position unit of the current viewpoint in the virtual scene, wherein the virtual scene is pre-divided into multiple position units; The visible set acquisition module is used to acquire the visible set data corresponding to the current position unit. The visible set data includes: a first type of data and a second type of data. The first type of data is used to record other position units visible from the current position unit, and the second type of data is used to record information about static objects visible from the current position unit. The visibility determination module is used to determine the object type of the target object to be rendered in the virtual scene, the object type including dynamic objects or static objects; according to the object type, the visibility state of the target object is determined using the second type of data or the first type of data, wherein the static object corresponds to the second type of data and the dynamic object corresponds to the first type of data; The rendering execution module is used to perform rendering operations on the target object if it is determined that the target object is visible.

18. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 16.

19. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 16.

20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 16.

Images