Method for processing scene data, method and device for putting virtual resource

Abstract

The application discloses a scene data processing method and device, computer equipment and a storage medium, and belongs to the technical field of computers. The application performs post-processing on scene navigation data of a virtual scene, first divides a first target region from the virtual scene to roughly exclude isolated regions that cannot be walked on, and then divides a second target region in the first target region to finely exclude regions that cannot be returned after moving. In this way, the second target region obtained through post-processing has very high accessibility, manual point arrangement is not required, the human cost of scene data processing can be saved, and the accuracy of data processing can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer device, and storage medium for processing scene data. Background Technology

[0002] With the development of computer technology and the diversification of terminal functions, the types of games that can be played on terminals are increasing. During game matches, it is often necessary to process the scene data of the game map to realize the in-game deployment of virtual resources or the in-game refresh of virtual objects. Virtual resources include virtual treasure chests, virtual resources, virtual props, and virtual items, while virtual objects include game bots such as AI companions (Artificial Intelligence), NPCs (Non-Player Characters), and monsters.

[0003] Whether determining the placement points of virtual resources or the refresh points of virtual objects, manual placement is usually adopted. This involves manually setting up multiple candidate points in the virtual scene, and randomly selecting some of these candidate points during the game to place virtual resources or refresh virtual objects. However, for some virtual scenes with huge areas and complex terrain, manual placement will bring huge manpower costs, and the selected candidate points are often located in places that players cannot reach (such as high platforms or gaps). Therefore, the manpower cost and accuracy of scene data processing are high. Summary of the Invention

[0004] This application provides a method, apparatus, computer device, and storage medium for processing scene data, which can save labor costs and improve the accuracy of scene data processing. The technical solution is as follows:

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

[0006] Acquire scene navigation data of a virtual scene, wherein the scene navigation data is used to indicate the space in the virtual scene where virtual objects can move;

[0007] Based on the scene navigation data, a first target area in the virtual scene is determined, and the first target area is used to indicate a one-way connected area that the virtual object in the virtual scene can reach.

[0008] A second target region is determined from the first target region, the second target region being used to indicate a bidirectionally connected region in the virtual scene that the virtual object can reach and return to.

[0009] On the one hand, a method for deploying virtual resources is provided, the method comprising:

[0010] In response to a request to deploy virtual resources, scene navigation data of the virtual scene is obtained, wherein the scene navigation data is used to indicate the space in the virtual scene where virtual objects can move.

[0011] A second target region determined based on the scene navigation data is obtained. The second target region is used to indicate a bidirectionally connected region in the virtual scene that the virtual object can reach and return to.

[0012] The virtual resource is deployed to the target location in the second target area within the virtual scene.

[0013] On the one hand, a scene data processing device is provided, the device comprising:

[0014] The acquisition module is used to acquire scene navigation data of the virtual scene, wherein the scene navigation data is used to indicate the space in the virtual scene where virtual objects can move.

[0015] The first determining module is used to determine a first target area in the virtual scene based on the scene navigation data. The first target area is used to indicate a one-way connected area that the virtual object in the virtual scene can reach.

[0016] The second determining module is used to determine a second target region from the first target region, wherein the second target region is used to indicate a bidirectionally connected region in the virtual scene that the virtual object can reach and return to.

[0017] In one possible implementation, the first determining module includes:

[0018] The first determining unit is used to determine multiple first candidate regions in the virtual scene based on the scene navigation data, where each first candidate region is a unidirectional connected region that the virtual object can reach from the corresponding root node.

[0019] The first filtering unit is used to filter the first target region from the plurality of first candidate regions.

[0020] In one possible implementation, the first determining unit is configured to:

[0021] For any unvisited grid in the scene navigation data, take the grid as the root node, determine all grids that can be reached from the root node, and define the area formed by the grid and the determined grids as a first candidate area.

[0022] In one possible implementation, the first filtering unit is used to:

[0023] The first candidate region with the largest number of grid cells among the plurality of first candidate regions is determined as the first target region.

[0024] In one possible implementation, the second determining module includes:

[0025] The second determining unit is used to determine a plurality of second candidate regions from the first target region, each second candidate region being a bidirectionally connected region that the virtual object can reach and return from the corresponding root node;

[0026] The second filtering unit is used to filter the second target region from the plurality of second candidate regions.

[0027] In one possible implementation, the second determining unit is used to:

[0028] Based on the first target region, a search tree is constructed, wherein each node in the search tree corresponds to a grid in the first target region;

[0029] Push each unprocessed node in the search tree onto the stack. For the node at the top of the stack, when the timestamp and trace value of the node are equal, determine the region formed by each node in the search subtree rooted at the node as a second candidate region.

[0030] In one possible implementation, the second filtering unit is used for:

[0031] The second candidate region with the largest number of grid cells among the plurality of second candidate regions is determined as the second target region.

[0032] In one possible implementation, the device further includes:

[0033] The third determining module is used to determine the region parameter of each grid in the scene navigation data based on the region to which the grid belongs. The region parameter is used to indicate the accessibility of the virtual object's corresponding grid activity in the virtual scene.

[0034] In one possible implementation, the third determining module includes:

[0035] The third determining unit is used to determine the region parameter of the grid as a first value when the grid is located outside the first target region;

[0036] The third determining unit is further configured to, when the grid is located in the first target region, determine the region parameter of the grid as a second value, wherein the accessibility corresponding to the second value of the region parameter is greater than the accessibility corresponding to the first value.

[0037] In one possible implementation, the third determining unit is further configured to:

[0038] The multiple second candidate regions contained in the first target region are sorted in descending order of the number of grids contained therein. Each second candidate region is a bidirectionally connected region that the virtual object can reach and return from the corresponding root node.

[0039] For each grid in the first target region, the region parameter of the grid is determined as the sequence number of the second candidate region to which the grid belongs in the sorting.

[0040] In one possible implementation, the device further includes:

[0041] The delivery module is used to respond to a delivery request for virtual resources in the virtual scene and deliver the virtual resources to the second target area in the virtual scene.

[0042] In one possible implementation, the device further includes:

[0043] The fourth determining module is used to determine the starting grid and ending grid of the path planning request in response to a path planning request for a virtual object in the virtual scene.

[0044] The fifth determining module is used to determine the legality of the virtual object's movement from the starting grid to the ending grid when the starting grid and the ending grid are located in the same bidirectional connected region, or when the ending grid is located in the second target region.

[0045] On the one hand, a device for distributing virtual resources is provided, the device comprising:

[0046] The acquisition module is used to acquire scene navigation data of the virtual scene in response to the virtual resource delivery request. The scene navigation data is used to indicate the space in the virtual scene where virtual objects can move.

[0047] The acquisition module is further configured to acquire a second target area determined based on the scene navigation data, wherein the second target area is used to indicate a bidirectional connected area in the virtual scene that the virtual object can reach and return to;

[0048] The delivery module is used to deliver the virtual resources to the target location in the second target area within the virtual scene.

[0049] On one hand, a computer device is provided, which 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 a method for processing scene data or a method for deploying virtual resources as described in any of the above possible implementations.

[0050] On the one hand, a storage medium is provided that stores at least one computer program, which is loaded and executed by a processor to implement a method for processing scene data or a method for deploying virtual resources as described in any of the above possible implementations.

[0051] On one hand, a computer program product or computer program is provided, the computer program product or computer program comprising one or more lines of program code, the one or more lines of program code being stored in a computer-readable storage medium. One or more processors of a computer device are capable of reading the one or more lines of program code from the computer-readable storage medium, the one or more processors executing the one or more lines of program code, enabling the computer device to execute the scene data processing method or the virtual resource deployment method of 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 post-processing the scene navigation data of the virtual scene, a first target area that virtual objects can reach is first delineated from the virtual scene to roughly eliminate some isolated areas that virtual objects cannot walk in at all. Then, a second target area that virtual objects can reach and return to is delineated from the first target area to finely eliminate some areas that virtual objects cannot return to after moving there. This ensures that the second target area obtained after post-processing has a high accessibility. The second target area guides various downstream business needs in the deployment of virtual resources, the refreshing of virtual objects, and the path planning of virtual objects in the virtual scene. It can prevent virtual resources or virtual objects from appearing in areas that players cannot reach, and it eliminates the need for manual placement, saving manpower costs for scene data processing and improving the accuracy of data processing. 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 1This is a schematic diagram of the implementation environment of a scene data processing method provided in an embodiment of this application;

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

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

[0058] Figure 4 This is a flowchart illustrating a post-processing method for NavMesh navigation mesh data provided in an embodiment of this application;

[0059] Figure 5 This is a schematic diagram of raw NavMesh data provided in an embodiment of this application;

[0060] Figure 6 This is a schematic diagram of NavMesh data after removing unreachable areas, provided in an embodiment of this application;

[0061] Figure 7 This is a schematic diagram of a Poly marked as 1 in NavMesh data provided in an embodiment of this application;

[0062] Figure 8 This is a schematic diagram of a Poly with a marker greater than 1 in NavMesh data provided in an embodiment of this application;

[0063] Figure 9 This is a flowchart illustrating a method for deploying virtual resources according to an embodiment of this application;

[0064] Figure 10 This is a flowchart of a virtual object path planning method according to an embodiment of this application;

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

[0066] Figure 12 This is a schematic diagram of the structure of a virtual resource delivery device according to an embodiment of this application;

[0067] Figure 13 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application;

[0068] Figure 14 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

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

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

[0071] In this application, the term "at least one" means one or more, and "multiple" means two or more, for example, multiple first positions means two or more first positions.

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

[0073] The user-related information (including but not limited to user device information, data 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. Furthermore, 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 scene navigation data of the game played by the user involved in this application is obtained with full authorization.

[0074] A virtual scene is a virtual environment displayed (or provided) by an application when it runs on a terminal. This virtual scene can be a simulation of the real world, a semi-simulated / semi-fictional virtual environment, or a purely fictional virtual environment. A virtual scene can be any of a two-dimensional, 2.5-dimensional, or three-dimensional virtual scene; this application does not limit the dimension of the virtual scene. For example, a virtual scene may include a sky, land, ocean, etc., and the land may include environmental elements such as deserts and cities. Users can control virtual objects to move within this virtual scene. Optionally, the virtual scene can also be used for virtual scene combat between at least two virtual objects, and the virtual scene has virtual resources available for use by at least two virtual objects.

[0075] Virtual objects refer to movable objects in a virtual scene. These movable objects can be virtual characters, virtual animals, anime characters, etc., such as people, animals, plants, oil drums, walls, and stones displayed in a virtual scene. A virtual object can be a virtual avatar representing the user within the virtual scene. A virtual scene can include multiple virtual objects, each with its own shape and volume, occupying a portion of the space within the virtual scene. Optionally, when the virtual scene is a three-dimensional virtual scene, the virtual object can be a three-dimensional model. This three-dimensional model can be a three-dimensional character constructed based on three-dimensional human skeleton technology. The same virtual object can display different appearances by wearing different skins. In some embodiments, virtual objects can also be implemented using 2.5D or 2D models; this application does not limit this.

[0076] Optionally, the virtual object can be a player character controlled through client-side operations, a non-player character (NPC) that can interact within the virtual scene, a neutral virtual object (such as a monster that provides buffs), or a game bot (such as a companion AI bot) within the virtual scene. Illustratively, the virtual object is a virtual character competing in the virtual scene. Optionally, the number of virtual objects participating in the interaction in the virtual scene can be preset or dynamically determined based on the number of clients joining the interaction.

[0077] Virtual resources refer to a type of competitive resource that players can control to pick up or bind virtual objects during gameplay. Optionally, some virtual resources are pre-placed in the virtual scene at the start of the game, or some virtual resources are placed in the virtual scene during gameplay according to preset logic. The placement logic of virtual resources includes, but is not limited to: time-based placement logic (e.g., placement 5 minutes after the start of the game) and trigger-based placement logic (e.g., placement 30 seconds after defeating the first enemy virtual object). This application embodiment does not specifically limit the placement logic. After virtual resources are placed in the virtual scene, players can control virtual objects to search for and pick up virtual resources in the virtual scene. Optionally, virtual resources include, but are not limited to: virtual treasure chests, virtual supplies, virtual items, virtual props, etc. This application embodiment does not specifically limit the resource type of virtual resources.

[0078] Shooter games (STGs) refer to a type of game in which virtual objects use virtual weapons or similar items to launch ranged attacks. Shooter games are a type of action game and exhibit distinct characteristics of action games. Optionally, shooter games include, but are not limited to, first-person shooters, third-person shooters, top-down shooters, eye-level shooters, platform shooters, scrolling shooters, keyboard and mouse shooters, and shooting range games. This application does not specifically limit the type of shooter game.

[0079] First-person shooter (FPS) games: FPS games are shooting games that users can play from a first-person perspective. The virtual scene in the game is viewed from the perspective of a virtual object controlled by the terminal. In the game, at least two virtual objects engage in a single-round combat mode in a virtual scene. The virtual objects survive in the virtual scene by avoiding damage from other virtual objects and dangers present in the virtual scene (such as swamps). When a virtual object's health points in the virtual scene reach zero, its life ends, and the last surviving virtual object in the virtual scene is the winner. Optionally, the above combat begins when the first terminal joins the game and ends when the last terminal leaves the game. Each terminal can control one or more virtual objects in the virtual scene. Optionally, the competitive mode of the combat can include single-player combat mode, two-player team combat mode, or multiplayer team combat mode, etc. This application embodiment does not specifically limit the competitive mode.

[0080] Taking shooting games as an example, users can control virtual objects to freely fall, glide, or deploy parachutes in the sky within the virtual scene, run, jump, crawl, and bend forward on land, and swim, float, or dive in the ocean. Users can also control virtual objects to move within the virtual scene using virtual vehicles, such as virtual cars, virtual aircraft, and virtual yachts. These examples are merely illustrations and are not intended to limit the scope of this application. Users can also control virtual objects to interact with other virtual objects using virtual props. These props include throwable props that activate after being thrown, shooting props that activate after launching a projectile, and interactive props for close-range combat. Users can also control virtual objects to search for and collect virtual resources within the virtual scene, such as virtual treasure chests, virtual supplies, virtual items, and virtual props. Users can also control virtual objects to interact with game robots in virtual scenes. For example, they can control virtual objects to play games with AI companions, or control virtual objects to defeat neutral virtual objects such as monsters to obtain certain buffs.

[0081] The system architecture involved in this application will be described below.

[0082] Figure 1 This is a schematic diagram illustrating the implementation environment of a scene data processing method provided in an embodiment of this application. See also... Figure 1 The implementation environment includes: a first terminal 120, a server 140, and a second terminal 160.

[0083] The first terminal 120 has an application installed and running that supports virtual scenes. Optionally, the application includes any one of the following: an FPS game, a third-person shooter game, a MOBA (Multiplayer Online Battle Arena) game, a virtual reality application, a 3D map application, or a multiplayer survival game. In some embodiments, the first terminal 120 is a terminal used by a first user. When the first terminal 120 runs the application, the user interface of the application is displayed on the screen of the first terminal 120, and based on the first user's initial actions in the user interface, a virtual scene is loaded and displayed in the application. The first user uses the first terminal 120 to operate a first virtual object located in the virtual scene to perform activities, including but not limited to: adjusting body posture, crawling, walking, running, riding, jumping, driving, picking up, shooting, attacking, throwing, and fighting. Illustratively, the first virtual object is a first virtual character, such as a realistic or anime character.

[0084] The first terminal 120 and the second terminal 160 communicate directly or indirectly with the server 140 via a wireless network or a wired network.

[0085] Server 140 includes at least one of a single server, multiple servers, a cloud computing platform, or a virtualization center. Server 140 is used to provide background services for applications supporting virtual scenarios. Optionally, server 140 undertakes the main computing work, and the first terminal 120 and the second terminal 160 undertake secondary computing work; or, server 140 undertakes secondary computing work, and the first terminal 120 and the second terminal 160 undertake the main computing work; or, server 140, the first terminal 120, and the second terminal 160 collaborate on computing using a distributed computing architecture.

[0086] Optionally, server 140 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, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0087] The second terminal 160 has an application installed and running that supports virtual scenes. Optionally, the application includes any one of the following: an FPS game, a third-person shooter game, a MOBA game, a virtual reality application, a 3D map application, or a multiplayer survival game. In some embodiments, the second terminal 160 is a terminal used by a second user. When the second terminal 160 runs the application, the user interface of the application is displayed on the screen of the second terminal 160. Based on the second user's initial actions in the user interface, a virtual scene is loaded and displayed in the application. The second user uses the second terminal 160 to operate a second virtual object located in the virtual scene to perform activities, including but not limited to: adjusting body posture, crawling, walking, running, riding, jumping, driving, picking up, shooting, attacking, throwing, and fighting. Illustratively, the second virtual object is a second virtual character, such as a realistic or anime character.

[0088] Optionally, the first virtual object controlled by the first terminal 120 and the second virtual object controlled by the second terminal 160 are in the same virtual scene, at which time the first virtual object can interact with the second virtual object in the virtual scene.

[0089] Schematic illustration: The first and second virtual objects are in an adversarial relationship. For example, the first and second virtual objects belong to different factions. Adversarial virtual objects can interact in a combat manner on land, such as throwing projectiles at each other. In other embodiments, the first and second virtual objects are teammates. For example, the first and second virtual characters belong to the same faction, the same team, have a friend relationship, or have temporary communication permissions.

[0090] Optionally, the applications installed on the first terminal 120 and the second terminal 160 are the same, or the applications installed on the two terminals are the same type of applications on different operating system platforms. The first terminal 120 and the second terminal 160 both refer to one of a plurality of terminals, and this embodiment of the application only uses the first terminal 120 and the second terminal 160 as examples.

[0091] The first terminal 120 and the second terminal 160 may have the same or different device types. These device types include, but are not limited to, at least one of the following: smartphones, tablets, smart speakers, smartwatches, handheld smart devices, portable gaming devices, in-vehicle terminals, laptops, and desktop computers. For example, both the first terminal 120 and the second terminal 160 may be smartphones or other handheld portable gaming devices. The following embodiments use smartphones as an example.

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

[0093] The following describes the terminology used in the embodiments of this application.

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

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

[0096] Unreal Engine provides pathfinding functionality (also known as navigation) for game AI bots. Pathfinding is a fundamental component of game AI, and its basic goal is to generate a path that an individual can reach, given a starting point and a destination point. Common pathfinding methods include: path nodes, navigation meshes (NavMesh), and potential fields. This application's embodiment relates to pathfinding based on NavMesh.

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

[0098] NavMesh: A data structure that fills the walkable space on the game map.

[0099] Poly: A convex polygon, which is the building block of the NavMesh navigation mesh, and is also known as the basic pathfinding unit of the RecastNavigation system.

[0100] A* pathfinding algorithm: It is an efficient search algorithm for static locations, which finds the shortest path between two points in a plane.

[0101] Breadth-First Search (BFS): also known as width-first search, is a classic algorithm in graph theory.

[0102] Strongly Connected Components (SCCs): A concept in graph theory. For any two vertices vi and vj in a graph, if there exists a directed path from vi to vj, and also a directed path from vj to vj, then the SCCs are strongly connected components. j to v i If there is a directed path between two vertices v, then the two vertices v are said to be v. i and v j Strongly connected. Furthermore, if every two vertices of a directed graph G are strongly connected, then G is called a strongly connected graph. For a directed graph that is not strongly connected, the maximal strongly connected subgraph is called a strongly connected component.

[0103] Weakly connected graph: The graph obtained by replacing all directed edges of a directed graph with undirected edges is called the base graph of the original graph. If the base graph of a directed graph is a connected graph, then the directed graph is a weakly connected graph.

[0104] Environment Query System (EQS): A technology within Unreal Engine 4, provided to game AI bots to collect and analyze current game environment data to find the most suitable results. For example, at the start of a game, game AI, such as virtual monsters, automatically spawn at random locations (called monster spawning or monster deployment). Once a player-controlled virtual object enters the monster's search area, the monster will pursue it. EQS's role is to provide the virtual monster with a suitable target point to move towards.

[0105] In game development, it is often necessary to place virtual resources or virtual objects in certain locations within a virtual scene. Virtual resources include virtual treasure chests, virtual resources, virtual props, and virtual items, while virtual objects include AI (Artificial Intelligence), NPCs (Non-Player Characters), and game bots such as monsters.

[0106] In the process of deploying the aforementioned virtual resources or virtual objects, traditional physical detection and manual placement methods can achieve certain results for some simple virtual scenes with small scale and relatively simple virtual object movement methods. Physical detection refers to detecting whether a virtual object will hit the ground or a mountain when it is deployed into the virtual scene, thereby determining whether to deploy it to the current location. Manual placement refers to manually setting up multiple candidate points in the virtual scene and randomly selecting some candidate points from these preset candidate points to deploy virtual resources or refresh virtual objects.

[0107] However, when it comes to more complex virtual object movement methods such as climbing, ziplining, and flying, physical detection methods cannot provide better accuracy. In addition, for some virtual scenes with huge areas and intricate terrain, manual placement of points would result in huge manpower costs. Furthermore, regardless of whether manual placement or physical detection is used, virtual resources are often placed in locations that players cannot reach (such as high platforms or gaps), or virtual objects spawn in locations that players cannot reach (such as high platforms or gaps), resulting in various situations where players cannot interact with them. Therefore, the high manpower costs and poor accuracy seriously affect the player's gaming experience.

[0108] In view of this, this application combines relevant concepts of graph theory with the BFS algorithm and the Tarjan SCC algorithm to propose a post-processing method for NavMesh navigation meshes, i.e., a scene data processing method. This method can divide the regions on the NavMesh navigation mesh according to reachability, and can determine the first target region that is unidirectionally reachable and the second target region that is bidirectionally reachable from the virtual scene. After having the region data (i.e., region parameters) for each Poly mesh divided according to reachability, it is easy to identify the virtual objects controlled by the player or the game robot that cannot reach from the virtual scene. This allows for the reasonable planning of the placement of virtual resources and the reasonable planning of the game robot's walking path, which can greatly improve the player's gaming experience.

[0109] The following is a brief overview of the overall process of the scene data processing method according to the embodiments of this application.

[0110] Figure 2 This is a flowchart illustrating a method for processing scene data according to an embodiment of this application. See also... Figure 2 This embodiment is executed by a computer device, and is illustrated using a computer device as a server as an example. This embodiment includes:

[0111] 201. The server obtains scene navigation data of the virtual scene, which is used to indicate the space in the virtual scene where virtual objects can move.

[0112] A server is a computer device used to provide backend services to applications that support virtual scenarios, including at least one of a single server, multiple servers, a cloud computing platform, or a virtualization center. This application uses a game server as an example for illustration.

[0113] The virtual scene involved in this application refers to the virtual environment provided by the application when it runs on the terminal, including a simulation environment of the real world, a semi-simulated and semi-fictional virtual environment, or a purely fictional virtual environment. Furthermore, the virtual scene can be a two-dimensional virtual scene, a 2.5-dimensional virtual scene, or a three-dimensional virtual scene, etc., and this application does not specifically limit this. Indicatively, the virtual scene includes environmental elements such as sky, land, hills, cliffs, canyons, oceans, rivers, lakes, cities, and deserts. Virtual objects controlled by the player and virtual objects controlled by machine-provided behavioral logic (which can be preset logic or an AI behavioral model) can all move within the virtual scene.

[0114] The virtual objects involved in this application refer to movable objects that have their own shape and volume and occupy a portion of space in a virtual scene. Optionally, virtual objects include player characters controlled by players through client operations, NPCs set up by the server in the virtual scene, neutral virtual objects (such as virtual monsters or wild monsters) deployed by the server into the virtual environment, or game robots (such as companion AI robots) deployed by the server into the virtual scene. This application does not specifically limit the type of virtual objects. Schematic, when the virtual scene is a three-dimensional virtual scene, the virtual object is a three-dimensional model, which is a three-dimensional character constructed based on three-dimensional human skeleton technology.

[0115] The scene navigation data involved in this application refers to the data obtained by analyzing and processing the virtual scene based on the game engine, which is used for navigation or pathfinding within the scene. Taking the game engine as UE engine or Unity engine as an example, the game engine can analyze the completed virtual scene to obtain NavMesh navigation mesh data. This NavMesh navigation network data is the scene navigation data involved in this application. It should be noted that scene navigation data may have different names or data structures in different game engines, and this application does not specifically limit this.

[0116] In some embodiments, the server analyzes and processes the original scene data of the virtual scene in the game engine for any virtual scene supported by the game application to obtain the scene navigation data of the virtual scene.

[0117] To illustrate, taking the UE engine or Unity engine as an example, the engine can mark and bake paths for virtual objects (such as environment, buildings, obstacles, props, etc.) in each virtual scene, generating mesh data for the virtual scene. Then, using the RecastNavigation navigation and pathfinding toolset provided by the engine or the NavMesh navigation and pathfinding system based on RecastNavigation, the mesh data of the virtual scene is processed as follows: a) Voxelization, which constructs a solid height field from the source geometry of the marked virtual objects in the virtual scene (such as the geometric model of mountains, cliffs, etc.) to represent the unwalkable space in the virtual scene. Usually, some unwalkable surfaces are removed at this stage (such as surfaces with too large a slope). A voxel is a point with size in space; b) Region Generation, which merges continuous intervals on the upper surface of the solid height field into regions. The goal of this stage is to further define which parts of the source geometry surface are walkable and to divide these walkable parts into continuous regions; c) Contour Generation. (d) Generation: This involves detecting the contours of the region and constructing simple polygons. For example, generating very fine polygons from the region and then simplifying these fine polygons to obtain simple polygons. These simple polygons represent walkable surfaces. This is the first step in converting from voxel space back to vector space. (e) Convex Polygon Generation: This involves dividing the simple polygons formed by the contours into convex polygon meshes (Poly). Each Poly represents a walkable surface. (f) Height Detail Generation: This involves triangulating the convex polygon meshes (Poly) to obtain height details. For example, the Delaunay triangulation algorithm can be used to triangulate the Poly to add vertices inside or at the edges of the Poly, ensuring that the mesh is equivalent to the source geometry surface, thereby increasing the height detail information. After the above processing (a) to (e) is completed, the Mesh data obtained from baking the virtual scene is further analyzed to obtain NavMesh navigation mesh data composed of a series of convex polygon meshes (Poly). This NavMesh navigation mesh data is the scene navigation data involved in step 201 above.

[0118] 202. Based on the scene navigation data, the server determines the first target area in the virtual scene. The first target area is used to indicate the one-way connected area that the virtual object in the virtual scene can reach.

[0119] The first target region is used to indicate a unidirectional connected region that can be reached by the virtual scene. Optionally, the first target region is a maximal weakly connected subgraph of the virtual scene, or the first target region is the union of multiple weakly connected subgraphs of the virtual scene. This application embodiment does not specifically limit this.

[0120] In some embodiments, since the scene navigation data is composed of multiple grids, each grid is considered a node in a graph. Therefore, based on whether a virtual object can move from one grid A to another grid B, it can be determined whether there exists a directed edge between the node corresponding to grid A and the node corresponding to grid B in the graph data. On this basis, the scene navigation data composed of various grids is equivalent to a directed graph, and each grid is equivalent to a vertex in the directed graph. In this case, the process of determining the first target region based on the scene navigation data is equivalent to ignoring the connection direction of each directed edge in the directed graph corresponding to the scene navigation data, that is, replacing all directed edges in the directed graph with undirected edges, thus obtaining the base graph of the directed graph. Next, each vertex (i.e., each grid) in the base graph of the directed graph is traversed. For each unvisited vertex, a breadth-first search algorithm is used to find all vertices reachable from that vertex. This vertex and all the found vertices constitute a weakly connected subgraph in the base graph of the directed graph. The above operation is repeated until each vertex has been visited, at which point the traversal stops. Then, all weakly connected subgraphs in the base graph of the directed graph can be obtained. The first target region can be selected from these weakly connected subgraphs. Optionally, the weakly connected subgraph containing the most vertices is selected as the first target region, or the N (N≥1) weakly connected subgraphs containing the most vertices are selected as the first target region. This embodiment does not specifically limit the selection logic of the first target region.

[0121] Schematic illustration: The scene navigation data is NavMesh navigation mesh data, which is composed of multiple convex polygon meshes (Poly). During traversal, the first unvisited Poly is found first. Then, using a breadth-first search algorithm, all Polys directly or indirectly connected to this Poly are found. At this point, a set of Polys containing this Poly and all the found Polys is obtained. This set of Polys represents a weakly connected subgraph. After traversing each Poly in the NavMesh navigation mesh data, multiple Poly sets are obtained. One or more Poly sets can be selected from these multiple Poly sets, and the region formed by these one or more Poly sets is determined as the first target region. For example, only the region formed by the Poly set containing the largest number of Polys is determined as the first target region.

[0122] 203. The server determines a second target area from the first target area, the second target area being used to indicate a bidirectionally connected area in the virtual scene that the virtual object can reach and return to.

[0123] In some embodiments, since the first target region determined in step 202 ignores the connection direction of the directed edges in the directed graph, it is equivalent to the first target region only excluding isolated regions (i.e., completely unconnected grids) that are inaccessible to virtual objects in the virtual scene. However, the first target region still has the problem of one-way connectivity, that is, when a virtual object is active in the first target region, it may reach a certain grid and then be unable to return to the original grid. Therefore, it is necessary to determine a second target region from the first target region to ensure that each grid in the second target region can return to the original grid.

[0124] In some embodiments, since the first target region is itself a weakly connected subgraph of the virtual scene, it means that, regardless of direction, each grid in the first target region must be directly or indirectly connected to any other grid in the first target region. Therefore, the Tarjan SCC algorithm can be used to process the first target region (i.e., the selected weakly connected subgraph) to find at least one strongly connected subgraph contained in the first target region. The Tarjan SCC algorithm is based on a depth-first search algorithm. In this embodiment, the Tarjan SCC algorithm can be modified to be based on a breadth-first search algorithm. Each strongly connected subgraph in the first target region corresponds to a subtree in the search tree. During the search, unprocessed nodes in the current search tree are added to a stack (Push unprocessed nodes onto the stack). Backtracking starts from the top node of the stack. During backtracking, it is determined whether the nodes from the top of the stack to the middle of the stack form a strongly connected subgraph. If the condition for a strongly connected subgraph is met, a strongly connected subgraph is determined. Then, the top node of the stack is popped, and backtracking continues for the new node at the top of the stack. The criteria for determining strongly connected subgraphs will be described in detail in the next embodiment, and will not be repeated here.

[0125] After obtaining all strongly connected subgraphs of the first target region, a second target region can be selected from these strongly connected subgraphs. For example, the strongly connected subgraph with the most vertices can be selected as the second target region, or the M (M≥1) strongly connected subgraphs with the most vertices can be selected as the second target region. The embodiments of this application do not specifically limit the selection logic of the second target region.

[0126] Schematic, after determining the set of Poly corresponding to the first target region from the NavMesh navigation mesh data, the Tarjan SCC algorithm is used to find all strongly connected subgraphs of the Poly set, where each strongly connected subgraph can be represented by a Poly subset. Then, one or more Poly subsets are selected from all Poly subsets, and the region formed by these one or more Poly subsets is determined as the second target region. For example, only the region formed by the Poly subset containing the largest number of Polys is determined as the second target region.

[0127] It should be noted that steps 201-203 above are equivalent to a post-processing procedure for scene navigation data. The result of this post-processing is the delineation of the second target region in the virtual scene, which is equivalent to identifying a maximal strongly connected subgraph (i.e., strongly connected components) within the virtual scene. Furthermore, the server can use this second target region to guide the deployment of virtual resources, the refreshing of virtual objects, and the path planning (or navigation / pathfinding) of virtual objects within the virtual scene. The second target region can be considered the main region of the NavMesh navigation mesh data. Typically, most activities of player-controlled virtual objects and machine-controlled game robots reside in the main region. Therefore, simply saving the relevant data for the second target region can improve the processing accuracy of subsequent services that require access to scene navigation data. For example, the server can control the deployment of virtual resources or game robots only to the second target region, avoiding deployment to areas inaccessible to player-controlled virtual objects. Similarly, when planning the path for game robots, minimizing their movement within the second target region ensures effective interaction between the game robot and player-controlled virtual objects.

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

[0129] The method provided in this application post-processes the scene navigation data of the virtual scene. First, it divides the virtual scene into a first target area that virtual objects can reach, roughly eliminating some isolated areas that virtual objects cannot walk in at all. Then, it divides the first target area into a second target area that virtual objects can reach and return to, finely eliminating some areas that virtual objects cannot return to after moving there. This ensures that the second target area obtained after post-processing has high accessibility. The second target area guides various downstream business needs in the deployment of virtual resources, the refreshing of virtual objects, and the path planning of virtual objects in the virtual scene. It can prevent virtual resources or virtual objects from appearing in areas that players cannot reach, and it eliminates the need for manual placement, saving manpower costs for scene data processing and improving the accuracy of data processing.

[0130] In the previous embodiment, the processing flow for scene data was briefly introduced. In this embodiment, the first target area and the second target area will be divided in detail. The following is an explanation.

[0131] Figure 3 This is a flowchart of a scene data processing method provided in an embodiment of this application, such as... Figure 3 As shown, this embodiment is executed by a computer device. Taking the computer device as a server as an example, this embodiment includes:

[0132] 301. The server obtains scene navigation data of the virtual scene, which is used to indicate the space in the virtual scene where virtual objects can move.

[0133] Step 301 above is similar to step 201 above, and will not be described in detail here.

[0134] 302. Based on the scene navigation data, the server determines multiple first candidate regions in the virtual scene. Each first candidate region is a unidirectional connected region that the virtual object can reach from the corresponding root node.

[0135] In some embodiments, since the scene navigation data is composed of multiple grids, each grid is regarded as a node in a graph data. Then, based on whether the virtual object can move from one grid A to another grid B, it can be determined whether there is a directed edge between the node corresponding to grid A and the node corresponding to grid B in the graph data. On this basis, the scene navigation data composed of each grid is equivalent to a directed graph, and each grid is equivalent to a vertex in the directed graph.

[0136] Based on the above, for any unvisited grid in the scene navigation data, taking that grid as the root node, a breadth-first search algorithm can be used to determine all the grids that can be reached from that root node. The area formed by that grid and the determined grids is defined as a first candidate region. This first candidate region is equivalent to an active space composed of all grids that can be reached from the root node. The above operation is repeated until there are no unvisited grids in the scene navigation data, which means that all grids in the scene navigation data have been traversed. At this time, multiple first candidate regions can be obtained.

[0137] In some embodiments, for the directed graph corresponding to the scene navigation data, the connection direction of each directed edge in the directed graph is ignored, that is, all directed edges in the directed graph are replaced with undirected edges, so that the base graph of the directed graph can be obtained. Next, each grid (i.e., each vertex) in the base graph of the directed graph is traversed. Each unvisited grid is taken as the root node, and a breadth-first search algorithm is used to find all grids reachable from the root node. In other words, all vertices in the base graph of the directed graph that can be directly or indirectly connected to the root node are found. The set of vertices, including the root node, represents a weakly connected subgraph in the base graph of the directed graph, and also represents a unidirectional connected region reachable from the root node in any virtual scene of any virtual object, i.e., a first candidate region. Then, the above operation is repeated with the next unvisited grid as the root node until there are no unvisited grids in the base graph of the directed graph. This means that all grids in the scene navigation data and all vertices in the base graph of the directed graph have been traversed. At this point, multiple first candidate regions corresponding to multiple root nodes can be obtained. These first candidate regions are also used to calculate all weakly connected subgraphs in the base graph of the directed graph.

[0138] Schematic, the scene navigation data is NavMesh navigation mesh data, which is composed of multiple convex polygon meshes (Poly). In the preprocessing stage, an index is created to uniquely identify each Poly. For example, each Poly is uniquely identified by an integer, called its index, denoted as PolyRef. Then, since each Poly has a unique corresponding mesh coordinate and index PolyRef in the virtual scene, a hash table (called the total index of all PolyRefs in the virtual scene) can be constructed for all Polys in the NavMesh navigation mesh data. Each Poly in the hash table is represented using a key-value pair structure, where the key is the index PolyRef of the corresponding Poly, and the value is the mesh coordinate of the corresponding Poly in the virtual scene. By constructing the hash table, the subsequent operations of determining the first and second target regions can be transformed into intersection, union, and complement operations on the sets formed by some key-value pairs in the hash table. This optimizes the speed of obtaining the first and second target regions, improving the processing efficiency of the scene data. For example, using the Xorshift64 random number generation algorithm to generate a corresponding index PolyRef for each Poly reduces the numerical regularity of the index PolyRef. Using the Xorshift64 algorithm can improve the overall performance by 2.54 times.

[0139] Next, during the traversal process used to find the first candidate region, each Key-Value structure in the hash table constructed based on the NavMesh navigation mesh data is accessed, which is equivalent to accessing the Poly corresponding to each Key-Value structure. The first unvisited Poly is found as the root node. According to the breadth-first search algorithm, all Polys that can be directly or indirectly connected to the root node are traversed from the root node, resulting in a Poly set composed of the root node and all Polys found that are directly or indirectly connected to the root node. This Poly set represents a weakly connected subgraph in the base graph of the directed graph. Then, the next unvisited Poly is found as the root node, and the above operation is repeated until there are no unvisited Key-Value structures in the hash table. This means that all Polys in the NavMesh navigation mesh data have been traversed, and all vertices in the base graph of the directed graph have been traversed. At this point, multiple Poly sets are obtained. Each Poly set represents a weakly connected subgraph in the base graph of the directed graph, and the unidirectional connected region formed by each Poly in the virtual scene is also a first candidate region.

[0140] It should be noted that in this traversal, the directed graph was transformed into the base graph of the directed graph, that is, the connection direction of all directed edges in the directed graph was ignored. Therefore, even if the virtual object can move from the grid Poly A in the virtual scene to the grid Poly B by jumping, moving, walking, etc., it cannot return from Poly B to Poly A (for example, it cannot return after jumping down the hill). However, since the connection direction is ignored, Poly A and Poly B will also be regarded as connected to each other in the undirected graph and added to the same Poly set.

[0141] 303. The server selects a first target region from the multiple first candidate regions. The first target region is used to indicate a unidirectional connected region that the virtual object in the virtual scene can reach.

[0142] In some embodiments, when the server selects a first target region from each first candidate region, it may determine the first candidate region with the largest number of grids contained in the plurality of first candidate regions as the first target region.

[0143] Schematic, the above process is equivalent to taking the weakly connected subgraph with the most vertices in all weakly connected subgraphs of the virtual scene as the first target region. For example, after dividing all the Polys of the NavMesh navigation mesh data into multiple Poly sets according to connectivity, the region formed by the Poly set with the largest number of Polys is determined as the first target region.

[0144] In some embodiments, when the server selects the first target region from each first candidate region, it can also sort each first candidate region in descending order of the number of grids contained therein, and take the region indicated by the union of the N first candidate regions that are ranked in the top N (N≥1) positions as the first target region. In other words, take the region indicated by the union of the N first candidate regions that contain the most vertices as the first target region.

[0145] Schematic, the above process is equivalent to taking the union of the N weakly connected subgraphs with the most vertices in all weakly connected subgraphs of the virtual scene as the first target region. For example, after dividing all the Polys of the NavMesh navigation mesh data into multiple Poly sets according to connectivity, the Poly sets are sorted in descending order of the number of Polys contained, and the region indicated by the union of the top N Poly sets is taken as the first target region.

[0146] In steps 302-303 above, a possible implementation method is provided for the server to determine the first target region in the virtual scene based on the scene navigation data. That is, all grids in the scene navigation data are divided into multiple first candidate regions according to connectivity, i.e., accessibility. Then, the first target region is obtained by roughly filtering from the multiple first candidate regions. This allows the second target region to be determined by fine filtering only for each grid in the first target region, while all grids outside the first target region are excluded and do not participate in the subsequent calculation of the second target region. This can save the amount of computation to obtain the second target region and improve the computational efficiency.

[0147] In steps 302-303 above, by obtaining the first target region, some completely disconnected Polys can be roughly excluded from all Polys in the NavMesh navigation mesh data. These excluded Polys can be regarded as some isolated Polys in the virtual scene. When determining the second target region in the future, it is only necessary to process the one-way connectivity problem of the remaining Polys in the first target region to achieve fine filtering of Polys that the virtual object can reach and return to.

[0148] 304. The server determines multiple second candidate regions from the first target region. Each second candidate region is a bidirectionally connected region that the virtual object can reach and return from the corresponding root node.

[0149] In some embodiments, for all Polys contained in the first target region determined in step 303 above, a key-value structure for each Poly can be created in the manner described in step 302 above, using the index PolyRef of each Poly as the key and the grid coordinates of the corresponding Poly in the virtual scene as the value. Thus, all key-value structures corresponding to all Polys contained in the first target region can form a new hash table, and the Polys indicated by all key-value structures in the hash table must be interconnected without considering direction (therefore, these Polys belong to the same weakly connected subgraph).

[0150] In some embodiments, the server constructs a search tree based on the first target region, where each node in the search tree corresponds to a grid in the first target region. For example, for the hash table constructed based on the first target region, a search tree of the Tarjan SCC algorithm is constructed, where each node in the search tree represents a Poly corresponding to a Key-Value structure in the hash table.

[0151] Next, starting from the first unvisited root node Poly in the search tree, a search is performed using either a depth-first search algorithm or a breadth-first search algorithm to find the last Poly in the current subtree. The root node Poly and all the Polys found in the current subtree (i.e., the unprocessed nodes) are pushed onto a stack. Backtracking begins from the Poly at the top of the stack. During backtracking, it is determined whether the Poly at the top of the stack satisfies the condition for a strongly connected subgraph. If the condition is met, it means that the Polys from the top of the stack to the Polys in the stack form a strongly connected subgraph (forming a second candidate region). Then, the Poly at the top of the stack is popped from the stack. The new Poly at the top of the stack after being popped is then checked to see if it satisfies the condition, and so on. Optionally, if the Poly at the top of the stack does not meet the condition, it is necessary to check whether the Poly at the top of the stack can find the next connected Poly (i.e., the extended node). If there is an extended node Poly and it has never been pushed onto the stack (i.e., it has not been visited), then the extended node Poly is pushed onto the stack. Since the stack structure has the Last-In-First-Out (LIFO) property, the newly pushed extended node Poly will be stored at the top of the stack, becoming the new Poly at the top of the stack. This allows us to determine whether the new Poly at the top of the stack (i.e., the extended node Poly) meets the condition. Alternatively, if the searched extended node Poly is already in the stack, then the trace value of the Poly after the extended node Poly in the stack needs to be updated. Based on the updated trace value, we can then determine whether the condition is met again. This process continues until all Polys in the search tree have been pushed onto the stack once and popped from the stack once. At this point, the traversal stops, and all strongly connected subgraphs in the first target region, i.e., all second candidate regions, can be obtained.

[0152] Optionally, the determination condition for the strongly connected subgraph mentioned above is as follows: if the timestamp DFN[i] and the traceback value LOW[i] of the node (Poly)i at the top of the stack in the search tree are equal, that is, if DFN[i] = LOW[i] exists for Poly i at the top of the stack, it means that Poly i and its subtrees in the search tree can form a strongly connected subgraph. Then, the region formed by each node Poly in the search subtree rooted at Poly i is determined as a second candidate region. Here, the timestamp of Polyi refers to the number of times Poly i is searched in the search tree, and the traceback value of Poly i refers to the order of the earliest stack node Poly that Poly i or its subtree can trace back to.

[0153] After performing the Tarjan SCC algorithm to traverse all Polys in the search tree, it can find all strongly connected subgraphs contained in the first target region. Each strongly connected subgraph represents a second candidate region in the first target region.

[0154] 305. The server selects a second target region from the multiple second candidate regions. The second target region is used to indicate a bidirectionally connected region in the virtual scene that the virtual object can reach and return to.

[0155] In some embodiments, when the server selects a second target region from the various second candidate regions, it can determine the second candidate region with the largest number of grids contained in the plurality of second candidate regions as the second target region.

[0156] Schematic, the above process is equivalent to taking the strongly connected subgraph with the most vertices in all strongly connected subgraphs of the virtual scene as the second target region. For example, after dividing the set of Polys contained in the first target region into multiple strongly connected subgraphs, i.e. second candidate regions, based on the Tarjan SCC algorithm, all Polys contained in each second candidate region form a Poly subset of the Poly set. At this time, the region formed by the Poly subset containing the largest number of Polys is determined as the second target region.

[0157] In some embodiments, when the server selects the second target region from each second candidate region, it can also sort each second candidate region in descending order of the number of grids contained therein, and take the region indicated by the union of the M second candidate regions that are ranked in the first M (M≥1) positions as the second target region. In other words, take the region indicated by the union of the M second candidate regions that contain the most vertices as the second target region.

[0158] Schematic, the above process is equivalent to taking the union of the M strongly connected subgraphs with the most vertices in all strongly connected subgraphs of the virtual scene as the second target region. For example, after dividing the set of Polys containing all Polys in the first target region into multiple strongly connected subgraphs, i.e., second candidate regions, based on the Tarjan SCC algorithm, it is equivalent to determining the Poly subsets corresponding to each of the multiple second candidate regions. Then, according to the order of the number of Polys contained, each Poly subset is sorted in descending order, and the region indicated by the union of the M Poly subsets ranked in the top M positions is taken as the second target region.

[0159] In steps 304-305 above, a possible implementation of the server determining the second target area from the first target area is provided. Since each grid in the second target area is an active space that the virtual object can reach and return to, the bidirectional connected area formed by these active spaces, i.e., the second target area, can be regarded as the main area where the virtual object is active in most cases in the virtual scene. The server can save relevant data that can indicate the second target area, and can guide the deployment of virtual resources, the refresh of virtual objects, and the path planning (or navigation, pathfinding) of virtual objects in the virtual scene based on the second target area.

[0160] In some embodiments, the server determines the region parameter of each grid in the scene navigation data based on the region to which the grid belongs. The region parameter is used to indicate the accessibility of the virtual object's corresponding grid activity in the virtual scene. The region parameter of each grid can indicate whether the grid belongs to the first target region and whether it belongs to the second target region. By combining the region parameters of all grids, it is possible to determine which grids are included in the first target region and which grids are included in the second target region.

[0161] In some embodiments, for each grid in the scene navigation data, if the grid is located outside the first target area, the server determines the region parameter of the grid to a first value. In other words, the server configures the region parameter of each grid located outside the first target area to a first value. For example, when the region parameter is an integer, the first value is 0 or a negative number. When the region parameter of a grid is accessed and is 0 or a negative number, it means that the grid is located outside the first target area. For another example, when the region parameter is a string, the first value is "Isolated". When the region parameter of a grid is accessed and is "Isolated", it means that the grid is located outside the first target area.

[0162] In some embodiments, for each grid in the scene navigation data, if the grid is located within the first target region, the server determines the grid's region parameter to a second value. This second value corresponds to a higher accessibility than the first value. In other words, the server configures the region parameter of each grid within the first target region to the second value, and defines the second value as having higher accessibility than the first value. Accessibility here refers to a connectivity metric in graph theory; higher accessibility means higher connectivity of the corresponding grid within the entire virtual scene (directed graph), and lower accessibility means lower connectivity of the corresponding grid within the entire virtual scene (directed graph). For example, when the region parameter is an integer, the second value is positive. When the region parameter of a grid is positive, it means that the grid is located within the first target region. Similarly, when the region parameter is a string, the second value is "non-isolated." When the region parameter of a grid is "non-isolated," it means that the grid is located within the first target region.

[0163] To illustrate, when the grid is located in the first target region, the region parameter of the grid is assigned different values ​​based on whether the grid is located in the second target region. For example, when the region parameter is an integer, the region parameter of each grid located outside the first target region is configured to 0 or a negative number, the region parameter of each grid located within the first target region but outside the second target region is configured to 1, and the region parameter of each grid located within the second target region is configured to 2. This ensures that the region parameter of the grid increases with the connectivity of the grid. Of course, it is not necessary to ensure that the region parameter of the grid is positively correlated with the connectivity. It is also possible to make the region parameter of the grid negatively correlated with the connectivity, or the two uncorrelated, as long as the region parameter can be used to distinguish whether the current grid belongs to the first target region or the second target region.

[0164] In some embodiments, the server sorts the multiple second candidate regions included in the first target region obtained in step 304 according to the number of grids they contain, from largest to smallest. Then, since all grids in the first target region are traversed when dividing the second candidate regions, and each grid is pushed onto and popped from the stack only once, meaning that each grid in the first target region has a unique second candidate region, it is only necessary to determine the region parameter of each grid as the index of the second candidate region to which that grid belongs in the sorting to identify whether each grid belongs to the second target region. For example, if the second target region refers to the second candidate region with the largest number of grids, it means that the second target region must be at the first position in the sorting of the multiple second candidate regions. Therefore, it is only necessary to find all grids with a region parameter value of 1; the region determined by these grids in the virtual scene is the second target region.

[0165] In the above method, a region parameter is configured for each grid to indicate which grids are included in the first target region and which grids are included in the second target region. Only the region parameter of each grid Poly needs to be saved to the NavMesh data, which can be used for subsequent virtual resource deployment, virtual object refresh and virtual object path planning (or navigation, pathfinding) and other services. This method has low storage overhead.

[0166] In other embodiments, the server may also maintain a hash table for each grid in the first target area, and similarly maintain another hash table for each grid in the second target area, so that the two hash tables can be used for subsequent services such as virtual resource deployment, virtual object refresh, and virtual object path planning (or navigation, wayfinding), and the storage overhead is also relatively low.

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

[0168] The method provided in this application post-processes the scene navigation data of the virtual scene. First, it divides the virtual scene into a first target area that virtual objects can reach, roughly eliminating some isolated areas that virtual objects cannot walk in at all. Then, it divides the first target area into a second target area that virtual objects can reach and return to, finely eliminating some areas that virtual objects cannot return to after moving there. This ensures that the second target area obtained after post-processing has high accessibility. The second target area guides various downstream business needs in the deployment of virtual resources, the refreshing of virtual objects, and the path planning of virtual objects in the virtual scene. It can prevent virtual resources or virtual objects from appearing in areas that players cannot reach, and it eliminates the need for manual placement, saving manpower costs for scene data processing and improving the accuracy of data processing.

[0169] The previous embodiment detailed the scene data processing method involved in this application embodiment. In engines such as UE or Unity, this can be regarded as a post-processing method for NavMesh navigation mesh data. In the traditional RecastNavigation navigation scheme, the virtual scene (i.e., game map, scene map) is sampled based on the space that can accommodate the virtual object's movement, thereby generating NavMesh navigation mesh data. However, no post-processing is performed on the NavMesh navigation mesh data. This results in the following: in any area that can accommodate the virtual object's movement (or standing), regardless of whether the virtual object can reach it (e.g., mountain tops, crevices, or the interior of enclosed spaces such as mountains), the data is processed. NavMesh navigation mesh data is generated inside objects such as sealed containers. Therefore, if unprocessed NavMesh navigation mesh data is directly used in subsequent tasks such as deploying virtual resources, refreshing virtual objects, or planning virtual object paths, the connectivity between areas may be lost. This is because NavMesh navigation mesh data doesn't consider the connectivity between areas, potentially resulting in some independent, inaccessible areas. If virtual resources are deployed or refreshed in areas inaccessible to the player, effective and sufficient game interaction and human-computer interaction will be impossible. Another consideration is that in some games, virtual resources like virtual treasure chests randomly drop near defeated (or eliminated, out of the game, or resurrected) virtual objects. However, due to the high randomness of the location where virtual objects are defeated, without sufficient consideration of terrain information, the deployment point of a virtual treasure chest might be stuck between two object models or in terrain gaps, preventing the player from picking it up.

[0170] After using the scene data processing method provided in the above embodiments, since a second target area in the virtual scene can be determined, the second target area ensures that the virtual object is both reachable and returnable. Therefore, when applied to the task of placing virtual resources or virtual objects, it is only necessary to control the placement point to always be within the second target area. For example, by quickly selecting points randomly from the grids contained in the second target area, the virtual resources can be prevented from falling into areas inaccessible to the player, thereby improving the accuracy of resource placement and optimizing the user experience. When applied to the path planning task of virtual objects, since the destination is often unreachable during navigation (such as hitting a wall, encountering obstacles, or being unable to climb at the foot of a mountain), in the traditional RecastNavigation navigation scheme, if the path is found to an unreachable point, it will cause the A* search algorithm to degenerate, resulting in unnecessary performance overhead. However, the embodiments of this application can predefine a second target area that is guaranteed to be reachable, thereby eliminating most unreachable grids in advance and avoiding the performance overhead caused by the degeneration of the A* search algorithm due to the path being found to an unreachable grid.

[0171] In summary, the post-processing method for NavMesh navigation mesh data described above effectively eliminates unreachable meshes in the virtual scene when defining the first target area, roughly excluding some completely disconnected and isolated areas. When defining the second target area, it effectively eliminates unreturnable meshes in the virtual scene, precisely excluding areas where one cannot return once entered (such as areas where one cannot return after jumping down a hill). This significantly improves processing performance and accuracy, greatly enhancing the gaming experience, whether controlling the deployment of virtual resources or virtual objects, handling path planning for virtual objects, or solving scene query problems related to virtual objects (i.e., selecting only meshes within the second target area when AI-controlled virtual objects move randomly to achieve efficient querying of reachable meshes).

[0172] In this embodiment, taking game engines that support the RecastNavigation library, such as UE or Unity, as an example, we will introduce a post-processing method for NavMesh navigation mesh data. This post-processing method is applicable to various complex terrain FPS games, third-person shooter games, MOBA games, virtual reality applications, 3D map programs, multiplayer survival games, etc. Combined with the game engine's EQS and other means, it enables game robots (referring to virtual objects not controlled by the player, usually controlled by AI behavior models) to know in advance which places in the virtual scene are inaccessible and which places, once jumped down, can never be climbed back up. This makes the game robot show higher intelligence in path planning and movement performance. It can also efficiently and automatically randomly place some virtual resources or game robots to places that the player-controlled virtual objects can definitely reach, which can solve the problem of placing tricky and unreachable locations in completely random situations, bringing a better player experience.

[0173] Figure 4 This is a flowchart illustrating a post-processing method for NavMesh navigation mesh data provided in an embodiment of this application, as shown below. Figure 4 As shown, this embodiment is executed by an electronic device. Taking the electronic device as a server as an example, this embodiment includes the following steps:

[0174] 401. The server collects information about all Polys in the NavMesh navigation mesh data and builds a hash table.

[0175] The NavMesh navigation mesh data is an exemplary illustration of the scene navigation data of the virtual scene in the above embodiments.

[0176] Optionally, the NavMesh navigation mesh data is traversed to find the index PolyRef of all Poly, and a total index of all PolyRefs in the virtual scene (i.e., the entire map) is built into a hash table using the game engine. The process of building the hash table is described in step 302 of the above embodiment, and will not be repeated here.

[0177] Figure 5 This is a schematic diagram of raw NavMesh data provided in an embodiment of this application, such as... Figure 5 As shown, in the NavMesh scheme, the virtual scene 500 is divided into a series of convex polygon meshes. The dark area 501 represents the unwalkable space inside the mountain, while the light areas 502 and 503 represent spaces where virtual objects can walk. However, although the interior of the mountain can accommodate virtual objects, they cannot pass through it. Therefore, the light area 502 is clearly a walkable but actually inaccessible area.

[0178] Since the built-in hash table implementation in the UE is relatively simple, it can be optimized for performance with small datasets. Alternatively, the Xorshift64 algorithm can be used to process PolyRef to reduce the regularity of its values, which can improve overall performance by 2.54 times.

[0179] 402. Does the server check if there is a next unvisited Poly in the hash table? If there is a next unvisited Poly, proceed to step 403; if there is no next unvisited Poly, proceed to step 404.

[0180] Optionally, all Polys in the hash table created in step 401 are traversed to find the first unvisited Poly and proceed to step 403. If no unvisited Poly is found, proceed to step 404.

[0181] 403. Without considering direction, the server starts from the found unvisited Poly, visits all reachable Polys based on the BFS algorithm, obtains a weakly connected component, and returns to step 402.

[0182] The weakly connected component is the weakly connected subgraph, which is also the first candidate region involved in the above embodiments.

[0183] Optionally, the direction of the Poly connection is ignored in this traversal. In other words, even if it is possible to jump from Poly A to Poly B, but it is impossible to return from Poly B to Poly A, Poly A and Poly B are still considered to be connected for traversal. Using the first unvisited Poly found in step 402 above as the root node, all Polys directly or indirectly connected to the root node are traversed from the root node. When the BFS algorithm stops searching, a weakly connected component consisting of the root node and all Polys searched by the BFS algorithm can be obtained.

[0184] Repeat steps 402-403 until all Polys in the hash table have been accessed. At this point, there must be no unaccessed Polys in the hash table. Proceed to step 404.

[0185] 404. The server sorts the weakly connected components in descending order of the number of polys they contain.

[0186] Since all Polys in the NavMesh navigation mesh data have been partitioned into multiple Poly sets that can be reached from the root node, only the Poly set containing the most Polys (i.e., the maximal weakly connected subgraph) is retained among all Poly sets. Every Poly in all other Poly sets is excluded and does not participate in subsequent post-processing calculations.

[0187] 405. The server marks all Polys except the largest weakly connected component as isolated.

[0188] The largest weakly connected component is also the first target region involved in the above embodiments.

[0189] After steps 402-404, completely disconnected Polys have been roughly eliminated. These Polys will be marked as isolated, that is, the region parameter of these Polys will be configured to a first value, which is used to indicate that these Polys are located outside the first target region.

[0190] Figure 6 This is a schematic diagram of NavMesh data after removing unreachable areas, provided in an embodiment of this application. Figure 5 Based on the original NavMesh data shown, unreachable light-colored regions 502 are identified through steps 402-404 above. Each Poly within a light-colored region 502 is marked as isolated, and these isolated Polys are excluded from subsequent post-processing calculations. For example... Figure 5 As shown, in order to visually represent the unreachable light-colored areas 502 formed by these isolated Polys, the light-colored areas 502 are modified into dark-colored areas, representing that although this area can accommodate virtual objects to walk on, the virtual objects cannot actually reach it.

[0191] 406. The server uses all unmarked orphaned Polys to build a new hash table.

[0192] Next, we need to address the one-way connectivity problem for all Polys in the first target region that are not marked as isolated. At this point, we can use the PolyRefs of the remaining Polys to build another hash table in a similar manner to step 401. We can see that all Polys in this hash table are definitely connected to each other without considering the direction.

[0193] 407. Does the server check if there is a next unvisited Poly in the hash table? If there is a next unvisited Poly, proceed to step 408; if there is no next unvisited Poly, proceed to step 409.

[0194] Optionally, all Polys in the hash table created in step 406 are traversed to find the first unvisited Poly and proceed to step 408. If no unvisited Poly is found, proceed to step 409.

[0195] 408. Taking direction into account, the server runs the Tarjan SCC algorithm to obtain a strongly connected component and returns to step 407.

[0196] Among them, the strongly connected component is the strongly connected subgraph, which is also the second candidate region involved in the above embodiments.

[0197] Repeat steps 407-408 until all Polys in the hash table have been visited. At this point, there will definitely be no unvisited Polys in the hash table, which means that the Tarjan SCC algorithm has been run on all Polys in the hash table. At this point, several strongly connected components can be obtained, and then proceed to step 409.

[0198] 409. The server sorts each strongly connected component in descending order of the number of Polys it contains.

[0199] The strongly connected components output by the Tarjan SCC algorithm after multiple iterations are sorted in descending order of the number of Polys they contain. This ensures that the strongly connected component ranked first has the most Polys, and this strongly connected component ranked first can be used as the final second target region in the above embodiment.

[0200] 410. The server marks each Poly with the ordinal number of its strongly connected component in the sorting.

[0201] In other words, the Polys in each strongly connected component are numbered starting from 1, in descending order. For example, all Polys in the first strongly connected component are marked as 1, all Polys in the second strongly connected component are marked as 2, and so on, until all Polys in the hash table that are not marked as orphans have been marked.

[0202] As we can see, since the strongly connected component ranked first contains the most Polys, the number of Polys marked as 1 is the largest. Therefore, the region formed by all Polys marked as 1 is called the second target region, which is the main region of the NavMesh navigation mesh data. Most of the activities of the virtual objects controlled by the player and the game robots controlled by the AI ​​behavior model are located in the main region.

[0203] Figure 7 This is a schematic diagram of a Poly marked as 1 in NavMesh data provided in an embodiment of this application. Figure 6Based on the NavMesh data after removing inaccessible areas, steps 407-409 further identify reachable and returnable (specifically, in mountainous environments, meaning both climbable and jumpable) strongly connected components (SCCs). Each Poly in the maximal strongly connected component (i.e., the strongly connected component containing the most Polys, referring to the second target region) is marked as 1. It can be seen that... Figure 7 The five indices shown are Poly 701 to 705, namely 1F3:0, 1A3:0, 1E9:0, 220:0, and 243:0. Their zone parameter is marked as 1, that is, Poly 701 to 705 are all marked with zone:1, which means that these five Polys are areas that can be jumped down from the mountain or climbed up from the foot of the mountain.

[0204] Figure 8 This is a schematic diagram of Polys marked with a value greater than 1 in NavMesh data provided in an embodiment of this application. Based on the NavMesh data after removing unreachable regions, reachable and returnable strongly connected components (SCCs) are further identified through steps 407-409 above. Each Poly in the maximal strongly connected component is marked as 1, and each Poly in the remaining strongly connected components is marked with the corresponding strongly connected component's sequence number in the sorting, such as... Figure 8 As shown, two Poly 801 and 802 with indices D1AA:0 and D33D:0 respectively are shown in a cliff environment. Their zone parameter is marked as 1382, which means that Poly 801 and 802 belong to the strongly connected component located at the 1382nd position in the sorting. This means that although the virtual object can move and walk between Poly 801 and 802, once the virtual object falls from the outer Poly to Poly 801 or 802, it cannot climb back to the original outer Poly from the fallen Poly. That is, these Polys with a mark greater than 1 do not belong to the same strongly connected component as the main region (i.e., the second target region, the region composed of Polys marked as 1).

[0205] 411. After completion, the server saves the data for each Poly tag.

[0206] The server stores the tag data assigned to each Poly for subsequent queries by other business processes.

[0207] The post-processing method for scene navigation data involved in the embodiments of this application only takes about 8 seconds to process a map (i.e., a virtual scene) of size 2km*2km. Please refer to the code results below for the running time of each step. Moreover, the calculation process is performed offline. The server only needs to save the relevant data of the second target area that has been calculated or the connectivity information of the entire virtual scene.

[0208] CollectPolys – 272.273ms – Total 0.27s / 1 / 272.273ms / / Collect Poly

[0209] Surf – 536.767ms – Total 0.54s / 1 / 536.767ms / / Find weakly connected components in a single traversal

[0210] MarkAsNull – 25.430ms – Total 0.03s / 1 / 25.430ms / / Except for the maximal weakly connected component,

[0211] All are marked as isolated, i.e., null.

[0212] NumPolys 590750, NumComponents 11088, NumUnreachable 112650 / / Calculate the number of Polys contained in each region.

[0213] RecollectPolys – 179.370ms – Total 0.18s / 1 / 179.370ms / / Collect unlabeled PolyFindSCC – 941.055ms – Total 0.94s / 1 / 941.055ms / / Secondary traversal to find strongly connected components

[0214] MarkReachabilityZone – 6161.103ms – Total 6.16s / 1 / 6161.103ms / / Marks reachable and returnable Polys, as well as reachable and non-returnable Polys.

[0215] NumRecollected 478100, NumSCC 16491, NumZone1 439890 / / Calculate the number of Polys contained in each region

[0216] Total – 8124.662ms – Total 8.12s / 1 / 8124.662ms / / Total runtime

[0217] In this embodiment, each Poly in the original NavMesh data is marked so that when the Poly's zone parameter value is different, it can indicate whether the region to which the Poly belongs is reachable and whether it can be returned. For example, when the Poly's zone parameter is isolated (e.g., 0 or negative numbers are defined as isolated, or Null is defined as isolated), the Poly belongs to an unreachable region; when the Poly's zone parameter is 1, the Poly belongs to the main region, i.e., the second target region (reachable and returnable); when the Poly's zone parameter is greater than 1, the Poly belongs to the region within the first target region but outside the second target region (reachable but not returnable). In this way, it is equivalent to obtaining the connectivity data of the virtual scene. When using the connectivity data, it is only necessary to access the zone parameter of the specified Poly in the connectivity data, or compare the size of the zone parameters of different Polys, to quickly provide connectivity-related query results.

[0218] Indicatively, during the random movement judgment of the game robot, when randomly moving to select a destination, the zone parameters of the starting point Poly and the ending point Poly are obtained. If the zone parameter of the ending point Poly is 1, or the zone parameters of the starting point Poly and the ending point Poly are equal, then the movement selection is considered valid.

[0219] To illustrate, when controlling the deployment of virtual resources or virtual objects, always controlling the deployment of virtual resources or virtual objects to the main area (i.e., randomly selecting points only from Polys with a zone parameter value of 1) can ensure that the deployed Polys are always located in the main area reachable by the virtual objects controlled by the player, thereby improving game performance and optimizing user experience.

[0220] In the above embodiments, different embodiments of the scene data processing method have been described. In this application embodiment, a method for deploying virtual resources based on already processed scene data is provided, such as... Figure 9 As shown, Figure 9 This is a flowchart illustrating a method for deploying virtual resources according to an embodiment of this application. This embodiment is executed by a computer device, and is described using a server as an example. The embodiment includes the following steps:

[0221] 901. In response to a request to deploy virtual resources, the server obtains scene navigation data of the virtual scene, which is used to indicate the space in the virtual scene where virtual objects can move.

[0222] In some embodiments, the server obtains a virtual resource delivery request. This delivery request may be initiated by a terminal or automatically generated by the server when delivery conditions are met. It should be noted that in a server cluster architecture, the server that generates the delivery request and the server that processes the delivery request may not be the same physical machine. For example, a game server generates the delivery request and a navigation server processes the delivery request. This application embodiment does not specifically limit the source of the delivery request.

[0223] In some embodiments, in response to the deployment request, the server parses the deployment request to obtain the scene identifier (ID) of the virtual scene to be deployed by the virtual resource, and then queries the scene navigation data stored corresponding to the scene ID, for example, queries the NavMesh navigation mesh data stored corresponding to the scene ID.

[0224] 902. The server obtains the second target area determined based on the scene navigation data. The second target area is used to indicate the bidirectional connected area that the virtual object in the virtual scene can reach and return to.

[0225] In some embodiments, the server can determine a second target area for the virtual scene based on the scene data processing methods involved in the above embodiments. At this time, the server will save the relevant data of the second target area. Then, it is only necessary to access the relevant data of the second target area to obtain the second target area in the virtual scene.

[0226] For example, the relevant data for the second target region refers to the region parameters configured for each grid in the scene navigation data. For instance, accessing the region parameter "zone" for each Poly in the NavMesh navigation grid data, schematically, the region formed by all Polys with a zone value of 1 is determined as the second target region. This region parameter is used to indicate the accessibility of the corresponding Poly activity of the virtual object in the virtual scene.

[0227] For example, the relevant data for the second target region refers to a hash table containing the indexes of all grids in the second target region. For instance, by accessing the hash table corresponding to the second target region, the indexes PolyRef of all Polys in the second target region can be found. The region formed by the Polys corresponding to these PolyRefs is the second target region.

[0228] 903. The server deploys the virtual resource to the target location in the second target area within the virtual scene.

[0229] In some embodiments, the server randomly determines a grid from the second target area as the target location and controls the delivery of virtual resources to the target location. The virtual resources include virtual treasure chests, virtual materials, virtual items, virtual props, etc. This application embodiment does not specifically limit the resource type of the virtual resources.

[0230] For example, the server may randomly select a deployment Poly for the virtual resource from among the Polys with a region parameter of 1, or the server may randomly select a deployment Poly for the virtual resource from the hash table of the second target region.

[0231] In this embodiment, the post-processed NavMesh data is used to process the deployment request of virtual resources in the virtual scene. In response to the deployment request, the virtual resource can be deployed to the second target area in the virtual scene, ensuring that the target location of the virtual resource is located in the main area that the player-controlled virtual object can reach and return to, which greatly improves the deployment accuracy of virtual resources and optimizes the user experience.

[0232] The above embodiments detail how to use post-processed scene navigation data to control the precise delivery of virtual resources into the virtual scene. It should be noted that replacing the virtual resources in the above embodiments with virtual objects controlled by AI behavior models can also achieve precise delivery of virtual objects (i.e., game robots). This delivery process is also called the birth or refresh process of virtual objects, which will not be elaborated here.

[0233] In this embodiment of the application, a method for path planning of virtual objects based on post-processed scene navigation data is also provided, such as... Figure 10 As shown, Figure 10 This is a flowchart illustrating a path planning method for virtual objects according to an embodiment of this application. This embodiment is executed by a computer device, and is described using a server as an example. The embodiment includes the following steps:

[0234] 1001. In response to a path planning request for a virtual object in a virtual scene, the server determines the starting and ending grids of the path planning request.

[0235] In some embodiments, the server obtains a path planning request for a virtual object. This path planning request may be a request initiated by the terminal, or it may be a request automatically generated by the server when path planning conditions are met (such as the random movement of a game robot). It should be noted that in a server cluster architecture, the server that generates the path planning request and the server that processes the path planning request may not be the same physical machine. For example, the game server generates the path planning request, and the navigation server processes the path planning request. This application embodiment does not specifically limit the source of the path planning request.

[0236] In some embodiments, the server responds to the path planning request by parsing the request to obtain the starting grid and ending grid for this path planning. Optionally, in a scenario involving the legality judgment of random movement of the game robot, the path planning request may only carry the starting grid, i.e., the starting Poly, and then the server randomly selects an ending grid, i.e., the ending Poly, connected to the starting grid.

[0237] 1002. The server determines a second target area in the virtual scene, which is used to indicate a bidirectionally connected area in the virtual scene that the virtual object can reach and return to.

[0238] Step 1002 above is similar to step 902 above, and will not be described in detail here.

[0239] 1003. When the starting grid and the ending grid are located in the same bidirectional connected region, or when the ending grid is located in the second target region, the server determines that the movement of the virtual object from the starting grid to the ending grid is legal.

[0240] In some embodiments, the server first determines whether the destination grid is located within the second target area. If the destination grid is located within the second target area, the movement is directly determined to be legal. If the destination grid is outside the second target area, the server further determines whether the virtual object between the starting grid and the destination grid is reachable and returnable. If the virtual object is reachable and returnable, it indicates that the starting grid and the destination grid are located in the same bidirectional connected area, and the movement is determined to be legal. If the virtual object is unreachable, or reachable but not returnable, it indicates that the movement between the starting grid and the destination grid is illegal.

[0241] To illustrate, the system queries the zone parameters of the starting point Poly and the ending point Poly. If the zone parameter of the ending point Poly is 1, it determines that the ending point Poly is located in the second target region and returns a valid move. If the zone parameter of the ending point Poly is not 1, it checks whether the zone parameters of the starting point Poly and the ending point Poly are equal. If they are equal, it determines that the starting point Poly and the ending point Poly are located in the same bidirectional connected region and returns a valid move. If they are not equal, it returns a invalid move.

[0242] In this embodiment, for the case of pathfinding between two unreachable Polys, traditional pathfinding schemes would use the A* search algorithm until an unfeasible path is found after exhausting the number of iterations, at which point the algorithm would return that the path is unreachable. However, in this embodiment, it is only necessary to determine whether the zone parameters of the starting Poly and the ending Poly are equal to efficiently and quickly determine whether the two Polys are bidirectionally connected. Therefore, the zone parameters of all Polys are also called the connectivity information or connectivity data of the entire virtual object. In this case, there is no need to use the A* search algorithm, which reduces the number of invalid traversals of the A* search algorithm for two unreachable Polys.

[0243] Furthermore, when selecting and moving points in the game engine EQS, it is also necessary to determine whether the path from the starting point Poly to the ending point Poly is reachable. In traditional EQS solutions, an A* search algorithm is required, and a large number of Polys are prepared to filter for reachability, resulting in very low point selection efficiency. However, the embodiment of this application only needs to read the zone parameters of the starting point Poly and the ending point Poly to immediately determine whether it is possible to reach the ending point Poly from the starting point Poly, without having to execute the original A* search algorithm. The overall performance is improved by 4.97 times in a single game, which is applicable to a wide range of EQS query tasks and optimizes the business performance of EQS.

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

[0245] The acquisition module 1101 is used to acquire scene navigation data of the virtual scene, which is used to indicate the space in the virtual scene where virtual objects can move.

[0246] The first determining module 1102 is used to determine a first target area in the virtual scene based on the scene navigation data. The first target area is used to indicate a one-way connected area that the virtual object in the virtual scene can reach.

[0247] The second determining module 1103 is used to determine a second target region from the first target region, the second target region being used to indicate a bidirectionally connected region in the virtual scene that the virtual object can reach and return to.

[0248] The apparatus provided in this application post-processes the scene navigation data of a virtual scene. First, it divides the virtual scene into a first target area that virtual objects can reach, roughly eliminating isolated areas that virtual objects cannot traverse. Then, it divides the first target area into a second target area that virtual objects can reach and return to, finely eliminating areas that virtual objects cannot return to after moving there. This ensures that the second target area obtained after post-processing has high accessibility. The second target area guides various downstream business needs in the deployment of virtual resources, the refreshing of virtual objects, and the path planning of virtual objects in the virtual scene. It can prevent virtual resources or virtual objects from appearing in areas that players cannot reach, and it eliminates the need for manual placement, saving manpower costs for scene data processing and improving the accuracy of data processing.

[0249] In one possible implementation, based on Figure 11 The device comprises, wherein the first determining module 1102 includes:

[0250] The first determining unit is used to determine multiple first candidate regions in the virtual scene based on the scene navigation data, where each first candidate region is a unidirectional connected region that the virtual object can reach from the corresponding root node.

[0251] The first filtering unit is used to filter the first target region from the plurality of first candidate regions.

[0252] In one possible implementation, the first determining unit is used to:

[0253] For any unvisited grid in the scene navigation data, take that grid as the root node, determine all the grids that can be reached from that root node, and define the area formed by that grid and the determined grids as a first candidate area.

[0254] In one possible implementation, the first screening unit is used for:

[0255] The first candidate region with the largest number of grid cells among the multiple first candidate regions is determined as the first target region.

[0256] In one possible implementation, based on Figure 11 The device comprises, wherein the second determining module 1103 includes:

[0257] The second determining unit is used to determine a plurality of second candidate regions from the first target region, each second candidate region being a bidirectionally connected region that the virtual object can reach and return from the corresponding root node;

[0258] The second filtering unit is used to filter the second target region from the plurality of second candidate regions.

[0259] In one possible implementation, the second determining unit is used to:

[0260] Based on the first target region, a search tree is constructed, where each node in the search tree corresponds to a grid in the first target region;

[0261] Push all unprocessed nodes in the search tree onto the stack. For the node at the top of the stack, if the timestamp and the trace value of the node are equal, determine the region formed by the nodes in the search subtree rooted at that node as a second candidate region.

[0262] In one possible implementation, the second screening unit is used for:

[0263] The second candidate region with the largest number of grid cells among the multiple second candidate regions is determined as the second target region.

[0264] In one possible implementation, based on Figure 11 The device comprises:

[0265] The third determining module is used to determine the region parameter of each grid in the scene navigation data based on the region to which the grid belongs. The region parameter is used to indicate the accessibility of the virtual object's corresponding grid activity in the virtual scene.

[0266] In one possible implementation, based on Figure 11 The device comprises, wherein the third determining module includes:

[0267] The third determining unit is used to determine the region parameter of the grid as a first value when the grid is located outside the first target region;

[0268] The third determining unit is further configured to determine the region parameter of the grid as a second value when the grid is located in the first target region, wherein the accessibility corresponding to the second value of the region parameter is greater than the accessibility corresponding to the first value.

[0269] In one possible implementation, the third determining unit is further configured to:

[0270] The multiple second candidate regions contained in the first target region are sorted in descending order of the number of grids contained. Each second candidate region is a bidirectionally connected region that the virtual object can reach and return from the corresponding root node.

[0271] For each grid in the first target region, the region parameter of that grid is determined as the index of the second candidate region to which that grid belongs in the sorting.

[0272] In one possible implementation, based on Figure 11 The device comprises:

[0273] The delivery module is used to respond to a delivery request for virtual resources in the virtual scene and deliver the virtual resources to the second target area in the virtual scene.

[0274] In one possible implementation, based on Figure 11 The device comprises:

[0275] The fourth determination module is used to determine the starting grid and ending grid of the path planning request in response to the path planning request of the virtual object in the virtual scene.

[0276] The fifth determination module is used to determine the legality of the virtual object's movement from the starting grid to the ending grid when the starting grid and the ending grid are located in the same bidirectional connected region, or when the ending grid is located in the second target region.

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

[0278] It should be noted that the scene data processing device provided in the above embodiments is only illustrated by the division of the above functional modules when processing scene navigation data of virtual scenes. In actual 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 data processing device and the scene data processing method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the scene data processing method embodiments, which will not be repeated here.

[0279] Figure 12 This is a schematic diagram of the structure of a virtual resource delivery device according to an embodiment of this application, as shown below. Figure 12 As shown, the device includes:

[0280] The acquisition module 1201 is used to acquire scene navigation data of the virtual scene in response to the virtual resource deployment request. The scene navigation data is used to indicate the space in the virtual scene where virtual objects can move.

[0281] The acquisition module 1201 is also used to acquire a second target area determined based on the scene navigation data. The second target area is used to indicate a bidirectional connected area in the virtual scene that the virtual object can reach and return to.

[0282] The delivery module 1202 is used to deliver the virtual resource to the target location in the second target area of ​​the virtual scene.

[0283] The device provided in this application embodiment uses post-processed scene navigation data to process the delivery request of virtual resources in the virtual scene. In response to the delivery request, the virtual resource is delivered to the second target area in the virtual scene, ensuring that the target location of the virtual resource is located in the main area that the player-controlled virtual object can reach and return to, which greatly improves the delivery accuracy of virtual resources and optimizes the user experience.

[0284] It should be noted that the virtual resource deployment device provided in the above embodiments is only illustrated by the division of the above functional modules when deploying virtual resources into a virtual scene. In actual 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 virtual resource deployment device and the virtual resource deployment method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the virtual resource deployment method embodiments, which will not be repeated here.

[0285] Figure 13 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application, such as... Figure 13 As shown, terminal 1300 is used as an example of a computer device for explanation. Optionally, the device type of terminal 1300 includes: smartphones, tablets, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 players (Moving Picture Experts Group Audio Layer IV), laptops, or desktop computers. Terminal 1300 may also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or other names.

[0286] Typically, terminal 1300 includes a processor 1301 and a memory 1302.

[0287] Optionally, the processor 1301 includes one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Optionally, the processor 1301 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 1301 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 1301 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 1301 also includes an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0288] In some embodiments, the memory 1302 includes one or more computer-readable storage media, optionally non-transitory. Optionally, the memory 1302 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 1302 is used to store at least one program code, which is executed by the processor 1301 to implement the scene data processing method or the virtual resource deployment method provided in the various embodiments of this application.

[0289] In some embodiments, the terminal 1300 may also optionally include a peripheral device interface 1303 and at least one peripheral device. The processor 1301, memory 1302, and peripheral device interface 1303 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 1303 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: a radio frequency circuit 1304, a display screen 1305, a camera assembly 1306, an audio circuit 1307, and a power supply 1308.

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

[0291] The radio frequency (RF) circuit 1304 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 1304 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 1304 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 1304 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 1304 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 1304 also includes circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0292] Display screen 1305 is used to display a UI (User Interface). Optionally, the UI includes graphics, text, icons, videos, and any combination thereof. When display screen 1305 is a touch display screen, display screen 1305 also has the ability to collect touch signals on or above the surface of display screen 1305. The touch signals can be input to processor 1301 for processing as control signals. Optionally, display screen 1305 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 1305, which is set on the front panel of terminal 1300; in other embodiments, there are at least two display screens 1305, which are respectively set on different surfaces of terminal 1300 or have a folded design; in still other embodiments, display screen 1305 is a flexible display screen, which is set on the curved surface or folded surface of terminal 1300. Furthermore, optionally, display screen 1305 is set as a non-rectangular irregular shape, that is, an irregularly shaped screen. Optionally, the display screen 1305 is made of materials such as LCD (Liquid Crystal Display) or OLED (Organic Light-Emitting Diode).

[0293] The camera assembly 1306 is used to acquire images or videos. Optionally, the camera assembly 1306 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 1306 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.

[0294] In some embodiments, the audio circuit 1307 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 1301 for processing, or input to the radio frequency circuit 1304 to realize voice communication. For stereo acquisition or noise reduction purposes, multiple microphones are used, each located at a different part of the terminal 1300. Optionally, the microphone is an array microphone or an omnidirectional acquisition microphone. The speaker is used to convert electrical signals from the processor 1301 or the radio frequency circuit 1304 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 convert electrical signals not only into sound waves that humans can hear, but also into sound waves that humans cannot hear for purposes such as distance measurement. In some embodiments, the audio circuit 1307 also includes a headphone jack.

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

[0296] In some embodiments, the terminal 1300 further includes one or more sensors 1310. The one or more sensors 1310 include, but are not limited to: an acceleration sensor 1311, a gyroscope sensor 1312, a pressure sensor 1313, an optical sensor 1314, and a proximity sensor 1315.

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

[0298] In some embodiments, the gyroscope sensor 1312 detects the orientation and rotation angle of the terminal 1300. The gyroscope sensor 1312 and the accelerometer sensor 1311 work together to acquire the user's 3D movements on the terminal 1300. Based on the data acquired by the gyroscope sensor 1312, the processor 1301 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.

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

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

[0301] The proximity sensor 1315, also known as a distance sensor, is typically located on the front panel of the terminal 1300. The proximity sensor 1315 is used to detect the distance between the user and the front of the terminal 1300. In one embodiment, when the proximity sensor 1315 detects that the distance between the user and the front of the terminal 1300 is gradually decreasing, the processor 1301 controls the display screen 1305 to switch from a screen-on state to a screen-off state; when the proximity sensor 1315 detects that the distance between the user and the front of the terminal 1300 is gradually increasing, the processor 1301 controls the display screen 1305 to switch from a screen-off state to a screen-on state.

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

[0303] Figure 14This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device 1400 can vary significantly due to differences in configuration or performance. The computer device 1400 includes one or more Central Processing Units (CPUs) 1401 and one or more memories 1402. The memories 1402 store at least one computer program, which is loaded and executed by the one or more processors 1401 to implement the scene data processing method or virtual resource deployment method provided in the various embodiments above. Optionally, the computer device 1400 also has wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The computer device 1400 also includes other components for implementing device functions, which will not be elaborated here.

[0304] In an exemplary embodiment, 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 terminal to complete the scene data processing method or the virtual resource deployment method 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.

[0305] In an exemplary embodiment, a computer program product or computer program is also provided, including one or more lines of program code stored in a computer-readable storage medium. One or more processors of a computer device are capable of reading the one or more lines of program code from the computer-readable storage medium, and the one or more processors execute the one or more lines of program code, enabling the computer device to perform the scene data processing method or the virtual resource deployment method described in the above embodiments.

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

[0307] 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 processing scene data, characterized in that, The method includes: Acquire scene navigation data of a virtual scene, wherein the scene navigation data is used to indicate the space in the virtual scene where virtual objects can move; Based on the scene navigation data, multiple first candidate regions in the virtual scene are determined, each first candidate region being a unidirectional connected region that the virtual object can reach from the corresponding root node; from the multiple first candidate regions, a first target region is obtained, the first target region being used to indicate a unidirectional connected region that the virtual object can reach in the virtual scene; Multiple second candidate regions are determined from the first target region. Each second candidate region is a bidirectionally connected region that the virtual object can reach and return from from its corresponding root node. From the multiple second candidate regions, a second target region is selected. The second target region is used to indicate a bidirectionally connected region that the virtual object in the virtual scene can reach and return from. In response to a request to deploy virtual resources in the virtual scene, the virtual resources are deployed to the second target area in the virtual scene.

2. The method according to claim 1, characterized in that, The step of determining multiple first candidate regions in the virtual scene based on the scene navigation data includes: For any unvisited grid in the scene navigation data, take the grid as the root node, determine all grids that can be reached from the root node, and define the area formed by the grid and the determined grids as a first candidate area.

3. The method according to claim 1, characterized in that, The step of filtering the plurality of first candidate regions to obtain the first target region includes: The first candidate region with the largest number of grid cells among the plurality of first candidate regions is determined as the first target region.

4. The method according to claim 1, characterized in that, Determining a plurality of second candidate regions from the first target region includes: Based on the first target region, a search tree is constructed, wherein each node in the search tree corresponds to a grid in the first target region; Push each unprocessed node in the search tree onto the stack. For the node at the top of the stack, when the timestamp and trace value of the node are equal, determine the region formed by each node in the search subtree rooted at the node as a second candidate region.

5. The method according to claim 1, characterized in that, The step of filtering the plurality of second candidate regions to obtain the second target region includes: The second candidate region with the largest number of grid cells among the plurality of second candidate regions is determined as the second target region.

6. The method according to claim 1, characterized in that, The method further includes: For each grid in the scene navigation data, a region parameter is determined based on the region to which the grid belongs. The region parameter is used to indicate the accessibility of the virtual object's corresponding grid activity in the virtual scene.

7. The method according to claim 6, characterized in that, The process of determining the region parameters of the grid based on the region to which the grid belongs includes: If the grid is located outside the first target area, the area parameter of the grid is determined to be a first value; When the grid is located in the first target region, the region parameter of the grid is determined to be a second value, wherein the accessibility corresponding to the second value is greater than the accessibility corresponding to the first value.

8. The method according to claim 7, characterized in that, The step of determining the region parameter of the grid as a second value when the grid is located in the first target region includes: The multiple second candidate regions contained in the first target region are sorted in descending order of the number of grids contained therein. Each second candidate region is a bidirectionally connected region that the virtual object can reach and return from the corresponding root node. For each grid in the first target region, the region parameter of the grid is determined as the sequence number of the second candidate region to which the grid belongs in the sorting.

9. The method according to claim 1, characterized in that, The method further includes: In response to a path planning request for a virtual object in the virtual scene, the starting grid and ending grid of the path planning request are determined; When the starting grid and the ending grid are located in the same bidirectional connected region, or when the ending grid is located in the second target region, the movement of the virtual object from the starting grid to the ending grid is determined to be legal.

10. A method for delivering virtual resources, characterized in that, The method includes: In response to a request to deploy virtual resources, scene navigation data of the virtual scene is obtained, wherein the scene navigation data is used to indicate the space in the virtual scene where virtual objects can move. A second target region is obtained based on the scene navigation data. The second target region is used to indicate a bidirectionally connected region that the virtual object in the virtual scene can reach and return to. The second target region is obtained by filtering multiple second candidate regions. Each second candidate region is a bidirectionally connected region that the virtual object can reach and return to from the corresponding root node. The multiple second candidate regions are determined from a first target region. The first target region is used to indicate a unidirectionally connected region that the virtual object in the virtual scene can reach. The first target region is obtained by filtering multiple first candidate regions in the virtual scene. Each first candidate region is a unidirectionally connected region that the virtual object can reach from the corresponding root node, as determined based on the scene navigation data. The virtual resource is deployed to the target location in the second target area within the virtual scene.

11. A scene data processing device, characterized in that, The device includes: The acquisition module is used to acquire scene navigation data of the virtual scene, wherein the scene navigation data is used to indicate the space in the virtual scene where virtual objects can move. The first determining module is used to determine multiple first candidate regions in the virtual scene based on the scene navigation data, each first candidate region being a unidirectional connected region that the virtual object can reach from the corresponding root node; and to filter out a first target region from the multiple first candidate regions, the first target region being used to indicate a unidirectional connected region that the virtual object can reach in the virtual scene. The second determining module is used to determine a plurality of second candidate regions from the first target region, each second candidate region being a bidirectionally connected region that the virtual object can reach and return from its corresponding root node; and to filter a second target region from the plurality of second candidate regions, the second target region being used to indicate a bidirectionally connected region that the virtual object in the virtual scene can reach and return from. The delivery module is used to respond to a delivery request for virtual resources in the virtual scene and deliver the virtual resources to the second target area in the virtual scene.

12. A device for distributing virtual resources, characterized in that, The device includes: The acquisition module is used to acquire scene navigation data of the virtual scene in response to the virtual resource delivery request. The scene navigation data is used to indicate the space in the virtual scene where virtual objects can move. The acquisition module is further configured to acquire a second target region determined based on the scene navigation data. The second target region is used to indicate a bidirectionally connected region in the virtual scene that the virtual object can reach and return to. The second target region is obtained by filtering from multiple second candidate regions. Each second candidate region is a bidirectionally connected region that the virtual object can reach and return to from the corresponding root node. The multiple second candidate regions are determined from a first target region. The first target region is used to indicate a unidirectionally connected region in the virtual scene that the virtual object can reach. The first target region is obtained by filtering from multiple first candidate regions in the virtual scene. Each first candidate region is a unidirectionally connected region that the virtual object can reach from the corresponding root node, as determined based on the scene navigation data. The delivery module is used to deliver the virtual resources to the target location in the second target area within the virtual scene.

13. 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 data processing method as described in any one of claims 1 to 9 or the virtual resource delivery method as described in claim 10.

14. A storage medium, characterized in that, The storage medium stores at least one computer program, which is loaded and executed by a processor to implement the scene data processing method as described in any one of claims 1 to 9 or the virtual resource delivery method as described in claim 10.

15. 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 data processing method as described in any one of claims 1 to 9 or the virtual resource delivery method as described in claim 10.

Images