Method for generating scene visibility data, scene loading method and device

Abstract

The application discloses a scene visibility data generation method and device and a scene loading method, and belongs to the technical field of computers. The application obtains OC data used for visibility determination by locally baking the associated regions of a PVS checkpoint in a virtual world, and uses the OC data to determine the visibility of each PVS unit in the PVS checkpoint to each associated region, so that the generated scene visibility data records the visibility of each associated region to each PVS unit, thereby making it possible to conveniently determine, through the scene visibility data, which scene regions in the periphery that need not be loaded when a virtual object is in a PVS unit, providing a screening method for the periphery scene regions, reducing the number of scene regions that need to be loaded in real time in a scene streaming loading and unloading technology, greatly improving the scene real-time loading efficiency, reducing the consumption of terminal running memory by a game application, and thereby improving the processing performance of the terminal.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for generating scene visibility data, a scene loading method, and an apparatus. Background Technology

[0002] With the development of computer technology, playing games has become a widespread form of entertainment. In some seamless open-world games, the terminal typically loads only a portion of the scene surrounding the virtual object, based on the position of the user-controlled virtual object in the virtual world each frame.

[0003] However, since there may be multiple scene areas around virtual objects, the total scene data of these scene areas will put a heavy burden on the terminal, consume a lot of the game application's running memory, and result in low real-time scene loading efficiency, affecting the terminal's processing performance. Summary of the Invention

[0004] This application provides a method for generating scene visibility data, a scene loading method, and an apparatus, which can reduce the number of scene regions loaded in real time, thereby reducing the consumption of game application runtime memory, improving scene real-time loading efficiency, and optimizing terminal processing performance. The technical solution is as follows:

[0005] On the one hand, a method for generating scene visibility data is provided, the method comprising:

[0006] For any one of the multiple visibility detection partitions in the virtual world, determine at least one associated region of the visibility detection partition from the multiple scene regions of the virtual world;

[0007] Baking is performed on the at least one associated region to obtain occlusion clipping data for the at least one associated region, the occlusion clipping data indicating the visibility of virtual objects located in the associated region;

[0008] For any visibility detection unit in the visibility detection partition, based on the occlusion and clipping data of the at least one associated region, unit visibility data of the visibility detection unit to the at least one associated region is generated, and the unit visibility data indicates whether the associated region is globally visible to the visibility detection unit;

[0009] Based on the unit visibility data of each visibility detection unit, the scene visibility data of the visibility detection partition is obtained.

[0010] On the one hand, a scene loading method based on scene visibility data is provided, the method comprising:

[0011] Based on the location of the controlled virtual object in the virtual world, at least one region to be loaded in the virtual world is determined;

[0012] Access the scene visibility data of the visibility detection partition to which the target detection unit where the controlled virtual object is located belongs, so as to obtain the unit visibility data of at least one associated region of the visibility detection partition of the target detection unit, wherein the unit visibility data indicates whether the associated region is globally visible to the target detection unit;

[0013] Based on the unit visibility data, determine the visibility of the at least one region to be loaded to the controlled virtual object;

[0014] From the at least one region to be loaded, remove the regions from the unit visibility data that indicate that the controlled virtual object is not visible.

[0015] On the one hand, a device for generating scene visibility data is provided, the device comprising:

[0016] The determination module is used to determine at least one associated region of any one of the multiple visibility detection zones in the virtual world from multiple scene regions of the virtual world.

[0017] A baking module is used to bake the at least one associated region to obtain occlusion and clipping data of the at least one associated region, wherein the occlusion and clipping data indicates the visibility of virtual objects located in the associated region;

[0018] A generation module is used to generate unit visibility data of any visibility detection unit in the visibility detection partition based on the occlusion and clipping data of the at least one associated region. The unit visibility data indicates whether the associated region is globally visible to the visibility detection unit.

[0019] The acquisition module is used to acquire scene visibility data of the visibility detection partition based on the unit visibility data of each visibility detection unit.

[0020] In some embodiments, the generation module includes:

[0021] The determining unit is configured to determine the starting index value and the ending index value of any of the associated regions;

[0022] A query unit is used to query the visibility of each virtual object whose index value is located between the start index value and the end index value from the occlusion and cropping data;

[0023] A configuration unit is used to configure the visibility detection unit to the visibility of the associated region based on the visibility of each virtual object obtained from the query.

[0024] A generation unit is used to generate the unit visibility data based on the visibility of each associated region by the visibility detection unit.

[0025] In some embodiments, the determining unit is used to:

[0026] The offset compensation amount of the associated region in the occlusion clipping data is determined as the starting index value;

[0027] The offset compensation amount of the next associated region in the occlusion clipping data is determined as the termination index value.

[0028] In some embodiments, each bit in the occlusion and clipping data records the visibility of a virtual object, and the bit corresponds one-to-one with an index value; the query unit is used for:

[0029] For the occlusion clipping data, starting from the starting bit indicated by the starting index value, the visibility of the virtual object recorded in each bit is traversed until the ending bit indicated by the ending index value is reached.

[0030] In some embodiments, the configuration unit is used for:

[0031] If the visibility of all the virtual objects obtained from the query indicates that they are not visible, then the visibility of the associated region will be configured to be invisible.

[0032] If the visibility indication of any virtual object obtained from the query is visible, configure the visibility of the associated region to be visible.

[0033] In some embodiments, the generating unit is used for:

[0034] Configure the visibility detection unit with initialized unit visibility data, wherein each bit in the unit visibility data records the visibility of an associated region, and the index value of each bit is the region identifier of the associated region recorded by the bit;

[0035] In the unit visibility data, the bit indicated by the region identifier of each associated region is assigned a value based on the visibility of each associated region.

[0036] In some embodiments, the determining module is used to:

[0037] For any of the scene regions, the loading distance of the scene category is determined based on the scene category of the scene region;

[0038] Based on the loading distance, the bounding box range of the visibility detection partition is expanded to obtain the first bounding box range;

[0039] When the first bounding box range intersects with the second bounding box range of the scene region, the scene region is determined as an associated region.

[0040] In some embodiments, the acquisition module is used to:

[0041] The unit visibility data of each visibility detection unit is merged to obtain the scene visibility data of the visibility detection partition, and the scene visibility data is associated with and stored with the visibility detection partition.

[0042] On the one hand, a scene loading device based on scene visibility data is provided, the device comprising:

[0043] The region determination module is used to determine at least one region to be loaded in the virtual world based on the location of the controlled virtual object in the virtual world;

[0044] An access module is used to access scene visibility data of the visibility detection partition to which the target detection unit where the controlled virtual object is located belongs, so as to obtain unit visibility data of at least one associated region of the visibility detection partition, wherein the unit visibility data indicates whether the associated region is globally visible to the target detection unit.

[0045] A visibility determination module is used to determine the visibility of the at least one region to be loaded to the controlled virtual object based on the unit visibility data;

[0046] A removal module is used to remove, from the at least one region to be loaded, regions from which the unit visibility data indicates that the controlled virtual object is not visible.

[0047] In some embodiments, the visibility determination module is used to:

[0048] For any of the regions to be loaded, the region identifier of the region to be loaded is used as the index value. The bit indicated by the index value is queried in the unit visibility data to obtain the visibility of the region to be loaded to the controlled virtual object.

[0049] On one hand, a computer device is provided, the computer device including one or more processors and one or more memories, the one or more memories storing at least one computer program, the at least one computer program being loaded and executed by the one or more processors to implement a method for generating scene visibility data or a scene loading method based on scene visibility data as described in any of the above possible implementations.

[0050] On one hand, a computer-readable storage medium is provided, which stores at least one computer program, which is loaded and executed by a processor to implement a method for generating scene visibility data or a method for loading scene based on scene visibility data, as described in any of the above possible implementations.

[0051] On one hand, a computer program product is provided, comprising one or more computer programs stored in a computer-readable storage medium. One or more processors of a computer device are capable of reading the one or more computer programs from the computer-readable storage medium, and the one or more processors execute the one or more computer programs, enabling the computer device to execute the scene visibility data generation method or the scene loading method based on scene visibility data according to any of the above possible embodiments.

[0052] The beneficial effects of the technical solutions provided in this application include at least the following:

[0053] By partially baking only the associated regions of a PVS level within a virtual world's visibility detection partition, occlusion and clipping data (OC data) for visibility determination can be obtained. This OC data is then used to determine the visibility of each PVS unit to each associated region within the PVS level, further generating overall scene visibility data for the PVS level. This allows the scene visibility data to record the visibility of each associated region of the PVS level to each PVS unit. This makes it easy to determine the visibility of each associated region of the PVS level to any PVS unit, facilitating decisions about which surrounding scene regions a virtual object does not need to load when it is within a PVS unit. Based on PVS technology, a method for filtering surrounding scene regions is provided. Therefore, based on the generated scene visibility data, the number of scene regions that need to be loaded in real-time during scene streaming loading and unloading technology is reduced, significantly improving real-time scene loading efficiency, reducing the consumption of terminal memory by game applications, and thus improving terminal processing performance. Attached Figure Description

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

[0055] Figure 1 This is a schematic diagram of the implementation environment of a method for generating scene visibility data provided in an embodiment of this application;

[0056] Figure 2 This is a flowchart of a method for generating scene visibility data provided in an embodiment of this application;

[0057] Figure 3 This is a flowchart of a method for generating scene visibility data provided in an embodiment of this application;

[0058] Figure 4 This is a flowchart illustrating a method for determining the correlation between a scene region and a visibility detection partition, as described in an embodiment of this application.

[0059] Figure 5 This is a flowchart of a method for generating scene visibility data provided in an embodiment of this application;

[0060] Figure 6 This is a schematic diagram of block storage of PVS OC data provided in an embodiment of this application;

[0061] Figure 7 This is a flowchart of a scene loading method based on scene visibility data provided in an embodiment of this application;

[0062] Figure 8 This is a flowchart of a scheme for optimizing LevelStreaming based on PVS provided in an embodiment of this application;

[0063] Figure 9 This is a test result diagram of a scheme for optimizing LevelStreaming based on PVS according to an embodiment of this application;

[0064] Figure 10 This is a schematic diagram of the structure of a scene visibility data generation device provided in an embodiment of this application;

[0065] Figure 11 This is a schematic diagram of the structure of a scene loading device based on scene visibility data provided in an embodiment of this application;

[0066] Figure 12 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application;

[0067] Figure 13 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation

[0068] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0069] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor are there any restrictions on quantity or execution order.

[0070] In this application, the term "at least one" means one or more, and "multiple" means two or more. For example, multiple scene areas in a virtual world means two or more scene areas in a virtual world.

[0071] The term "including at least one of A or B" in this application refers to the following situations: including only A, including only B, and including both A and B.

[0072] The user-related information (including but not limited to user device information, personal information, behavioral information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in this application, when applied to specific products or technologies using the methods of the embodiments of this application, are all obtained with the user's permission, consent, authorization, or full authorization from all parties, and the collection, use, and processing of related information, data, and signals must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the virtual world scene data involved in this application were obtained under full authorization.

[0073] Virtual world: A virtual environment or virtual scene displayed (or provided) by an application when it runs on a terminal. This virtual world is a simulation of the real world, a semi-simulated / semi-fictional virtual environment, or a purely fictional virtual environment. Optionally, the virtual world can be any of a two-dimensional virtual space, a 2.5-dimensional virtual space, or a three-dimensional virtual space; this application embodiment does not limit the dimensions of the virtual world. For example, the virtual world includes the sky, land, and ocean, and the land includes environmental elements such as deserts and cities. Users can control virtual objects to move within this virtual world.

[0074] Virtual objects refer to movable objects in a virtual world. These include virtual characters, animals, and anime characters. Examples include people, animals, plants, oil drums, walls, and stones displayed in a virtual world. A virtual object is a virtual representation of the user within that virtual world. Typically, a virtual world contains multiple virtual objects, each with its own shape and volume, occupying a portion of the virtual world's space.

[0075] Optionally, the virtual object can be a player character controlled through client-side operations, an AI (Artificial Intelligence) object trained and set in the virtual world, or an NPC (Non-Player Character) object set in the virtual world. For example, the virtual object can be a virtual character competing in the virtual world. Optionally, the number of virtual objects participating in the interaction in the virtual world can be preset or dynamically determined based on the number of clients joining the interaction.

[0076] With the development of computer technology, playing games has become a widespread form of entertainment. In some seamless open-world games, the terminal typically loads only a portion of the scene surrounding the virtual object, based on the position of the user-controlled virtual object in the virtual world each frame.

[0077] However, since there may be multiple scene areas around virtual objects, the total scene data of these scene areas will put a heavy burden on the terminal, consume a lot of the game application's running memory, and result in low real-time scene loading efficiency, affecting the terminal's processing performance.

[0078] In view of this, the embodiments of this application consider that from the perspective of the virtual object, the scene areas around the virtual object may have occlusion relationships with each other. That is, the scene areas around the virtual object are not entirely visible to the virtual object. There are visible scene areas and invisible scene areas around the virtual object (such as being completely occluded by some virtual buildings, resulting in invisibility). Therefore, a method for generating scene visibility data is designed. Scene visibility data is configured for all visibility detection partitions in the virtual world, and the scene visibility data of each visibility detection partition is stored on the terminal side. Thus, when the game application is running in real time on each terminal, based on the position of the controlled virtual object controlled by the terminal, after finding the surrounding areas to be loaded, the invisible areas to be loaded are eliminated based on the scene visibility data. This can greatly reduce the number of areas to be loaded in real time, thereby improving the real-time scene loading efficiency, reducing the memory consumed by the terminal for the game application, and improving the processing performance of the terminal.

[0079] The following is an explanation of the terms used in this application.

[0080] Game engine: Refers to the core components of pre-written, editable computer game systems or interactive real-time graphics applications. These systems provide game designers with a variety of tools needed to write games, aiming to allow them to easily and quickly create game programs without starting from scratch. A game engine includes the following systems: rendering engine (i.e., "renderer," including 2D and 3D graphics engines), physics engine, collision detection system, sound effects, scripting engine, computer animation, artificial intelligence, network engine, and scene management.

[0081] Unreal Engine (UE): An industry-leading game engine developed by the game company EPIC. It is a complete game development platform for next-generation game consoles and DirectX 9 PCs, providing game developers with a large number of core technologies, data generation tools and basic support.

[0082] The UE provides navigation functionality (also known as pathfinding). The basic goal of navigation is to generate a reachable path from the starting point to the target point for a virtual object in the virtual world, given a starting point and a target point. Common pathfinding methods include: based on waypoints (PathNode), based on navigation mesh (NavMesh), and based on potential fields, etc.

[0083] RecastNavigation is a powerful pathfinding system widely used in major game engines (such as Unity and UE4). It's a popular in-game navigation solution based on virtual scenes. In other words, RecastNavigation is a navigation and pathfinding toolset that uses a set of adjacent convex polygons to describe a 3D virtual scene. The A* pathfinding algorithm ensures the reachability of the 3D virtual scene. The RecastNavigation system has the following features: it can represent a 3D virtual scene; it can assign 3D coordinate attributes to game objects with near-precise accuracy; it can determine the reachability of two points on the 3D scene surface; and it can dynamically change the 3D scene terrain.

[0084] NavMesh: A data structure that fills the walkable area of ​​a virtual world provided by the game. NavMesh indicates the walkable area of ​​a virtual object in the virtual world. The unit of NavMesh is called Poly (i.e., Polygon), which is the basic pathfinding unit of the RecastNavigation system.

[0085] Occlusion Cull (OC): OC refers to object-based occlusion culling. In real-time rendering, hidden culling (discarding triangles facing away from the viewer) is used to improve rendering speed. However, in large-scale scenes, occlusion between models is common, resulting in many occluded models performing meaningless shading calculations. In this case, hidden culling can only ensure that the back of the occluded object is not rendered, but it cannot prevent the front from still undergoing invalid calculations. OC technology was proposed to solve this problem by discarding the entire occluded object (including hundreds or thousands of triangles) to further improve rendering speed.

[0086] Precomputed Visibility Set (PVS): The UE provides a precomputed occlusion culling system for rendering optimization in real-time graphics, offering good real-time game interaction performance on mobile platforms. During implementation, the precomputed occlusion culling system solves for a potential visible set offline and obtains a converged set of the potential visible set, the extra visible set, through progressive prediction. In this application embodiment, the PVS refers to the extra visible set obtained from the above prediction.

[0087] Precomputed Visibility Set Level (PVSLevel): In a precomputed occlusion culling system, the virtual world is divided into multiple visibility set levels, and each visibility set level is further divided into multiple visibility units. These visibility set levels are also known as PVS levels.

[0088] A Precomputed Visibility Cell (PVSCell) is the basic unit for visibility detection in a precomputed occlusion culling system. For each PVSCell, based on its position, it calculates whether a virtual object within the PVSCell can see virtual objects within the surrounding scene area. In other words, the visibility of virtual objects within the surrounding scene area is calculated based on the PVSCell's position. The PVSCell is also known as a PVS unit.

[0089] Specifically, in the pre-computation occlusion culling system, each PVS unit pre-calculates what virtual objects the virtual objects in that PVS unit can see and what virtual objects they cannot see. After serializing the OC data obtained from these visibility calculations, it can be saved and packaged into the game application. When the game application is running, based on the current position of the camera attached to the controlled virtual object, it reads the OC data of the PVS unit where the current position is located and submits the visibility recorded in the OC data to the CPU (Central Processing Unit). The CPU determines which virtual objects need to be submitted to the GPU (Graphics Processing Unit) for drawing and rendering based on the OC data. In other words, the CPU performs OC detection based on the OC data. Only visible objects that pass the OC detection will be submitted to the GPU to perform the subsequent drawing and rendering process. Virtual objects that do not pass the OC detection will not participate in the drawing and rendering process.

[0090] Scene Level: For seamless open worlds, to facilitate scene loading, a seamless virtual world is usually divided into multiple scene levels (also known as maps, levels, etc.). A scene level is the unit for scene loading. It's important to note that the division methods for scene levels and visibility detection partitions are unrelated. A scene level is the unit for scene loading, while a visibility detection partition is the unit for visibility detection. They are typically divided based on different logics. For example, a scene level may be divided into multiple visibility detection partitions, and a visibility detection partition may be associated with multiple scene levels (in this embodiment, associated scene levels are referred to as associated levels).

[0091] Level bounding boxes: refer to the smallest cube that can enclose all virtual objects within a level or PVS level. For scene regions, each scene region (i.e., level) has its own level bounding box. For visibility detection partitions, each visibility detection partition (i.e., PVS level) has its own PVS level bounding box.

[0092] Level Streaming: A technique for implementing seamless open-world scene loading and unloading. It dynamically loads new surrounding scene areas and unloads older, more distant scene areas based on the position of virtual objects in the virtual world for each frame.

[0093] Zlib algorithm: A data compression algorithm applicable to all platforms, providing a library of functions for data compression.

[0094] GameThread: One of the threads used in a game application when multithreading is employed. It is used to maintain the main game business logic and can be used to implement the creation / destruction logic of virtual objects, virtual items, etc.

[0095] RenderThread: One of the threads used in a game application when multithreading is employed, used for non-hardware-level rendering instruction processing logic.

[0096] The system architecture of the embodiments of this application will be described below.

[0097] Figure 1 This is a schematic diagram illustrating the implementation environment of a method for generating scene visibility data provided in an embodiment of this application. See also... Figure 1 In this implementation environment, a terminal 101 and a server 102 are involved. The terminal 101 and the server 102 are directly or indirectly connected through wired or wireless communication, which is not limited herein.

[0098] Terminal 101 has installed and runs game applications or cloud gaming applications that support virtual worlds. Optionally, the game applications or cloud gaming applications include: MMOG (Massive Multiplayer Online Game), MMORPG (Massive Multiplayer Online Role-Playing Game), MOBA (Multiplayer Online Battle Arena) games, shooting games, virtual reality applications, 3D mapping programs, multiplayer survival games with equipment, etc.

[0099] In some embodiments, terminal 101 is a computer device used by a user. When terminal 101 runs a game application, taking a seamless open-world game as an example, in response to the user's initial operation triggered in the game application, terminal 101 does not need to load the entire scene area of ​​the virtual world at once. It can use the scene streaming loading and unloading LevelStreaming technology to dynamically load the scene area around the virtual object in the virtual world according to the position of the virtual object controlled by terminal 101, and unload the scene area not around the virtual object, so as to improve the scene loading efficiency.

[0100] Server 102 includes at least one of the following: a single server, multiple servers, a cloud computing platform, or a virtualization center. Server 102 provides backend services for game applications supporting the virtual world, and it provides the basic gameplay logic. Optionally, server 102 undertakes the main game logic operations, and terminal 101 undertakes secondary game logic operations; or, server 102 undertakes secondary game logic operations, and terminal 101 undertakes the main game logic operations; or, server 102 and terminal 101 collaborate on game logic operations using a distributed computing architecture.

[0101] Optionally, server 102 may be an independent physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0102] In an exemplary scenario, a GameSvr process is created in server 102 to provide the basic gameplay logic of the game. Correspondingly, when terminal 101 runs the game application, a game thread (GameThread) and a rendering thread (RenderThread) are created. The game thread (GameThread) is used to maintain the main game business logic, and the rendering thread (RenderThread) is used for non-hardware-level rendering instruction processing logic.

[0103] For traditional game applications, server 102 performs offline baking (such as baking on one machine or distributed online baking on multiple machines) on each visibility detection partition, i.e., PVS level, based on the scene visibility data generation method provided in the embodiments of this application, to generate scene visibility data for each PVS level. The scene visibility data of each PVS level, together with OC data, is saved and packaged into the game application. After the terminal 101 installs the game application, it will download the compressed OC data and scene visibility data of each PVS level to its local machine. During the operation of the game application, the GameThread on the terminal 101 side calculates the position of the controlled virtual object in the virtual world in each frame. Optionally, the GameThread on the terminal 101 side determines the scene loading list of the current frame based on the position of the controlled virtual object in the current frame through LevelStreaming logic. Then, based on the scene loading method based on scene visibility data provided in the embodiments of this application, for each region to be loaded in the scene loading list, its visibility recorded in the scene visibility data is accessed to determine whether this region to be loaded is visible to the visibility detection unit, i.e., the PVS unit, where the controlled virtual object is located. If it is not visible, it means that it does not contribute to the game screen of the current frame, and this region to be loaded is removed from the scene loading list. After traversing the entire scene loading list, all invisible regions can be removed. In other words, the GameThread processes the visibility determination of scene regions and implements the loading and unloading of scene regions. Next, the GameThread submits the final scene loading list to the RenderThread. The RenderThread then performs Objective-C (OC) detection on each virtual object in the remaining unloaded area after culling. Virtual objects that pass OC detection are submitted to the RHI (Render Hardware Interface) thread, which in turn drives the GPU's rendering pipeline to render these OC-detected objects, resulting in the game screen for the current frame. It's worth noting that, in addition to this, the GameThread on terminal 101 can also synchronize the position of the controlled virtual objects in the current frame to the GameSvr process on server 102. This allows the GameSvr process on server 102 to perform basic gameplay logic calculations (such as providing raycasting and damage calculation logic) based on the controlled virtual objects' positions in the current frame, and then synchronize the results back to the GameThread on terminal 101.

[0104] For cloud gaming applications, server 102, based on the scene visibility data generation method provided in this application embodiment, offline bakes and generates scene visibility data for each visibility detection partition, i.e., PVS level, and stores the scene visibility data of each PVS level along with OC data in a cloud database. During real-time rendering based on LevelStreaming technology, terminal 101 runs the cloud gaming application. The game thread (GameThread) on terminal 101 calculates the position of the controlled virtual object in the virtual world in each frame and synchronizes the position of the controlled virtual object in the current frame to the GameSvr process on server 102 in real time. The GameSvr process on server 102 determines the scene loading list for the current frame based on the synchronized position. Based on the scene loading method based on scene visibility data provided in this application embodiment, for each region to be loaded in the scene loading list, its visibility recorded in the scene visibility data is accessed to determine whether this region to be loaded is visible to the PVS unit where the controlled virtual object is located. If it is not visible, it means that the game screen of the current frame is not visible. If no data is contributed, this unloaded area is removed from the scene loading list. After traversing the entire scene loading list, all invisible areas are removed. Then, the scene data for each unloaded area in the final scene loading list is sent to the GameThread on terminal 101. The GameThread, using inter-thread communication mechanisms, passes the scene data of the unloaded areas to the RenderThread on terminal 101. The RenderThread performs Objective-C (OC) detection on each virtual object in the remaining unloaded areas. Virtual objects that pass OC detection are submitted to the RHIThread, which drives the GPU's rendering pipeline to render these objects, resulting in the game screen for the current frame. Furthermore, the GameSvr process on server 102 can perform basic gameplay logic calculations (such as providing ray detection and damage calculation logic) based on the synchronized location, and synchronize the results to the GameThread on terminal 101.

[0105] It should be noted that the device type of terminal 101 includes, but is not limited to, at least one of the following: smartphone, tablet computer, smart speaker, smartwatch, handheld smart device, portable gaming device, in-vehicle terminal, laptop computer, and desktop computer. For example, terminal 101 is a smartphone or other handheld portable gaming device. The following embodiments illustrate this by assuming that terminal 101 includes a smartphone.

[0106] Those skilled in the art will understand that the number of the aforementioned terminals may be more or less. For example, there may be only one terminal, or there may be dozens or hundreds of terminals, or even more. This application does not limit the number of terminals or the type of device.

[0107] The following describes the basic process of the method for generating scene visibility data according to the embodiments of this application.

[0108] Figure 2 This is a flowchart illustrating a method for generating scene visibility data according to an embodiment of this application. See also... Figure 2 This embodiment is executed by a computer device. Taking the computer device as a server as an example, this embodiment includes the following steps:

[0109] 201. For any one of the multiple visibility detection partitions in the virtual world, determine at least one associated region of the visibility detection partition from the multiple scene regions of the virtual world.

[0110] In this embodiment of the application, virtual world refers to the virtual environment, virtual scene or virtual space provided by the game application, and virtual world is a three-dimensional virtual world or a two-dimensional virtual world.

[0111] During scene loading, for seamless open-world games such as MMOGs and MMORPGs, in order to facilitate scene loading, the virtual world is usually divided into multiple scene areas based on predefined scene division logic. Each scene area is called a level or scene map. Each scene area includes one or more virtual objects, such as virtual objects, virtual creatures, virtual buildings, virtual obstacles, virtual resources, etc. In this application embodiment, the type of virtual object is not specifically limited.

[0112] In the pre-computed occlusion culling system, the virtual world is divided into multiple visibility detection partitions based on predefined visibility partitioning logic. Furthermore, each visibility detection partition is further divided into multiple visibility detection units. Here, the visibility detection partition is also called a PVS level, and the visibility detection unit is also called a PVS unit.

[0113] It should be noted that the division methods of scene regions and visibility detection partitions are unrelated. Scene regions are the units for scene loading, while visibility detection partitions are the units for visibility detection. They are usually divided based on different division logics. For example, a scene region may be divided into multiple visibility detection partitions, and a visibility detection partition may also be associated with multiple scene regions (in this embodiment, the associated scene regions are referred to as associated regions).

[0114] In step 201, for each visibility detection partition obtained from the virtual world division, at least one associated region is determined from all scene regions obtained from the virtual world division. In other words, for each PVS level obtained from the virtual world division, associated regions of the PVS level are filtered out from each scene region obtained from the virtual world division. Unassociated regions of the PVS level do not need to participate in the generation process of the PVS level's scene visibility data. Thus, by filtering out unassociated regions of the PVS level in step 201, the computational load of scene visibility data during generation can be greatly reduced, improving the efficiency of scene visibility data generation. The method for determining associated regions will be described in detail in the next embodiment and will not be repeated here.

[0115] In other embodiments, when performing visibility determination, since not all scene areas in the virtual world need to participate in PVS processing, for each PVS level, during the process of filtering out related areas from all scene areas in the virtual world, related areas that do not need to participate in PVS processing can be further removed from the filtered related areas; or, all scene areas that do not need to participate in PVS processing can be removed from all scene areas in the virtual world in advance, and then related areas can be further filtered out from the remaining scenes after removal, and the finally obtained related areas can be put into the local baking in step 202 below.

[0116] 202. Bake the at least one associated region to obtain occlusion clipping data for the at least one associated region, the occlusion clipping data indicating the visibility of virtual objects located in the associated region.

[0117] In this embodiment of the application, during the process of generating scene visibility data for a single visibility detection partition, it is not necessary to use the game engine to perform global baking of the entire scene area of ​​the entire virtual world. Instead, only the associated areas of the visibility detection partition selected in step 201 are locally baked. This reduces baking time and further improves the efficiency of scene visibility data generation.

[0118] In some embodiments, the occlusion clipping (OC) data of each associated region is obtained by using the associated regions selected in the game engine baking step 201. For example, the OC data includes the offset compensation amount VisibilityIdOffset of each associated region, which is used to indicate the bit offset of the associated region in the OC data.

[0119] 203. For any visibility detection unit in the visibility detection partition, based on the occlusion and clipping data of the at least one associated region, generate unit visibility data of the visibility detection unit for the at least one associated region, the unit visibility data indicating whether the associated region is globally visible to the visibility detection unit.

[0120] In this embodiment, for each visibility detection unit in the visibility detection partition, based on the OC data obtained from the local baking in step 202, unit visibility data for that visibility detection unit can be generated. This unit visibility data is used to indicate whether each associated region selected in step 201 is globally visible to the visibility detection unit. In other words, the OC data indicates the visibility at the virtual object granularity. In step 203, the visibility at the associated region granularity is obtained through the OC data. Furthermore, by integrating the visibility of all visibility detection units in the same visibility detection partition at the associated region granularity in step 204, the scene visibility data of the entire visibility detection partition can be obtained.

[0121] Schematic, in the pre-computation occlusion culling system, each PVS unit in the current PVS level is traversed: for each PVS unit, based on the position of the PVS unit, it is calculated whether the viewpoint originating from the PVS unit can see each virtual object in each associated region selected in step 201. Thus, if the viewpoint originating from the PVS unit cannot see all virtual objects in a certain associated region, it means that the associated region is globally invisible to the PVS unit; otherwise, if the viewpoint originating from the PVS unit can see any virtual object in a certain associated region, it means that the associated region is globally visible to the PVS unit. Repeating the above process, the visibility of the PVS unit to all associated regions can be determined, and the visibility of the PVS unit to all associated regions can be integrated to form the unit visibility data of the PVS unit.

[0122] 204. Based on the unit visibility data of each visibility detection unit, obtain the scene visibility data of the visibility detection partition.

[0123] In some embodiments, step 203 is performed for each visibility detection unit in the current visibility detection partition to obtain the unit visibility data of that visibility detection unit. By traversing all visibility detection units in the visibility detection partition, the unit visibility data of all visibility detection units in the visibility detection partition can be obtained. Further, the unit visibility data of all visibility detection units in the visibility detection partition are integrated to obtain the scene visibility data of the visibility detection partition. This scene visibility data is used to indicate the visibility of each associated region of the visibility detection partition to each visibility detection unit in the visibility detection partition. In other words, by traversing each PVS unit in the current PVS level, step 203 is performed for each PVS unit to obtain the unit visibility data of each PVS unit. The unit visibility data of all PVS units in the current PVS level are merged to obtain the scene visibility data of the current PVS level. This scene visibility data indicates the visibility of each associated region of the PVS level to each PVS unit.

[0124] In some embodiments, for each visibility detection partition divided in the virtual world, scene visibility data for that visibility detection partition can be generated through steps 201-204. By traversing all visibility detection partitions involved in the virtual world, all scene visibility data for the entire virtual world can be generated. Furthermore, after the server obtains all scene visibility data offline, it saves all scene visibility data together with OC data and packages it into the game application. This allows the terminal to use the scene visibility data of any visibility detection partition locally based on the scene streaming loading and unloading LevelStreaming technology during real-time rendering to perform secondary filtering on each region to be loaded based on its location, eliminating invisible regions to be loaded. By using scene visibility data, the processing efficiency of real-time rendering can be improved and the performance of real-time rendering can be optimized.

[0125] In other embodiments, it is not necessary to generate scene visibility data for every visibility detection partition in the virtual world. For example, scene visibility data is only generated for some visibility detection partitions that need to dynamically add or unload scene regions based on visibility to optimize real-time rendering performance. For instance, the dwell time of each account in each visibility detection partition during the game is counted, and some visibility detection partitions with dwell time exceeding the duration threshold are considered as high-frequency access visibility detection partitions. These visibility detection partitions have high requirements for real-time rendering performance, so scene visibility data is only generated and cached for these high-frequency access visibility detection partitions to optimize the real-time rendering performance of high-frequency access visibility detection partitions in a targeted manner. This application does not specifically limit whether scene visibility data is generated for every visibility detection partition in the virtual world.

[0126] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0127] The method provided in this application embodiment, by partially baking only the associated regions of a visibility detection partition (PVS level) in the virtual world, obtains occlusion and clipping data (OC data) for visibility determination. The OC data is then used to determine the visibility of each PVS unit to each associated region within the PVS level, further generating overall scene visibility data for the PVS level. This allows the scene visibility data to record the visibility of each associated region of the PVS level to each PVS unit. Thus, the scene visibility data can easily determine the visibility of each associated region of the PVS level to any PVS unit, facilitating decisions on which surrounding scene regions do not need to be loaded when a virtual object is in a PVS unit. Based on PVS technology, a filtering method for surrounding scene regions is provided. Therefore, based on the generated scene visibility data, the number of scene regions that need to be loaded in real-time in scene streaming loading and unloading technology is reduced, significantly improving real-time scene loading efficiency, reducing the consumption of terminal memory by game applications, and thus improving terminal processing performance.

[0128] In the above embodiments, the process of generating scene visibility data for a single visibility detection partition was briefly introduced. In the embodiments of this application, some implementation details of the above-mentioned process of generating scene visibility data will be described.

[0129] Figure 3 This is a flowchart illustrating a method for generating scene visibility data according to an embodiment of this application. See also... Figure 3 This embodiment is executed by a computer device. Taking the computer device as a server as an example, this embodiment includes the following steps:

[0130] 301. For any one of the multiple visibility detection partitions in the virtual world, determine at least one associated region of the visibility detection partition from the multiple scene regions of the virtual world.

[0131] In some embodiments, for each visibility detection partition obtained by dividing the virtual world, at least one associated region is determined from all scene regions obtained by dividing the virtual world.

[0132] In the above process, it is equivalent to filtering out the associated regions of each PVS level obtained by dividing the virtual world from the various scene regions contained in the virtual world. This means that the unassociated regions of the PVS level do not need to participate in the generation process of the scene visibility data of the PVS level. By filtering out the unassociated regions of the PVS level, the amount of calculation of scene visibility data during generation can be greatly reduced, and the generation efficiency of scene visibility data can be improved.

[0133] The following section will use any scene area in the virtual world as an example to explain how to determine whether a scene area is an associated area of ​​the current visibility detection partition. Figure 4 This is a flowchart illustrating a method for determining the correlation between a scene region and a visibility detection partition, as described in an embodiment of this application. Figure 4 As shown, step 301 can be achieved through the following sub-steps 3011-3013:

[0134] 3011. For any given scene region, determine the loading distance of the scene category based on the scene category of the scene region.

[0135] In some embodiments, since scene regions of different categories typically have different loading distances, and scene regions of the same category usually share the same loading distance, a mapping relationship between scene categories and loading distances can be pre-configured. Further, for the scene region to be determined, the scene category to which the scene region belongs is determined based on the region name or region identifier. Then, based on this mapping relationship, the loading distance matching the scene category is retrieved. Here, the loading distance is any value greater than 0, and the loading distance can be represented by "LoadDist".

[0136] In some embodiments, the above mapping relationship is implemented in the form of a scene loading table. That is, the technician pre-configures the loading distance of different scene categories and records the mapping relationship between scene categories and loading distances in the scene mapping table, so that the scene configuration table can provide the above mapping relationship. For example, the scene mapping table is a hash table.

[0137] In other embodiments, the above mapping relationship is implemented in the form of a key-value data structure. That is, for each pair of matching scene category and loading distance, a key-value data structure is constructed with scene category as key and loading distance as value. The above operation is repeated to construct multiple pairs of key-value data structures, so that multiple pairs of key-value data structures can provide the above mapping relationship. The embodiments of this application do not specifically limit the implementation of the mapping relationship. For example, in addition to scene mapping table and key-value data structure, other methods such as arrays and queues can be used to provide the mapping relationship.

[0138] In other embodiments, the loading distance of the scene area is not determined by the scene category. That is, technicians can also configure different loading distances for different scene areas of the same scene category. In this case, the mapping relationship needs to be recorded between the scene area and the loading distance. At this time, it is only necessary to query the loading distance of the scene area based on the area identifier of the scene area. Similarly, the above mapping relationship between the scene area and the loading distance can also be implemented through a scene mapping table or a key-value data structure, which is the same as the above implementation method and will not be repeated here.

[0139] 3012. Based on the loading distance, the bounding box range of the visibility detection partition is expanded to obtain the first bounding box range.

[0140] In some embodiments, an original bounding box range can be determined for each visibility detection partition. However, the original bounding box range of the visibility detection partition is insufficient to determine its correlation with the scene region. Therefore, it is necessary to expand the original bounding box range using the loading distance obtained in sub-step 3011 to obtain the expanded first bounding box range.

[0141] Expanding the original bounding box range and using the expanded first bounding box range in the relevance judgment is because when a virtual object is located in a visibility detection partition, it usually loads a certain range of the surrounding scene area, rather than being strictly confined to the original bounding box range. Especially when the virtual object is located at the boundary of the visibility detection partition, it may be necessary to load some scene areas located slightly further away from the outer edge of the visibility detection partition. In this way, expanding the original bounding box range by loading distance can avoid missing some associated areas at the boundary position and improve the accuracy of detecting associated areas.

[0142] In one example, in the world coordinate system of the virtual world, the original bounding box range of the visibility detection partition is expanded by the loading distance in both the x and y directions to obtain the expanded first bounding box range. By expanding only in the x and y directions, the amount of computation during expansion can be reduced. This is because when virtual objects are displaced in the virtual world, they usually only move in the x and y directions, and rarely move up or down in the z direction, i.e., the vertical direction. Therefore, while improving the detection accuracy of the managed area, the number of detected associated areas can be reduced, thereby reducing the amount of computation required to generate scene visibility data in the future.

[0143] In another example, in the world coordinate system of the virtual world, the original bounding box range of the visibility detection partition is expanded by the loading distance in the x, y and z directions to obtain the expanded first bounding box range. By expanding in the x, y and z directions, the detection accuracy of the associated region can be greatly improved, covering the associated region when the virtual object rises and falls in the z direction, avoiding missing any associated region. The embodiments of this application do not specifically limit the direction of expansion based on the loading distance.

[0144] 3013. If the first bounding box range intersects with the second bounding box range of the scene region, the scene region is determined as an associated region; otherwise, return to step 3011 to check whether the next scene region is an associated region.

[0145] In some embodiments, after obtaining the first bounding box range through sub-step 3012 for the aforementioned visibility detection partition, a second bounding box range can also be determined for each scene region. Then, by detecting whether the first bounding box range intersects with the second bounding box range—that is, detecting whether the first and second bounding box ranges have a spatial intersection—if the first and second bounding box ranges have a spatial intersection, it means that the first and second bounding box ranges intersect, and the current scene region is determined as an associated region of the current visibility detection partition. The process then returns to step 3011 for the next scene region. Otherwise, if the first and second bounding box ranges do not have a spatial intersection, it means that the first and second bounding box ranges do not intersect. At this point, the current scene region is determined, and it is not an associated region. The process then returns to step 3011 for the next scene region. Steps 3011-3013 are repeated until all scene regions to be determined in the virtual world have been traversed. At this point, all associated regions of the current visibility detection partition can be obtained.

[0146] In steps 3011-3013 above, by detecting whether the first bounding box range obtained after expanding the visibility detection partition intersects with the second bounding box range of each scene region, it is possible to avoid missing some associated regions at the boundary positions, thereby comprehensively and accurately determining all associated regions of the visibility detection partition and improving the detection accuracy of associated regions.

[0147] Alternatively, when detecting associated regions, instead of expanding the original bounding box range of the visibility detection partition, the second bounding box range of each scene region can be expanded, and the intersection detection can be performed based on the original bounding box range of the visibility detection partition and the expanded second bounding box range of each scene region, which can also improve the detection accuracy of associated regions.

[0148] Optionally, when detecting associated regions, the bounding box ranges of the visibility detection partition and the scene region can be left unexpanded. That is, the intersection detection can be performed directly based on the original bounding box range of the visibility detection partition and the second bounding box range of each scene region. This eliminates the need to expand the original bounding box range of the visibility detection partition, simplifies the identification process of associated regions, and improves the identification efficiency of associated regions. The embodiments of this application do not specifically limit the detection method of associated regions.

[0149] In other embodiments, when determining visibility, since not all scene areas in the virtual world need to participate in PVS processing, a portion of scene areas that do not need to participate in PVS processing can be pre-configured. Based on this, for each visibility detection partition, after filtering out at least one associated region in step 301, associated regions that do not need to participate in PVS processing can be removed from these at least one associated region, and the remaining associated regions can be added to step 302; alternatively, scene areas that do not need to participate in PVS processing can be pre-removed from all scene areas in the virtual world, and then at least one associated region of the current visibility detection partition can be further filtered from the removed scene areas, and the finally filtered at least one associated region can be added to step 302. This application embodiment does not specifically limit this approach.

[0150] Schematic illustration: In the process of assigning region identifiers to all scene regions in the virtual world, scene regions containing any statically renderable virtual objects are required to participate in PVS processing, while scene regions without any statically renderable virtual objects are not required to participate in PVS processing. Under this setting, valid values ​​are assigned to the region identifiers of all scene regions in the virtual world that contain statically renderable virtual objects, and invalid values ​​are assigned to the region identifiers of all scene regions in the virtual world that do not contain statically renderable virtual objects. For example, the valid values ​​assigned to the region identifiers of the aforementioned scene regions containing statically renderable virtual objects start from 0 and increment sequentially by 1, and no two scene regions have the same region identifier. In addition, the invalid values ​​assigned to the region identifiers of the aforementioned scene regions that do not contain statically renderable virtual objects are the same but different negative numbers; for example, all invalid values ​​are -1.

[0151] Next, for each PVS level, after filtering out at least one associated region through step 301, the associated regions with illegal region identifiers are removed from the at least one associated region, and the remaining associated regions are put into step 302; or, the scene regions with illegal region identifiers are removed from all scene regions in the virtual world in advance, and then at least one associated region of the current visibility detection partition is filtered out from the multiple scene regions after removal, and the at least one associated region finally filtered out is put into step 302. This application embodiment does not specifically limit this.

[0152] In the above process, by removing some scene areas that do not need to participate in PVS processing, the number of associated areas that need to be processed by PVS can be further reduced. Thus, on the basis of filtering out the non-associated areas of each PVS, the associated areas that do not need to participate in PVS processing are further filtered out, so as to further reduce the amount of computation of scene visibility data during generation and improve the generation efficiency of scene visibility data.

[0153] 302. Bake the at least one associated region to obtain occlusion clipping data for the at least one associated region, the occlusion clipping data indicating the visibility of virtual objects located in the associated region.

[0154] In some embodiments, the game engine is used to perform local baking on each of the associated regions selected in step 301 to obtain occlusion clipping (OC) data of each associated region. In addition, the OC data and region identifiers of each associated region are then recorded. The region identifiers are pre-assigned to each scene region. The configuration method of the region identifiers is as described in step 301 and will not be repeated here.

[0155] In one example, the OC data generated for each associated region includes: an offset compensation value, VisibilityIdOffset, for each associated region, which indicates the bit offset of the associated region in the OC data. Furthermore, for each visibility detection partition, the region identifier, LevelUniqueId, and offset compensation value, VisibilityIdOffset, for each associated region of that visibility detection partition are recorded.

[0156] In the above process, since it is not necessary to use the game engine to perform global baking of the entire scene area of ​​the entire virtual world during the process of generating scene visibility data for a single visibility detection partition, only the relevant areas of the visibility detection partition selected in step 301 are locally baked, the baking time can be reduced and the efficiency of scene visibility data generation can be further improved.

[0157] 303. For any visibility detection unit in the visibility detection partition, determine the starting index value and the ending index value of any associated region in the at least one associated region.

[0158] In some embodiments, when generating scene visibility data for each visibility detection partition, unit visibility data is generated for each visibility detection unit in the visibility detection partition, and then the unit visibility data of each visibility detection unit are merged to obtain the scene visibility data of the entire visibility detection partition.

[0159] In steps 303-306, the method for generating unit visibility data for each visibility detection unit will be described in detail. Furthermore, when generating unit visibility data for each visibility detection unit, the visibility of each associated region to the visibility detection unit is determined one by one, taking each associated region as a unit, and then the visibility of each associated region to the visibility detection unit is merged to obtain the unit visibility data of the entire visibility detection unit. In steps 303-305, the method for determining the visibility of each associated region to the visibility detection unit will be described in detail below.

[0160] As described in step 303 above, each visibility detection unit in the visibility detection partition is traversed. Taking any visibility detection unit as an example, a data space for unit visibility data is pre-allocated for this visibility detection unit. For example, a data space for recording unit visibility data is allocated in memory for this visibility detection unit. This data space is called PVSOptLevelStreaming. Then, all bits of the unit visibility data recorded in this data space are initialized. Furthermore, for any associated region of the current visibility detection partition, the start index value and end index value of the associated region can be determined. The start index value represents the index value of the first virtual object in the associated region in the OC data, and the end index value represents the index value of the last virtual object in the associated region in the OC data. By determining the start index value and end index value, it is possible to locate which bits in the OC data represent the visibility of each virtual object in the current associated region.

[0161] It should be noted that since OC data indicates the visibility of virtual objects by the visibility detection unit at the granularity of virtual objects, and the visibility of these virtual objects is serialized and arranged according to their associated regions in the OC data, when locally baking to generate OC data in step 302 above, it is also necessary to record an offset compensation amount, VisibilityIdOffset, for each associated region to indicate the bit offset of this associated region in the OC data. Therefore, for any associated region, the offset compensation amount, VisibilityIdOffset, indicates the index value of the first virtual object in that associated region in the OC data, i.e., the starting index value. Similarly, the offset compensation amount, VisibilityIdOffset, of the next associated region indicates the index value of the last virtual object in that associated region in the OC data. In other words, the offset compensation amount of the associated region in the OC data is determined as the starting index value of the associated region, and the offset compensation amount of the next associated region in the OC data is determined as the ending index value of the associated region.

[0162] In the above process, by generating an offset compensation amount VisibilityIdOffset for each associated region, each associated region can obtain its own starting index value and ending index value in the OC data through its own offset compensation amount VisibilityIdOffset and the offset compensation amount VisibilityIdOffset of the next associated region. Since only each associated region is locally baked, the offset compensation amounts VisibilityIdOffset of adjacent associated regions in the OC data are also connected end to end, thus enabling the quick and accurate acquisition of its own starting index value and ending index value.

[0163] In other embodiments, the start index value and end index value of each associated region relative to each visibility detection unit can be recorded when generating OC data. This eliminates the need to temporarily calculate the start index value and end index value, and the start index value and end index value recorded in the OC data can be accessed directly, which can improve access efficiency.

[0164] In other embodiments, instead of local baking, global baking is used for each visibility detection partition. In this case, the starting index value and ending index value can be queried in the same way. Although the baking time is longer, more scene areas can be included in the visibility detection, which can improve the accuracy of visibility detection. This application does not make specific limitations on this.

[0165] 304. From the occlusion clipping data, query the visibility of each virtual object whose index value lies between the starting index value and the ending index value.

[0166] In some embodiments, OC data includes multiple bits, each bit in the OC data records the visibility of a virtual object. The bits where the visibility of virtual objects in different associated regions are located are serialized, and the bits correspond one-to-one with the index values, that is, a bit has a unique corresponding index value.

[0167] Under the above premise, for each associated region, after determining the start index and end index of the associated region in step 303, the unique start bit indicated by the start index can be found in the OC data. Similarly, the unique end bit indicated by the end index can be found. Then, for the OC data, starting from the start bit indicated by the start index, the visibility of the virtual object recorded in each bit is traversed until the end bit indicated by the end index is reached. In other words, each bit from the start bit to the end bit records the visibility of a virtual object in the current associated region. By traversing and accessing each bit from the start bit to the end bit, the visibility of each virtual object in the associated region by the visibility detection unit can be read, that is, it can be determined whether each virtual object in the associated region is visible to the visibility detection unit.

[0168] In the above process, by using the start index value and the end index value, the bit corresponding to the first virtual object in the current associated region and the bit corresponding to the last virtual object in the associated region can be determined from the OC data. Since the bits of each virtual object in the same associated region are serialized and arranged continuously during the local baking process, the start bit and the end bit can be locked in the OC data by using the start index value and the end index value. This allows for quick locking of the visibility of each virtual object in the associated region by the visibility detection unit.

[0169] 305. Based on the visibility of each virtual object obtained in step 304, configure the visibility detection unit to enable visibility of the associated region.

[0170] In some embodiments, in step 304 above, by traversing each bit from the start bit to the end bit, the visibility of each virtual object in the associated region can be read by the visibility detection unit. Further, if the visibility of all queried virtual objects indicates that they are invisible, the visibility of the associated region is configured to be invisible; if the visibility of any queried virtual object indicates that it is visible, the visibility of the associated region is configured to be visible.

[0171] In one example, the visibility recorded in each bit of the OC data either indicates that the visibility detection unit is not visible to the corresponding virtual object, or indicates that the visibility unit is visible to the corresponding virtual object.

[0172] Optionally, the data recorded in each bit is binary data, which can be either 0 or 1. When the value is 0, it indicates that the visibility detection unit is not visible to the corresponding virtual object, and when the value is 1, it indicates that the visibility detection unit is visible to the corresponding virtual object. At this point, if in step 304, starting from the starting bit, each bit in the OC data is read bit by bit until the ending bit is read, and if all the binary data recorded in all the read bits are 0, it means that the visibility of each virtual object obtained is not visible. This indicates that all virtual objects in the associated region are not visible to the visibility detection unit. Since the visibility detection unit cannot see all the virtual objects in the associated region, it means that the entire associated region is not visible to the visibility detection unit. Therefore, the visibility of the associated region is configured as invisible. Otherwise, if any of the binary data recorded in all the read bits is 1, it means that the visibility of a certain virtual object in the associated region is visible. This indicates that at least one virtual object in the associated region is visible to the visibility detection unit. In this case, the visibility detection unit can at least see the virtual object corresponding to the bit in the associated region that is 1. This means that the entire associated region is visible to the visibility detection unit. Therefore, the visibility of the associated region is configured as visible. In the above process, only one possible implementation is provided, in which a value of 0 indicates that the bit is invisible and a value of 1 indicates that the bit is visible. Optionally, binary data in the bit can also be set, in which a value of 1 indicates that the bit is invisible and a value of 0 indicates that the bit is visible. This application does not specifically limit this implementation.

[0173] Optionally, the data recorded in each bit is Boolean data, which is either false or true. When the value is false, it indicates that the visibility detection unit is not visible to the corresponding virtual object, and when the value is true, it indicates that the visibility detection unit is visible to the corresponding virtual object. At this point, if in step 304, starting from the starting bit, each bit in the OC data is read bit by bit until the ending bit is reached, and if all the Boolean data recorded in all the read bits is false, it means that the visibility of each virtual object obtained by the query is not visible. This indicates that all virtual objects in the associated region are not visible to the visibility detection unit. Since the visibility detection unit cannot see all the virtual objects in the associated region, it means that the entire associated region is not visible to the visibility detection unit. Therefore, the visibility of the associated region is configured to be invisible. Otherwise, if any of the Boolean data recorded in all the read bits is true, it means that the visibility of a certain virtual object in the associated region is visible. This indicates that at least one virtual object in the associated region is visible to the visibility detection unit. In this case, the visibility detection unit can at least see the virtual object corresponding to the bit in the associated region that indicates true. This means that the entire associated region is visible to the visibility detection unit. Therefore, the visibility of the associated region is configured to be visible. In the above process, only one possible implementation is provided, in which a value of false indicates that the data is not visible and a value of true indicates that the data is visible. Optionally, boolean data in the bit can also be set, in which a value of true indicates that the data is not visible and a value of false indicates that the data is visible. This application does not specifically limit this implementation.

[0174] 306. Based on the visibility of each associated region by the visibility detection unit, generate unit visibility data of the visibility detection unit for at least one associated region.

[0175] The unit visibility data indicates whether the associated region is globally visible to the visibility detection unit.

[0176] In some embodiments, after the visibility detection unit detects the visibility of each associated region through steps 303-305, as described in step 303, a data space PVSOptLevelStreaming for recording unit visibility data is pre-allocated to the visibility detection unit, and an initialized unit visibility value is configured for the visibility detection unit in the data space PVSOptLevelStreaming. Illustratively, the initialized unit visibility data also contains multiple bits, each bit recording the visibility of an associated region. Each bit corresponds one-to-one with an index value; for example, the region identifier of each associated region is used as the index value of the corresponding bit. That is, the index value of each bit is the region identifier of the associated region recorded by that bit. Thus, after determining the visibility of the current associated region through step 305, the bit indicated by the region identifier of the associated region can be assigned a value in the unit visibility data based on the visibility of each associated region determined in step 305.

[0177] In one example, each bit in the unit visibility data records binary data. A value of 0 indicates invisibility, and a value of 1 indicates visibility. For each associated region, based on the region identifier, the bit indicated by that region identifier can be found in the unit visibility data. Then, if the visibility of the associated region is invisible (i.e., the entire associated region is not visible to the visibility detection unit), the found bit is assigned a value of 0. Otherwise, if the visibility of the associated region is visible (i.e., the entire associated region is visible to the visibility detection unit), the found bit is assigned a value of 1. This explanation only uses a value of 0 indicating invisibility and a value of 1 indicating visibility as an example. Optionally, the binary data in the bit can also be set such that a value of 1 indicates invisibility and a value of 0 indicates visibility. This embodiment does not specifically limit this approach.

[0178] In another example, each bit in the cell visibility data records Boolean data. A value of false indicates invisibility, and a value of true indicates visibility. For each associated region, based on its region identifier, the bit indicated by that region identifier can be found in the cell visibility data. Then, if the visibility of the associated region is invisible (i.e., the entire associated region is invisible to the visibility detection unit), the found bit is assigned the value false. Otherwise, if the visibility of the associated region is visible (i.e., the entire associated region is visible to the visibility detection unit), the found bit is assigned the value true. This explanation only uses the example of a value of false indicating invisibility and a value of true indicating visibility. Optionally, the Boolean data in the bit can also be set, with a value of true indicating invisibility and a value of false indicating visibility. This application does not specifically limit this approach.

[0179] In steps 303-306 above, the visibility of each visibility detection unit in the visibility detection partition to any associated region is obtained, and the bit indicating the associated region is assigned a value in the unit visibility data. Steps 303-306 are traversed for all associated regions, and the unit visibility data after all bits have been assigned is obtained. At this time, the initial value of each bit in the initial process is overwritten by the new value assigned in step 306. After traversing all bits and reassigning them, the assigned unit visibility data can indicate the visibility of the visibility detection unit to each associated region. By determining the visibility of the entire associated region based on the visibility of each virtual object in the associated region, it is easy to identify which associated regions are globally visible to the current visibility detection unit and which are globally invisible to the current visibility detection unit.

[0180] It should be noted that steps 303-306 above provide a possible implementation for generating unit visibility data of the visibility detection unit for the at least one associated region based on the occlusion and clipping data of the at least one associated region. That is, when generating OC data through local baking, the offset compensation amount VisibilityIdOffset of each associated region is recorded, and the starting index value and ending index value of the current associated region are determined based on the offset compensation amount VisibilityIdOffset of the current associated region and the next associated region, thereby making it easy to find the visibility of each virtual object in the associated region from the OC data, so as to determine the visibility of the entire associated region. Then, the unit visibility data of the current visibility detection unit is assigned a value according to the visibility of all associated regions, which can ensure the detection accuracy of the unit visibility data.

[0181] In other embodiments, when generating unit visibility data for each visibility detection unit, it is not necessary to generate standard OC data at the granularity of each virtual object through local baking. Instead, during local baking, all virtual objects in each associated region are treated as a whole region object. For example, each associated region is encoded with color, such as black representing invisible and white representing visible. This decouples the generation process of standard OC data from the generation process of unit visibility data. The color of the associated region after local baking can indicate which associated regions are visible, which can greatly improve the generation efficiency of unit visibility data and scene visibility data. The embodiments of this application do not specifically limit the generation method of unit visibility data.

[0182] 307. Merge the unit visibility data of each visibility detection unit to obtain the scene visibility data of the visibility detection partition.

[0183] In some embodiments, steps 303-306 are performed for each visibility detection unit, traversing all visibility detection units in the current visibility detection partition to obtain the unit visibility data of each visibility detection unit in the visibility detection partition. The unit visibility data of each visibility detection unit are then merged to obtain the scene visibility data of the entire visibility detection partition. In other words, for any PVS level, all PVS units in the PVS level are traversed and processed to obtain the unit visibility data of each PVS unit. The collection of unit visibility data of all PVS units is taken as the scene visibility data of the PVS level.

[0184] 308. Associate and store the scene visibility data with the visibility detection partition.

[0185] In some embodiments, the server stores scene visibility data for each visibility detection partition. Then, the scene visibility data of the aforementioned visibility detection partition is compressed and packaged into the data packet of the game application (i.e., all scene visibility data is saved and packaged into the game application). This allows the terminal to download all scene visibility data obtained from offline baking to its local machine after installing the game application.

[0186] Optionally, during the compression and storage process, the visibility detection partition is associated with the scene visibility data and stored together. Then, based on the compression algorithm, the associated scene visibility data is compressed and packaged separately. For example, the partition identifier of the visibility detection partition is associated with the scene visibility data of the visibility detection partition and stored together. Then, based on the Zlib algorithm, the associated scene visibility data is compressed and packaged separately (at this time, the participation of OC data is not required).

[0187] Optionally, during the compression and storage process, the scene visibility data of the visibility detection partition and the OC data are stored together. Then, based on the compression algorithm, the scene visibility data and OC data stored together are compressed and packaged separately. For example, in the data package of a game application, the scene visibility data and OC data of each visibility detection partition, i.e., the PVS level, are compressed and stored separately, but both adopt the same cell distribution (i.e., the visibility detection unit divided when generating OC data is consistent with the visibility detection unit divided when generating scene visibility data). By storing scene visibility data and OC data separately, it is convenient to call OC data or scene visibility data according to different business needs, avoid the coupling of scene visibility data and OC data, and improve the response rate of subsequent business needs.

[0188] In steps 307-308 above, a possible implementation is provided for obtaining scene visibility data of the visibility detection partition based on the unit visibility data of each visibility detection unit. That is, the unit visibility data of each visibility detection unit is merged to obtain the scene visibility data of the entire visibility detection partition. Optionally, the entire visibility detection partition can also be divided into several visibility detection cells, each containing multiple visibility detection units. That is, an intermediate layer is constructed between the visibility detection units and the visibility detection partition to speed up the indexing of detailed visibility detection units. When a new query request for a specified target detection unit arrives, it is only necessary to first route to the corresponding visibility detection partition and then to the subordinate visibility detection cell to quickly locate the visibility detection unit, thus eliminating the need to query other visibility detection cells and greatly improving indexing efficiency. This application embodiment does not specifically limit whether to add an intermediate layer.

[0189] Furthermore, after the server obtains all scene visibility data through offline baking, it saves all scene visibility data along with OC data and packages it into the game application. This allows the terminal to use LevelStreaming technology for local scene loading and unloading during real-time rendering to call the scene visibility data of any visibility detection partition to perform secondary filtering on each region to be loaded based on its location, eliminating invisible regions to be loaded. By using scene visibility data, the processing efficiency of real-time rendering is improved and the performance of real-time rendering is optimized. The specific secondary filtering method will be described in detail in the next embodiment and will not be repeated here.

[0190] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0191] The method provided in this application embodiment, by partially baking only the associated regions of a visibility detection partition (PVS level) in the virtual world, obtains occlusion and clipping data (OC data) for visibility determination. The OC data is then used to determine the visibility of each PVS unit to each associated region within the PVS level, further generating overall scene visibility data for the PVS level. This allows the scene visibility data to record the visibility of each associated region of the PVS level to each PVS unit. Thus, the scene visibility data can easily determine the visibility of each associated region of the PVS level to any PVS unit, facilitating decisions on which surrounding scene regions do not need to be loaded when a virtual object is in a PVS unit. Based on PVS technology, a filtering method for surrounding scene regions is provided. Therefore, based on the generated scene visibility data, the number of scene regions that need to be loaded in real-time in scene streaming loading and unloading technology is reduced, significantly improving real-time scene loading efficiency, reducing the consumption of terminal memory by game applications, and thus improving terminal processing performance.

[0192] The above embodiments detailed the process of generating scene visibility data for any visibility detection partition in a virtual world. This application provides an exemplary process for generating scene visibility data. Figure 5 This is a flowchart of a method for generating scene visibility data provided in an embodiment of this application, such as... Figure 5 As shown, this embodiment is executed by a computer device, and the computer device is used as a server for example. For simplicity, in this embodiment, the visibility detection partition is denoted as PVSLevel, the visibility detection unit is denoted as PVSCell, the scene visibility data is denoted as PVSOPtLevelStreaming, and the occlusion clipping data is denoted as OC data.

[0193] 501. For all scene regions in the virtual world that contain static renderable virtual objects, assign a valid value to their region identifier LevelUniqueId, starting from 0 and incrementing by 1. Record the region identifier LevelUniqueId with the largest value after assignment as WorldMaxLevelUniqueId. Conversely, for scene regions that do not contain static renderable virtual objects, i.e., scene regions that do not participate in PVS processing, assign an invalid value to their region identifier LevelUniqueId, such as an invalid value -1.

[0194] 502. Based on the navigation mesh NavMesh, divide the virtual world into various visibility detection partitions PVSLevel to generate multiple PVSLevels for the empty scene. Similarly, based on the navigation mesh NavMesh, arrange various visibility detection units PVSCells and assign each PVSCell to its corresponding PVSLevel based on its location.

[0195] 503. Perform local baking on each PVSLevel to generate standard OC data.

[0196] In some embodiments, during the local baking process, only the visibility information of virtual objects in the associated region associated with the current PVSLevel needs to be processed, without processing the visibility information of virtual objects in the non-associated region of the current PVSLevel, which can effectively reduce the data packet size and memory usage of PVS data.

[0197] Schematic, the partial baking method includes the following sub-steps (a)-(b):

[0198] (a) Determine whether the current scene area is related to PVSLevel, that is, determine whether the current scene area is an associated area of ​​PVSLevel, which involves the following sub-steps a1-a3:

[0199] a1. Based on the scene name of the scene area, determine the scene category to which the scene area belongs, and then obtain the loading distance LoadDist of the scene area based on the scene configuration table.

[0200] a2. Let the original bounding box LevelBound of PVSLevel be Box1. Expand Box1 outward by a loading distance LoadDist in the x and y directions, and let the original bounding box LevelBound of the scene area be Box2. Here, the expanded Box1 is the first bounding box range, and Box2 is the second bounding box range.

[0201] a3. Determine if Box1 and Box2 intersect. If Box1 and Box2 intersect, it means that the scene area is related to PVSLevel, that is, the scene area is the associated area of ​​PVSLevel; otherwise, if Box1 and Box2 do not intersect, it means that the scene area is not related to PVSLevel, and continue to return to step a1 for the next scene area.

[0202] (b) Only perform local baking on each associated region detected in step (a) to generate PVSLevel OC data, and PVSLevel records the region identifier LevelUniqueId and offset compensation amount VisibilityIdOffset of all associated regions. VisibilityIdOffset indicates the degree of bit offset of the associated region in the OC data.

[0203] Figure 6 This is a schematic diagram of block storage of PVS OC data provided in an embodiment of this application, such as... Figure 6 As shown, the PVS OC data obtained after partial baking can be stored in blocks within PVS_Grid_x_x (referring to the PVS grid). Figure 6 The grid-like lines shown represent the individual PVSCells. After local baking, each PVSCell needs to store two parts of PVS OC data: standard OC data (used for occlusion and clipping of virtual objects in the scene area) and PVSOPtLevelStreaming data (used for secondary filtering of the surrounding areas to be loaded when loading and unloading LevelStreaming in the scene).

[0204] 504. For each PVSLevel divided in step 502, generate scene visibility data PVSOPtLevelStreaming based on the OC data of the PVSLevel standard.

[0205] Schematic, the PVSOptLevelStreaming generation method includes the following sub-steps (i)-(ii):

[0206] (i) Iterate through and process all PVSLevel cells in the current PVSLevel:

[0207] (i-1) Obtain a PVSCell, allocate PVSOptLevelStreaming data space for the PVSCell. For example, the number of bytes occupied in memory for each allocated data space is ((WorldMaxLevelUniqueId+1)+7) / 8, and initialize all bytes to 0xFF, indicating that all associated regions are initially visible by default.

[0208] (i-2) Obtain the following information for all associated regions of the current PVSLevel: region identifier LevelUniqueId and offset compensation amount VisibilityIdOffset. Then, process all associated regions in a loop.

[0209] Visibility calculation of a domain to a PVSCell:

[0210] (i-2-1) Obtain the region identifier LevelUniqueId and offset compensation amount VisibilityIdOffset of an associated region. Then, record the region identifier LevelUniqueId as the index value CurrentLevelUniqueId of the current associated region in the cell visibility data of PVSCell; and configure the offset compensation amount VisibilityIdOffset of the associated region as the start index value StartBitIndex of the bit position of the associated region in the OC data, and configure the offset compensation amount VisibilityIdOffset of the next associated region as the end index value EndBitIndex of the bit position of the associated region in the OC data. The start index value StartBitIndex indicates the start bit position of the associated region in the OC data, and the end index value EndBitIndex indicates the last bit position of the associated region in the OC data, i.e., the end bit position.

[0211] (i-2-2) Iterate through each bit between the StartBitIndex and EndBitIndex of the OC data, and determine whether all the binary data recorded in these bits are 0. Here, we take the example of a binary data value of 0 representing invisible and a value of 1 representing visible. If all the bits are 0, it means that the current associated region is globally invisible. If any bit is 1, it means that the current associated region is globally visible.

[0212] (i-2-3) Based on the visibility result of the associated region determination in the previous step (i-2-2), set the value of the CurrentLevelUniqueId bit in the PVSOptLevelStreaming data. For example, a value of 1 indicates that the entire associated region is globally visible, and a value of 0 indicates that the entire associated region is globally invisible.

[0213] (ii) After traversing and processing all PVSLevels, the Zlib algorithm, which is universal across all platforms, can be used to compress the assigned PVSLevelStreaming data and save the compressed PVSLevelStreaming data to PVSLevel.

[0214] Optionally, both PVSOPtLevelStreaming data and standard OC data (also known as PVS OC data) are stored in PVSLevel, and both use the exact same Cell distribution (i.e., both divide PVSCells in the same way). However, PVSOPtLevelStreaming data and standard OC data are compressed and stored separately. This allows the terminal with the game application installed to access PVSOPtLevelStreaming data independently (without mixing in OC data) when adding and unloading LevelStreaming based on the game thread (GameThread) during scene streaming. It also allows the terminal-side rendering thread (RenderThread) to access OC data independently (without mixing in PVSOPtLevelStreaming data) during screen rendering. By compressing and storing different types of data separately, different types of threads can decompress and obtain the required data type according to business needs, without mixing in irrelevant data.

[0215] In this application embodiment, a scheme for constructing scene visibility data PVS0ptLevelStreaming for each visibility detection partition PVSLevel is provided. For seamless open-world games, when constructing the virtual world, for each PVSLevel and each PVSCell, the visibility of the entire associated region is calculated based on the PVS visibility of all static renderable virtual objects in the associated region, and the visibility results of the associated region are stored. The visibility of each PVSCell to each associated region is used to generate scene visibility data PVS0ptLevelStreaming for PVSLevel. The scene visibility data PVS0ptLevelStreaming is then segmented, saved, and packaged into the game application, which can ensure that a smooth scene streaming loading and unloading service is provided to the outside world when the game application is running.

[0216] Furthermore, based on this, when calculating the area to be loaded based on the position of the controlled virtual object and the distance between the controlled virtual object and the scene area, an additional layer of PVS visibility filtering logic based on the entire scene area is added. By configuring completely invisible scene areas (i.e., globally invisible) not to be loaded, the smoothness of the scene streaming loading and unloading process can be further improved without affecting the performance of real-time rendering of game screens. This is because only completely obscured and invisible scene areas are omitted (not loaded). This can be called the PVS-optimized scene streaming loading and unloading LevelStreaming technology.

[0217] In the above embodiments, the construction of scene visibility data PVS0ptLevelStreaming for each visibility detection partition PVSLevel is described in detail on the server side. It should be noted that after the server side obtains the OC data and PVS0ptLevelStreaming data for each PVSLevel offline, the OC data and PVS0ptLevelStreaming data for each PVSLevel are saved and packaged into the data package of the game application. This allows each terminal to download the OC data and PVS0ptLevelStreaming data for each PVSLevel to its local machine after installing the game application. Subsequently, when running the game application, the online real-time scene streaming loading and unloading LevelStreaming calculation logic can be implemented based on the locally saved PVS0ptLevelStreaming data.

[0218] In this embodiment, we will explain how the terminal utilizes the scene visibility data PVSOPtLevelStreaming provided in the game application to perform secondary filtering of the real-time scene streaming loading and unloading technology LevelStreaming during the real-time rendering process. Here, we will only use the example of embedding the OC data and PVSOPtLevelStreaming data of each PVSOPtLevel into the game application in a traditional game application, and then the terminal performs the calculation of scene streaming loading and unloading LevelStreaming locally. In some embodiments, for cloud gaming application scenarios, the terminal only needs to synchronize the position of the controlled virtual object in the virtual world in each frame with the server. The server will calculate the area to be loaded in each frame after culling based on the OC data and PVSOPtLevelStreaming data in real time, without the terminal participating in the calculation of scene streaming loading and unloading LevelStreaming. This embodiment does not specifically limit this.

[0219] Figure 7 This is a flowchart of a scene loading method based on scene visibility data provided in an embodiment of this application, such as... Figure 7 As shown, this embodiment is executed by a terminal, which is an exemplary illustration of a computer device. This embodiment includes the following steps:

[0220] 701. The terminal determines the location of the controlled virtual object in the virtual world.

[0221] In this embodiment of the application, for ease of distinction, the virtual object controlled by the terminal is referred to as the "controlled virtual object", and the static renderable virtual object in the scene area of ​​the virtual world is still referred to as the "virtual object".

[0222] In some embodiments, when the terminal launches the game application, it creates a GameThread and a RenderThread. The GameThread is used to maintain the main game business logic, and the RenderThread is used for non-hardware-level rendering instruction processing logic. Then, during the operation of the game application, if it is detected that the player controls the virtual object to move, the GameThread is used to obtain the position of the virtual object in real time.

[0223] In some embodiments, the location of the controlled virtual object determined by the terminal refers to the location coordinates of the controlled virtual object. These location coordinates are the world coordinates, screen coordinates, or coordinates in other coordinate systems of the controlled virtual object. This application embodiment does not specifically limit the type of location coordinates.

[0224] 702. The terminal determines at least one region to be loaded in the virtual world based on the location of the controlled virtual object in the virtual world.

[0225] In some embodiments, the terminal updates the LevelStreaming state based on the position coordinates of the controlled virtual object determined in step 701 above, in order to calculate which scene areas should be loaded at the current position:

[0226] 1) Extract the following information for a scene region: Load Distance (LoadDist) and Bounding Box (LevelBound);

[0227] 2) Construct a bounding sphere for detection based on the position coordinates of the controlled virtual object and the loading distance LoadDist of the scene area;

[0228] 3) Determine if the bounding sphere intersects with the bounding box (LevelBound) of the current scene region. If they intersect, proceed to step 4); otherwise, proceed to step 5.

[0229] 4) If the bounding sphere and the bounding box LevelBound intersect, add the current scene region to the scene loading list and proceed to step 6);

[0230] 5) If the bounding sphere and the bounding box LevelBound do not intersect, add the current scene region to the scene unload list and proceed to step 6);

[0231] 6) Determine if all scene areas of the virtual world have been traversed. If traversal is complete, proceed to step 7; otherwise, return to step 1.

[0232] 7) Cache the scene loading list and scene unloading list, and record the scene areas in the scene loading list as at least one area to be loaded, so as to be put into the subsequent PVS-based filtering process.

[0233] In steps 1)-7) above, the terminal side can determine whether each scene area is within the bounding sphere of the controlled virtual object based on the position of the controlled virtual object in the virtual world for each frame. The bounding sphere indicates the loading range of the controlled virtual object. Scene areas that intersect with the loading range are added to the scene loading list, and scene areas that do not intersect with the loading range are added to the scene unloading list, thus enabling frame-level scene streaming loading and unloading.

[0234] This explanation focuses on the terminal side using LevelStreaming technology to add and unload scenes, which detects the position of the controlled virtual object in each frame in real time and obtains the scene loading list and scene unloading list for each frame based on the position of the controlled virtual object. Since the server side does not need to participate in the scene loading and unloading calculation process, this can save the server's computing resources and reduce the communication overhead between the terminal and the server.

[0235] In other embodiments, particularly for cloud gaming applications, the terminal can send a scene stream loading request carrying the location to the server after obtaining the location of the controlled virtual object in each frame in real time. The server receives the scene stream loading request, parses the location carried in the scene stream loading request, and calculates the scene loading list and scene unloading list for the current frame in a manner similar to step 702. In other words, the server receives the terminal's information on the location of the controlled virtual object synchronously, and the server side calculates the scene loading list and scene unloading list. In this way, since the calculation process of scene streaming loading and unloading is migrated to the cloud, the computational overhead on the terminal side can be greatly reduced.

[0236] 703. The terminal accesses the scene visibility data of the visibility detection partition to which the target detection unit where the controlled virtual object is located belongs, so as to obtain the unit visibility data of at least one associated area of ​​the target detection unit in the visibility detection partition.

[0237] The unit visibility data indicates whether the associated region is globally visible to the target detection unit.

[0238] In some embodiments, the terminal can query the visibility detection unit where the controlled virtual object is located based on the location of the controlled virtual object. Here, the visibility detection unit where the controlled virtual object is located is called the target detection unit. Then, as described in the previous embodiment, the server generates scene visibility data PVSOptLevelStreaming for each visibility detection partition and packages the scene visibility data PVSOptLevelStreaming of each visibility detection partition into the game application. In this way, after the terminal installs the game application, it can access the scene visibility data PVSOptLevelStreaming of the visibility detection partition to which the target detection unit belongs locally, and can query the unit visibility data of the target detection unit itself. This unit visibility data can indicate whether the various associated areas of the visibility detection partition to which the target detection unit belongs are globally visible. Since the determination of the region to be loaded in step 702 is based on the bounding sphere of the controlled virtual object, and the associated region is equivalent to the entire visibility detection partition, and the visibility detection partition can obviously encompass the bounding sphere of the controlled virtual object, it can be known that the region to be loaded at the current position must be a subset of the associated region of the entire visibility detection partition. Therefore, based on the unit visibility data accessed in step 703, it is certain that the visibility of each region to be loaded in the scene loading list can be queried.

[0239] In some embodiments, to save storage space, game applications typically compress the scene visibility data PVSOptLevelStreaming for each visibility detection partition (PVS level) when saving the PVSOptLevelStreaming. Therefore, during game application operation, since scene streaming needs to be added and unloaded in real time, as the game progresses, the cached PVSOptLevelStreaming for previously decompressed PVS levels is stored. This means that if the same PVS level's PVSOptLevelStreaming data needs to be accessed again, there's no need to decompress it repeatedly; only the cached PVSOptLevelStreaming data needs to be accessed, improving the efficiency of accessing the PVSOptLevelStreaming data. In other words, when the terminal accesses the scene visibility data PVSotLevelStreaming of the current PVS level (i.e., the visibility detection partition to which the target detection unit belongs in the current frame), it first checks whether the cache contains the scene visibility data PVSotLevelStreaming of the current PVS level. If it does, there is no need to decompress it repeatedly; it can directly access the scene visibility data PVSotLevelStreaming of the current PVS level in the cache and find the unit visibility data of the target detection unit. If not, it needs to query and decompress the scene visibility data PVSotLevelStreaming of the current PVS level in the game application's Software Development Kit (SDK) to access the unit visibility data of the target detection unit in the decompressed PVSotLevelStreaming data.

[0240] 704. Based on the unit visibility data, the terminal determines the visibility of the at least one region to be loaded to the controlled virtual object.

[0241] In some embodiments, for any region to be loaded determined in step 702, the terminal uses the region identifier of the region to be loaded as an index value to query the bit indicated by the index value in the unit visibility data to obtain the visibility of the region to be loaded to the controlled virtual object. For example, if the bit is recorded as binary data, and the binary data is set to 0 to represent invisible and 1 to represent visible, then if the bit read is 0, it is determined that the region to be loaded is invisible to the controlled virtual object, and if the bit read is 1, it is determined that the region to be loaded is visible to the controlled virtual object. The settings of other binary data or the settings of Boolean data recorded in the bit are not described here, and are the same as those described in the previous embodiment.

[0242] In some embodiments, each region to be loaded determined in step 702 is traversed, and the visibility of each region to be loaded to the controlled virtual object is queried in the unit visibility data accessed in step 703, and then the process proceeds to step 705.

[0243] It should be noted that this explanation only uses the terminal-side query unit visibility data to determine the visibility of the area to be loaded as an example. In other embodiments, the server can also access the unit visibility data of the target detection unit after receiving the location of the synchronized controlled virtual object and calculating the current frame scene loading list, thereby determining the visibility of each area to be loaded in the scene loading list. This application does not specifically limit the execution subject.

[0244] 705. The terminal removes from the at least one loadable area the unit visibility data indicates is not visible to the controlled virtual object.

[0245] In some embodiments, for each of the at least one loadable regions, the visibility of the loadable region to the controlled virtual object can be queried in step 704. Then, if the queried visibility indicates that the loadable region is not visible to the controlled virtual object, the loadable region is removed from the scene loading list and added to the scene unloading list. If the queried visibility indicates that the loadable region is visible to the controlled virtual object, the next loadable region is determined, and the above operation is repeated until all loadable regions are traversed. In this way, the final scene loading list no longer contains scene regions that are not visible to the controlled virtual object. It is possible to perform secondary filtering on the loadable regions in the scene loading list based on PVS data, which effectively reduces the number of loadable regions in each frame.

[0246] It should be noted that this explanation only takes the removal of invisible areas to be loaded on the terminal side as an example. In other embodiments, after the server receives the location of the synchronized controlled virtual object and calculates the current frame scene loading list, the server can access the unit visibility data of the target detection unit to determine the visibility of each area to be loaded in the scene loading list and remove the invisible areas to be loaded from the scene loading list. This application does not specifically limit the execution subject.

[0247] 706. The terminal loads the scene data of each region to be loaded from the server after the removal process.

[0248] In some embodiments, after the terminal removes invisible loading areas from the scene loading list in step 705, the scene loading list no longer contains scene areas invisible to the controlled virtual object. At this point, the terminal can retrieve scene data for each remaining loading area from the server, enabling it to render the scene area surrounding the controlled virtual object in real time based on the received scene data for each loading area, thus drawing each frame of real-time game footage. Optionally, after the terminal loads the scene data for each remaining loading area from the server, the GameThread submits the loaded scene data for each loading area to the RenderThread. The RenderThread performs OC detection on each virtual object in the remaining loading areas, submits the virtual objects that pass OC detection to the RHIThread, and the RHIThread drives the rendering pipeline on the GPU to render the virtual objects that pass OC detection in real time, obtaining the game footage of the current frame, and displaying the game footage of the current frame on the terminal screen.

[0249] In the above process, the calculated scene loading list is filtered a second time based on the PVS visibility of the area to be loaded. This ensures that even if a scene area is within the loading range of the controlled virtual object, if the scene area is completely invisible, it means that the scene area does not contribute to the game screen and will only increase the running memory of the game application and the OC burden during rendering. By eliminating such areas that are globally invisible according to PVS visibility, the scene areas that actually need to be loaded in each frame can be accurately determined, greatly reducing the number of levels that need to be loaded in each frame.

[0250] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0251] The method provided in this application, based on configuring the loading and unloading of scene regions according to the distance between the controlled virtual object and the scene region, further determines the PVS visibility of the region to be loaded within the loading range. This ensures that regions that are completely occluded and therefore globally invisible are removed from the scene loading list and no longer become regions that need to be loaded by the terminal. This greatly reduces the number of regions to be loaded in each frame of the game application, reduces the memory occupied by the game application during runtime, and alleviates the OC burden of only performing occlusion removal on loaded regions, thereby greatly improving game running efficiency and optimizing the terminal's processing performance.

[0252] The above embodiments detail how the terminal utilizes the constructed scene visibility data PVSotLevelStreaming in real-time rendering to perform secondary filtering on the scene loading list calculated in the real-time scene streaming loading and unloading technology LevelStreaming, eliminating a large number of unloading areas that do not actually contribute to the game screen. This application embodiment will introduce a possible implementation scheme for optimizing the scene streaming loading and unloading technology LevelStreaming based on PVS.

[0253] Figure 8 This is a flowchart of a scheme for optimizing LevelStreaming based on PVS, as provided in an embodiment of this application. Figure 8 As shown, this embodiment can be executed independently by the terminal, independently by the server, or through interaction between the terminal and the server. This application does not specifically limit the executing entity; both the terminal and the server are exemplary computer devices. This embodiment includes the following steps:

[0254] 801. Based on the scenario-based streaming logic for adding and unloading LevelStreaming, dynamically add and unload PVSLevels and integrate PVS data.

[0255] Since PVS data is stored in blocks along with PVSLevel, and PVSOPtLevelStreaming data is not filtered along with PVSLevels, the LevelStreaming logic can be used to integrate dynamically loaded PVSLevel and its PVSOPtLevelStreaming data together to achieve streaming loading and unloading of PVS data. Here, PVS data refers to the PVSOPtLevelStreaming data of PVSLevel.

[0256] 802. Based on the location of the controlled virtual object, determine the currently used PVSCell, and if necessary, decompress and obtain scene visibility data PVSOptLevelStreaming in real time.

[0257] To save storage space, PVSLevel's PVSLevel Streaming data is usually compressed and stored in blocks. Therefore, PVSLevel Streaming data that has been decompressed in previous historical frames can be cached for subsequent repeated calls. This avoids the latency caused by repeated decompression and further improves game running efficiency through caching technology.

[0258] 803. Execute distance-based LevelStreaming logic, obtain the original scene loading list, traverse each region to be loaded in the scene loading list, and based on the region identifier LevelUniqueId and scene visibility data PVSOptLevelStreaming of the region to be loaded, confirm whether the region to be loaded is visible to the PVSCCell where the controlled virtual object is located, remove invisible regions to be loaded from the scene loading list, and add the removed regions to the scene unloading list.

[0259] For example, for each region to be loaded in the scene loading list, based on its region identifier LevelUniqueId, the binary data stored in the LevelUniqueId bit of the PVSOPtLevelStreaming data is read. Assuming a value of 0 represents invisible and a value of 1 represents visible, the visibility of the region to be loaded can be determined based on the value of the binary data recorded in the read bit. For example, a read bit of 1 indicates visibility, and a read bit of 0 indicates invisibility. Then, regions determined to be PVS invisible (e.g., a read bit of 0) are removed from the scene loading list and added to the scene unloading list, thus achieving dynamic updates to both the scene loading and scene unloading lists.

[0260] 804. Submit the scene loading list after removal and the updated scene uninstallation list, and perform the actual loading and uninstallation operations.

[0261] In this embodiment of the application, it is obvious that due to the filtering logic in step 803, the areas to be loaded in the scene loading list will be removed because PVS is not visible. This means that the number of areas to be loaded in the scene loading list will be reduced due to the filtering of PVSOPtLevelStreaming data. This greatly reduces the number of areas to be loaded in each frame, and thus reduces the memory occupied by the game application during runtime.

[0262] Furthermore, since the number of regions to be loaded has been reduced, it means that all virtual objects in the regions to be loaded no longer need to be loaded. These removed virtual objects will not participate in the Objective-C calculations during the rendering process, which can greatly reduce the burden on Objective-C. In addition, the reduction in the number of virtual objects in memory also helps to save the computing power of the CPU and even the GPU, thereby improving the efficiency of game operation.

[0263] Regarding the PVS-based optimized LevelStreaming solution involved in the embodiments of this application, a test is conducted using a certain game application as an example, such as... Figure 9 As shown, Figure 9 This is a test effect diagram of a PVS-based optimized LevelStreaming scheme involved in the embodiments of this application. As can be seen, during game operation, after loading several PVS data blocks near the position of the controlled virtual object, standard OC data is put into the occlusion culling process of virtual objects in the scene area, and PVS_SOptLevelStreaming data is put into the filtering process of the scene loading list calculated in the LevelStreaming logic. After filtering the scene loading list of each frame using the above PVS data, up to 131 scene areas that originally needed to be loaded can be filtered out in a certain frame. That is, the number of areas to be loaded is reduced by 131. Since the game application can reduce the number of scene areas that need to be loaded in each frame during real-time operation, this obviously greatly improves the scene loading efficiency of the game and saves the terminal's CPU and GPU computing power, thereby optimizing the game's running efficiency and optimizing the terminal's processing performance.

[0264] Figure 10 This is a schematic diagram of the structure of a scene visibility data generation device provided in an embodiment of this application, such as... Figure 10 As shown, the device includes:

[0265] The determining module 1001 is used to determine at least one associated region of any one of the multiple visibility detection zones in the virtual world from multiple scene regions of the virtual world.

[0266] Baking module 1002 is used to bake the at least one associated region to obtain occlusion clipping data of the at least one associated region, the occlusion clipping data indicating the visibility of virtual objects located in the associated region;

[0267] The generation module 1003 is used to generate unit visibility data of any visibility detection unit in the visibility detection partition based on the occlusion and clipping data of the at least one associated region. The unit visibility data indicates whether the associated region is globally visible to the visibility detection unit.

[0268] The acquisition module 1004 is used to acquire scene visibility data of the visibility detection partition based on the unit visibility data of each visibility detection unit.

[0269] The apparatus provided in this application provides occlusion and clipping data (OC data) for visibility determination by partially baking only the associated regions of a visibility detection partition (PVS level) in the virtual world. The OC data is then used to determine the visibility of each PVS unit to each associated region within the PVS level, further generating overall scene visibility data for the PVS level. This allows the scene visibility data to record the visibility of each associated region of the PVS level to each PVS unit. Thus, the scene visibility data can easily determine the visibility of each associated region of the PVS level to any PVS unit, facilitating decisions on which surrounding scene regions do not need to be loaded when a virtual object is in a PVS unit. Based on PVS technology, a method for filtering surrounding scene regions is provided. Therefore, based on the generated scene visibility data, the number of scene regions that need to be loaded in real-time in scene streaming loading and unloading technology is reduced, significantly improving real-time scene loading efficiency, reducing the consumption of terminal memory by game applications, and thus improving terminal processing performance.

[0270] In some embodiments, based on Figure 10 The device comprises, wherein the generation module 1003 includes:

[0271] The determining unit is used to determine the starting index value and the ending index value of any associated region;

[0272] A query unit is used to query the visibility of each virtual object whose index value is located between the start index value and the end index value from the occluded cropped data;

[0273] The configuration unit is used to configure the visibility of the visibility detection unit to the associated region based on the visibility of each virtual object obtained from the query.

[0274] The generation unit is used to generate visibility data for each associated region based on the visibility of the visibility detection unit.

[0275] In some embodiments, the determining unit is used to:

[0276] The offset compensation amount of the associated region in the occlusion clipping data is determined as the starting index value;

[0277] The offset compensation amount of the next associated region in the occlusion clipping data is determined as the termination index value.

[0278] In some embodiments, each bit in the occlusion clipping data records the visibility of a virtual object, and each bit corresponds one-to-one with an index value; the query unit is used for:

[0279] For the occlusion clipping data, starting from the starting bit indicated by the starting index value, the visibility of the virtual object recorded in each bit is traversed until the ending bit indicated by the ending index value is reached.

[0280] In some embodiments, the configuration unit is used for:

[0281] If the visibility of all virtual objects obtained from the query indicates that they are not visible, then configure the visibility of the associated region to be invisible;

[0282] If the visibility indication of any virtual object obtained from the query is visible, configure the visibility of the associated region to be visible.

[0283] In some embodiments, the generating unit is used for:

[0284] Configure the initial unit visibility data for the visibility detection unit. Each bit in the unit visibility data records the visibility of an associated region, and the index value of each bit is the region identifier of the associated region recorded by that bit.

[0285] In the visibility data of this unit, the bit indicated by the region identifier of each associated region is assigned a value based on the visibility of each associated region.

[0286] In some embodiments, the determining module 1001 is configured to:

[0287] For any given scene region, determine the loading distance for that scene category based on the scene category of that scene region;

[0288] Based on this loading distance, the bounding box range of the visibility detection partition is expanded to obtain the first bounding box range;

[0289] If the first bounding box range intersects with the second bounding box range of the scene region, the scene region is identified as an associated region.

[0290] In some embodiments, the acquisition module 1004 is used for:

[0291] The unit visibility data of each visibility detection unit is merged to obtain the scene visibility data of the visibility detection partition, and the scene visibility data is associated with and stored with the visibility detection partition.

[0292] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0293] It should be noted that the scene visibility data generation device provided in the above embodiments, when generating scene visibility data for visibility detection partitions in the virtual world, is only illustrating the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computer device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the scene visibility data generation device and the scene visibility data generation method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the scene visibility data generation method embodiments, which will not be repeated here.

[0294] Figure 11 This is a schematic diagram of the structure of a scene loading device based on scene visibility data provided in an embodiment of this application, as shown below. Figure 11 As shown, the device includes:

[0295] The region determination module 1101 is used to determine at least one region to be loaded in the virtual world based on the location of the controlled virtual object in the virtual world;

[0296] Access module 1102 is used to access scene visibility data of the visibility detection partition to which the target detection unit where the controlled virtual object is located belongs, so as to obtain the unit visibility data of at least one associated region of the target detection unit to the visibility detection partition, and the unit visibility data indicates whether the associated region is globally visible to the target detection unit.

[0297] The visibility determination module 1103 is used to determine the visibility of the at least one region to be loaded to the controlled virtual object based on the visibility data of the unit;

[0298] The removal module 1104 is used to remove, from the at least one region to be loaded, regions from which the unit visibility data indicates that the controlled virtual object is not visible.

[0299] The apparatus provided in this application, by configuring the loading and unloading of scene regions based on the distance between the controlled virtual object and the scene region, further determines the PVS visibility of the region to be loaded within the loading range. This ensures that regions that are completely occluded and therefore globally invisible are removed from the scene loading list and no longer become regions that need to be loaded by the terminal. This greatly reduces the number of regions to be loaded in each frame of the game application, reduces the memory occupied by the game application, and alleviates the OC burden of only performing occlusion removal on loaded regions, thereby greatly improving game running efficiency and optimizing the terminal's processing performance.

[0300] In some embodiments, the visibility determination module 1103 is used to:

[0301] For any region to be loaded, the region identifier of the region to be loaded is used as the index value. The bit indicated by the index value is queried in the visibility data of the unit to obtain the visibility of the region to be loaded to the controlled virtual object.

[0302] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0303] It should be noted that the scene loading device based on scene visibility data provided in the above embodiments is only illustrated by the division of the above functional modules when performing scene streaming loading and unloading based on scene visibility data. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computer device can be divided into different functional modules to complete all or part of the functions described above. In addition, the scene loading device based on scene visibility data provided in the above embodiments and the scene loading method embodiment based on scene visibility data belong to the same concept. For details of its specific implementation process, please refer to the scene loading method embodiment based on scene visibility data, which will not be repeated here.

[0304] Figure 12 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application, such as... Figure 12 As shown, terminal 1200 is an exemplary illustration of a computer device. Optionally, the device type of terminal 1200 includes: a smartphone, tablet computer, MP3 player (Moving Picture Experts Group Audio Layer III), MP4 player (Moving Picture Experts Group Audio Layer IV), laptop computer, or desktop computer. Terminal 1200 may also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or other names.

[0305] Typically, terminal 1200 includes a processor 1201 and a memory 1202.

[0306] Optionally, the processor 1201 includes one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Optionally, the processor 1201 is implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). In some embodiments, the processor 1201 includes a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 1201 integrates a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 1201 also includes an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0307] In some embodiments, the memory 1202 includes one or more computer-readable storage media, optionally non-transitory. Optionally, the memory 1202 also includes high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1202 is used to store at least one program code, which is executed by the processor 1201 to implement the scene loading method based on scene visibility data provided in the various embodiments of this application.

[0308] In some embodiments, the terminal 1200 may also optionally include a peripheral device interface 1203 and at least one peripheral device. The processor 1201, memory 1202, and peripheral device interface 1203 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 1203 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: radio frequency circuitry 1204, display screen 1205, camera assembly 1206, audio circuitry 1207, and power supply 1208.

[0309] Peripheral device interface 1203 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 1201 and memory 1202. In some embodiments, processor 1201, memory 1202 and peripheral device interface 1203 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 1201, memory 1202 and peripheral device interface 1203 are implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0310] The radio frequency (RF) circuit 1204 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 1204 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 1204 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 1204 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. Optionally, the RF circuit 1204 communicates with other terminals via at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: metropolitan area networks (MANs), various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks (WLANs), and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 1204 also includes circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0311] Display screen 1205 is used to display a UI (User Interface). Optionally, the UI includes graphics, text, icons, videos, and any combination thereof. When display screen 1205 is a touch display screen, display screen 1205 also has the ability to collect touch signals on or above the surface of display screen 1205. The touch signals can be input to processor 1201 for processing as control signals. Optionally, display screen 1205 is also used to provide virtual buttons and / or virtual keyboards, also known as soft buttons and / or soft keyboards. In some embodiments, there is one display screen 1205, which is set on the front panel of terminal 1200; in other embodiments, there are at least two display screens 1205, which are respectively set on different surfaces of terminal 1200 or have a folded design; in still other embodiments, display screen 1205 is a flexible display screen, which is set on the curved surface or folded surface of terminal 1200. Furthermore, optionally, display screen 1205 is set as a non-rectangular irregular shape, that is, an irregularly shaped screen. Optionally, the display screen 1205 is made of materials such as LCD (Liquid Crystal Display) or OLED (Organic Light-Emitting Diode).

[0312] The camera assembly 1206 is used to acquire images or videos. Optionally, the camera assembly 1206 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 1206 also includes a flash. Optionally, the flash is a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm-light flash and a cool-light flash, used for light compensation at different color temperatures.

[0313] In some embodiments, the audio circuit 1207 includes a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, and convert the sound waves into electrical signals that are input to the processor 1201 for processing, or input to the radio frequency circuit 1204 to realize voice communication. For stereo acquisition or noise reduction purposes, multiple microphones are used, respectively located at different parts of the terminal 1200. Optionally, the microphone is an array microphone or an omnidirectional acquisition microphone. The speaker is used to convert electrical signals from the processor 1201 or the radio frequency circuit 1204 into sound waves. Optionally, the speaker is a conventional film speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can not only convert electrical signals into sound waves that humans can hear, but also convert electrical signals into sound waves that humans cannot hear for purposes such as distance measurement. In some embodiments, the audio circuit 1207 also includes a headphone jack.

[0314] The power supply 1208 is used to power the various components in the terminal 1200. Optionally, the power supply 1208 is AC power, DC power, a disposable battery, or a rechargeable battery. When the power supply 1208 includes a rechargeable battery, the rechargeable battery supports wired or wireless charging. The rechargeable battery also supports fast charging technology.

[0315] In some embodiments, the terminal 1200 further includes one or more sensors 1210. The one or more sensors 1210 include, but are not limited to: an acceleration sensor 1211, a gyroscope sensor 1212, a pressure sensor 1213, an optical sensor 1214, and a proximity sensor 1215.

[0316] In some embodiments, the accelerometer 1211 detects the magnitude of acceleration along the three coordinate axes of a coordinate system established with the terminal 1200. For example, the accelerometer 1211 is used to detect the components of gravitational acceleration along the three coordinate axes. Optionally, the processor 1201 controls the display screen 1205 to display the user interface in either a landscape or portrait view based on the gravitational acceleration signal acquired by the accelerometer 1211. The accelerometer 1211 is also used for acquiring motion data from games or the user.

[0317] In some embodiments, the gyroscope sensor 1212 detects the orientation and rotation angle of the terminal 1200. The gyroscope sensor 1212 and the accelerometer sensor 1211 work together to acquire the user's 3D movements on the terminal 1200. Based on the data acquired by the gyroscope sensor 1212, the processor 1201 implements the following functions: motion sensing (e.g., changing the UI based on the user's tilt operation), image stabilization during shooting, game control, and inertial navigation.

[0318] Optionally, the pressure sensor 1213 is disposed on the side bezel of the terminal 1200 and / or on the lower layer of the display screen 1205. When the pressure sensor 1213 is disposed on the side bezel of the terminal 1200, it can detect the user's grip signal on the terminal 1200, and the processor 1201 performs left / right hand recognition or quick operation based on the grip signal collected by the pressure sensor 1213. When the pressure sensor 1213 is disposed on the lower layer of the display screen 1205, the processor 1201 controls the operable controls on the UI interface based on the user's pressure operation on the display screen 1205. The operable controls include at least one of button controls, scroll bar controls, icon controls, and menu controls.

[0319] Optical sensor 1214 is used to collect ambient light intensity. In one embodiment, processor 1201 controls the display brightness of display screen 1205 based on the ambient light intensity collected by optical sensor 1214. Specifically, when the ambient light intensity is high, the display brightness of display screen 1205 is increased; when the ambient light intensity is low, the display brightness of display screen 1205 is decreased. In another embodiment, processor 1201 also dynamically adjusts the shooting parameters of camera assembly 1206 based on the ambient light intensity collected by optical sensor 1214.

[0320] The proximity sensor 1215, also known as a distance sensor, is typically mounted on the front panel of the terminal 1200. The proximity sensor 1215 is used to detect the distance between the user and the front of the terminal 1200. In one embodiment, when the proximity sensor 1215 detects that the distance between the user and the front of the terminal 1200 is gradually decreasing, the processor 1201 controls the display screen 1205 to switch from a screen-on state to a screen-off state; when the proximity sensor 1215 detects that the distance between the user and the front of the terminal 1200 is gradually increasing, the processor 1201 controls the display screen 1205 to switch from a screen-off state to a screen-on state.

[0321] Those skilled in the art will understand that Figure 12 The structure shown does not constitute a limitation on terminal 1200, and it may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0322] Figure 13This is a schematic diagram of a server structure provided in an embodiment of this application. The server 1300 is an exemplary illustration of a computer device. The server 1300 can vary significantly due to differences in configuration or performance. The server 1300 includes one or more Central Processing Units (CPUs) 1301 and one or more memories 1302. The memories 1302 store at least one computer program, which is loaded and executed by the one or more processors 1301 to implement the scene visibility data generation method or the scene loading method based on scene visibility data provided in the various embodiments above. Optionally, the server 1300 also has wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The server 1300 also includes other components for implementing device functions, which will not be elaborated here.

[0323] In exemplary embodiments, a computer-readable storage medium is also provided, such as a memory including at least one computer program, which can be executed by a processor in a computer device to perform the scene visibility data generation method or the scene loading method based on scene visibility data in the various embodiments described above. For example, the computer-readable storage medium includes ROM (Read-Only Memory), RAM (Random-Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, and optical data storage devices, etc.

[0324] In an exemplary embodiment, a computer program product is also provided, including one or more computer programs stored in a computer-readable storage medium. One or more processors of a computer device are capable of reading the one or more computer programs from the computer-readable storage medium, and the one or more processors execute the one or more computer programs, enabling the computer device to perform a method for generating scene visibility data or a scene loading method based on scene visibility data as described in the above embodiments.

[0325] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. Optionally, the program is stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0326] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for generating scene visibility data, characterized in that, The method includes: For any one of the multiple visibility detection partitions in the virtual world, determine at least one associated region of the visibility detection partition from the multiple scene regions of the virtual world, wherein the at least one associated region is a scene region where the bounding box extent of the visibility detection partition intersects with the bounding box extent of the scene region; Baking is performed on the at least one associated region to obtain occlusion clipping data for the at least one associated region, the occlusion clipping data indicating the visibility of virtual objects located in the associated region; For any visibility detection unit in the visibility detection partition, based on the occlusion and clipping data of the at least one associated region, unit visibility data of the visibility detection unit to the at least one associated region is generated, and the unit visibility data indicates whether the associated region is globally visible to the visibility detection unit; The unit visibility data of each visibility detection unit is merged to obtain the scene visibility data of the visibility detection partition, and the scene visibility data is associated with and stored with the visibility detection partition.

2. The method according to claim 1, characterized in that, The step of generating unit visibility data for the at least one associated region based on the occlusion and clipping data of the at least one associated region includes: For any of the associated regions, determine the starting index value and the ending index value of the associated region; From the occlusion and clipping data, query the visibility of each virtual object whose index value lies between the start index value and the end index value; Based on the visibility of each virtual object obtained from the query, configure the visibility detection unit to the visibility of the associated region; Based on the visibility of each associated region by the visibility detection unit, the unit visibility data is generated.

3. The method according to claim 2, characterized in that, Determining the starting and ending index values ​​of the associated region includes: The offset compensation amount of the associated region in the occlusion clipping data is determined as the starting index value; The offset compensation amount of the next associated region in the occlusion clipping data is determined as the termination index value.

4. The method according to claim 2, characterized in that, Each bit in the occlusion and clipping data records the visibility of a virtual object, and each bit corresponds one-to-one with an index value. The step of querying the visibility of each virtual object whose index value lies between the start index value and the end index value from the occlusion cropping data includes: For the occlusion clipping data, starting from the starting bit indicated by the starting index value, the visibility of the virtual object recorded in each bit is traversed until the ending bit indicated by the ending index value is reached.

5. The method according to claim 2, characterized in that, The configuration of the visibility detection unit for the associated region based on the visibility of each virtual object obtained from the query includes: If the visibility of all the virtual objects obtained from the query indicates that they are not visible, then the visibility of the associated region will be configured to be invisible. If the visibility indication of any virtual object obtained from the query is visible, configure the visibility of the associated region to be visible.

6. The method according to claim 2, characterized in that, The process of generating the unit visibility data based on the visibility of each associated region by the visibility detection unit includes: Configure the visibility detection unit with initialized unit visibility data, wherein each bit in the unit visibility data records the visibility of an associated region, and the index value of each bit is the region identifier of the associated region recorded by the bit; In the unit visibility data, the bit indicated by the region identifier of each associated region is assigned a value based on the visibility of each associated region.

7. The method according to claim 1, characterized in that, Determining at least one associated region of the visibility detection partition from multiple scene regions of the virtual world includes: For any of the scene regions, the loading distance of the scene category is determined based on the scene category of the scene region; Based on the loading distance, the bounding box range of the visibility detection partition is expanded to obtain the first bounding box range; When the first bounding box range intersects with the second bounding box range of the scene region, the scene region is determined as an associated region.

8. A scene loading method based on scene visibility data, characterized in that, The method includes: Based on the location of the controlled virtual object in the virtual world, at least one region to be loaded in the virtual world is determined; Access the scene visibility data of the visibility detection partition to which the target detection unit where the controlled virtual object is located belongs, so as to obtain the unit visibility data of at least one associated region of the visibility detection partition. The unit visibility data indicates whether the associated region is globally visible to the target detection unit. The scene visibility data of the visibility detection partition is obtained by merging the unit visibility data of each visibility detection unit. The scene visibility data is stored in association with the visibility detection partition. The at least one associated region is the scene region where the bounding box range of the visibility detection partition intersects with the bounding box range of the scene region. Based on the unit visibility data, determine the visibility of the at least one region to be loaded to the controlled virtual object; From the at least one region to be loaded, remove the regions from the unit visibility data that indicate that the controlled virtual object is not visible.

9. The method according to claim 8, characterized in that, Determining the visibility of the at least one region to be loaded to the controlled virtual object based on the unit visibility data includes: For any of the regions to be loaded, the region identifier of the region to be loaded is used as the index value. The bit indicated by the index value is queried in the unit visibility data to obtain the visibility of the region to be loaded to the controlled virtual object.

10. A device for generating scene visibility data, characterized in that, The device includes: The determination module is used to determine at least one associated region of any one of the multiple visibility detection partitions in the virtual world from multiple scene regions of the virtual world. The at least one associated region is a scene region where the bounding box range of the visibility detection partition intersects with the bounding box range of the scene region. A baking module is used to bake the at least one associated region to obtain occlusion and clipping data of the at least one associated region, wherein the occlusion and clipping data indicates the visibility of virtual objects located in the associated region; A generation module is used to generate unit visibility data of any visibility detection unit in the visibility detection partition based on the occlusion and clipping data of the at least one associated region. The unit visibility data indicates whether the associated region is globally visible to the visibility detection unit. The acquisition module is used to merge the unit visibility data of each visibility detection unit to obtain the scene visibility data of the visibility detection partition, and to associate and store the scene visibility data with the visibility detection partition.

11. The apparatus according to claim 10, characterized in that, The generation module includes: The determining unit is configured to determine the starting index value and the ending index value of any of the associated regions; A query unit is used to query the visibility of each virtual object whose index value is located between the start index value and the end index value from the occlusion and cropping data; A configuration unit is used to configure the visibility detection unit to the visibility of the associated region based on the visibility of each virtual object obtained from the query. A generation unit is used to generate the unit visibility data based on the visibility of each associated region by the visibility detection unit.

12. The apparatus according to claim 11, characterized in that, The determining unit is used for: The offset compensation amount of the associated region in the occlusion clipping data is determined as the starting index value; The offset compensation amount of the next associated region in the occlusion clipping data is determined as the termination index value.

13. The apparatus according to claim 11, characterized in that, Each bit in the occlusion and clipping data records the visibility of a virtual object, and each bit corresponds one-to-one with an index value; the query unit is used for: For the occlusion clipping data, starting from the starting bit indicated by the starting index value, the visibility of the virtual object recorded in each bit is traversed until the ending bit indicated by the ending index value is reached.

14. The apparatus according to claim 11, characterized in that, The configuration unit is used for: If the visibility of all the virtual objects obtained from the query indicates that they are not visible, then the visibility of the associated region will be configured to be invisible. If the visibility indication of any virtual object obtained from the query is visible, configure the visibility of the associated region to be visible.

15. The apparatus according to claim 11, characterized in that, The generation unit is used for: Configure the visibility detection unit with initialized unit visibility data, wherein each bit in the unit visibility data records the visibility of an associated region, and the index value of each bit is the region identifier of the associated region recorded by the bit; In the unit visibility data, the bit indicated by the region identifier of each associated region is assigned a value based on the visibility of each associated region.

16. The apparatus according to claim 10, characterized in that, The determining module is used for: For any of the scene regions, the loading distance of the scene category is determined based on the scene category of the scene region; Based on the loading distance, the bounding box range of the visibility detection partition is expanded to obtain the first bounding box range; When the first bounding box range intersects with the second bounding box range of the scene region, the scene region is determined as an associated region.

17. A scene loading device based on scene visibility data, characterized in that, The device includes: The region determination module is used to determine at least one region to be loaded in the virtual world based on the location of the controlled virtual object in the virtual world; An access module is used to access the scene visibility data of the visibility detection partition to which the target detection unit where the controlled virtual object is located belongs, so as to obtain the unit visibility data of at least one associated region of the visibility detection partition. The unit visibility data indicates whether the associated region is globally visible to the target detection unit. The scene visibility data of the visibility detection partition is obtained by merging the unit visibility data of each visibility detection unit. The scene visibility data is stored in association with the visibility detection partition. The at least one associated region is the scene region where the bounding box range of the visibility detection partition intersects with the bounding box range of the scene region. A visibility determination module is used to determine the visibility of the at least one region to be loaded to the controlled virtual object based on the unit visibility data; A removal module is used to remove, from the at least one region to be loaded, regions from which the unit visibility data indicates that the controlled virtual object is not visible.

18. The apparatus according to claim 17, characterized in that, The visibility determination module is used for: For any of the regions to be loaded, the region identifier of the region to be loaded is used as the index value. The bit indicated by the index value is queried in the unit visibility data to obtain the visibility of the region to be loaded to the controlled virtual object.

19. A computer device, characterized in that, The computer device includes one or more processors and one or more memories, wherein at least one computer program is stored in the one or more memories, and the at least one computer program is loaded and executed by the one or more processors to implement the scene visibility data generation method as described in any one of claims 1 to 7; or, the scene loading method based on scene visibility data as described in any one of claims 8 to 9.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which is loaded and executed by a processor to implement the method for generating scene visibility data as described in any one of claims 1 to 7; or, the scene loading method based on scene visibility data as described in any one of claims 8 to 9.

21. A computer program product, characterized in that, The computer program product includes at least one computer program, which is loaded and executed by a processor to implement the scene visibility data generation method as described in any one of claims 1 to 7; or, the scene loading method based on scene visibility data as described in any one of claims 8 to 9.

Images