Method and device for generating warfare fog, medium and product

Abstract

The embodiment of the invention relates to the technical field of information, and discloses a warfare fog generation method and device, a medium and a product. The method is applied to a graphics processor, and comprises the following steps of: determining a static object and a dynamic object according to an updating frequency of an object in a game running process; determining a first rendering texture and / or a second rendering texture according to the static object and the dynamic object; the first rendering texture is used for representing the state of an area covered by the visual field of a static object, and the second rendering texture is used for representing the state of an area covered by the visual field of the static object and / or a dynamic object; and generating warfare fog according to the first rendering texture and / or the second rendering texture. The method can be at least used for solving the technical problems that the computing load is high when the CPU generates the warfare fog and many low-end devices do not support or support the characteristic in a limited manner in the process of generating the warfare fog mask through the computing core of the GPU.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a method, device, medium and product for generating fog of war. Background Technology

[0002] Fog of War is a game mechanic used to hide areas that players have not yet explored or cannot currently observe. It is commonly used in simulation games, such as strategy war games, as well as role-playing games.

[0003] There are two common methods for creating fog of war: one is to calculate the visibility range of each unit in the CPU and synthesize a fog map; the other is to generate the fog map using the GPU's computing cores.

[0004] However, the inventors have discovered at least the following technical problems in the related technology: 1. When generating fog of war based on CPU, the CPU's computing load is high in complex scenes, which can cause frame drops or frame drops when displayed on mobile devices; 2. In the process of generating fog of war mask through the computing core of GPU, many low-end devices do not support or only support this feature, resulting in poor compatibility. Summary of the Invention

[0005] One objective of this application is to provide a solution that addresses the problems of high computational load when generating fog of war using CPUs and the fact that many low-end devices do not support or have limited support for the fog of war masking generated via GPU computing cores.

[0006] To achieve the above objectives, some embodiments of this application provide the following aspects:

[0007] In a first aspect, some embodiments of this application provide a method for generating fog of war, the method being applied to a graphics processor, the method comprising: determining static objects and dynamic objects based on the update frequency of objects during game operation; determining a first rendering texture and / or a second rendering texture based on the static objects and the dynamic objects; the first rendering texture being used to characterize the state of an area covered by the view of a static object, and the second rendering texture being used to characterize the state of an area covered by the view of a static object and / or a dynamic object; and generating fog of war based on the first rendering texture and / or the second rendering texture.

[0008] Secondly, some embodiments of this application also provide an electronic device, the electronic device comprising: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method described above.

[0009] Thirdly, some embodiments of this application also provide a computer-readable medium having computer program instructions stored thereon, which can be executed by a processor to implement the method described above.

[0010] Fourthly, some embodiments of this application also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method described above.

[0011] Compared with related technologies, the solution provided in this application, which generates fog of war based on the GPU, can reduce the CPU burden and leverage the advantages of GPU parallel computing for accelerated computation. Static and dynamic objects are determined based on their update frequency during game execution. This eliminates the need for frame-by-frame updates after identifying different objects, further reducing CPU pressure. Then, following a classification approach, a first rendering texture and / or a second rendering texture are determined based on the static and dynamic objects. The first rendering texture represents the state of the area covered by the static object's view, and the second rendering texture represents the state of the area covered by the static and / or dynamic object's view. This process does not rely on Compute Shader; it only requires creating and managing Render Textures in the GPU. This improves adaptability to low-end devices to a certain extent and allows for compatibility with multiple platforms such as mobile, PC, and consoles, as well as different rendering interfaces (APIs), offering better scalability and broader device compatibility. Finally, fog of war is generated based on the first and / or second rendering textures, flexibly accommodating both static and dynamic objects. Thus, by providing a GPU-based fog of war generation method, we can avoid overloading the CPU and relying on interface applets. When facing complex game graphics processing scenarios, the processing speed is faster, and it is less prone to frame drops or stuttering on the monitor. It is also compatible with both high-end and low-end devices. Attached Figure Description

[0012] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0013] Figure 1 An exemplary flowchart of a fog of war generation method provided for some embodiments of this application;

[0014] Figure 2 An exemplary flowchart for generating fog of war based on a first rendered texture and / or a second rendered texture is provided for some embodiments of this application;

[0015] Figure 3 This is an exemplary structural diagram of an electronic device provided for some embodiments of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0017] The following terms are used in this document.

[0018] CPU, Central Processing Unit, is the core of a computer's operation and control system, manufactured using very large-scale integrated circuits.

[0019] GPU, Graphics Processing Unit, is used to handle graphics rendering-related tasks and has highly parallel computing capabilities.

[0020] Fog of War is a game mechanic used to hide areas that players have not yet explored or are not currently able to observe.

[0021] SLG, Simulation Game, refers to simulation games such as strategy war games.

[0022] RPG, Role-Playing Game.

[0023] OpenGL / OpenGL ES, or Open Graphics Library, is a cross-language, cross-platform application programming interface (API) for rendering 2D and 3D vector graphics. It consists of nearly 350 different function calls used to draw complex 3D scenes from simple graphics bits.

[0024] Compute Shader is a type of shader program in OpenGL (and OpenGL ES) used to perform general-purpose computing tasks on a GPU.

[0025] Render Texture is used to render images and allows the rendered result to be saved as a reusable texture. Essentially, it is a memory area that temporarily stores images and is created and managed by the GPU.

[0026] Fragment shaders perform color calculations on pixels during the rendering process.

[0027] Vulkan is a low-overhead, cross-platform 2D and 3D graphics and computing application interface. Unlike OpenGL, Vulkan is a low-level API that can perform parallel tasks and better allocate the use of multiple CPU cores.

[0028] Metal, developed by Apple, is an application programming interface that combines graphics and computing functions, targeting low-level, low-overhead hardware acceleration.

[0029] API stands for Application Programming Interface.

[0030] First Embodiment

[0031] The first embodiment of this application relates to a method for generating fog of war. For example... Figure 1 As shown, the method is applied to a graphics processor, and the method may include the following steps:

[0032] Step S10: Determine static and dynamic objects based on their update frequency during the game.

[0033] Step S20: Determine a first rendering texture and / or a second rendering texture based on the static object and the dynamic object; the first rendering texture is used to characterize the state of the area covered by the view of the static object, and the second rendering texture is used to characterize the state of the area covered by the view of the static object and / or the dynamic object.

[0034] Step S30: Generate fog of war based on the first rendering texture and / or the second rendering texture.

[0035] First, it should be noted that the method is applied to a graphics processing unit (GPU), and the technical solution of this embodiment uses the GPU as the execution entity. In some embodiments, the method can be adapted to multiple platforms such as mobile devices, PCs, and consoles, and can be adapted to various application programming interfaces such as OpenGL, Vulkan, and Metal.

[0036] The following sections will provide a detailed explanation of each of the above steps.

[0037] Specifically, regarding step S10, the update frequency typically refers to the time interval between two state updates of an object in the game. That is, the mechanism that refreshes and modifies the object's state again after a certain time interval since the last update. Static objects can include objects whose position and state typically do not change during game execution, while dynamic objects can include objects whose position and state may change during game execution. The update frequency of static objects is lower than that of dynamic objects. For example, in an open-world RPG game, static objects can be the game's scenery, including terrain, buildings, fixed trees, and immovable decorations such as streetlights and benches; dynamic objects can be player characters, NPCs, and items.

[0038] Specifically, in step S20, at the beginning of the rendering process, two rendering textures are created. The initial default value of the pixels is black, where black represents the invisible area and white represents the visible area. Static objects are rendered onto the first rendering texture, and dynamic objects and the first rendering texture are rendered together onto the second rendering texture.

[0039] For example, when a static object is updated, it can be rendered to a first rendering texture, while dynamic objects and the first rendering texture are rendered together to a second rendering texture. When a static object is not updated, only the dynamic object is rendered to the second rendering texture; in this case, the first rendering texture is reused instead of being rendered. Therefore, when static objects remain unchanged, this results in significant performance optimization and a simplified workflow. For instance, in an SLG game, the first rendering texture can display explored fog-of-war areas, the second rendering texture can display character movement, and the first rendering texture is only updated when the player starts exploring a new area, allowing it to be reused in the current area.

[0040] Specifically, step S30 involves overlaying the first and second rendering textures, and then performing logical operations on each pixel of the two textures to blend them into the final fog of war image. For example, the logical operations can be Boolean operations.

[0041] For steps S10-S30, for example, in a real-time strategy game, there are static objects such as fixed buildings and mountains, as well as dynamic objects such as moving soldiers and heroes. First, static and dynamic objects are distinguished. Objects with an update frequency greater than 2 minutes are classified as static objects, and objects with an update frequency less than or equal to 2 minutes are classified as dynamic objects. Then, a first rendering texture is generated to record the always-lit area covered by the building's view. A second rendering texture is generated, and a temporary view of soldiers and heroes moving is superimposed on the first rendering texture. Finally, fog of war is generated in the areas not covered by the texture.

[0042] It is understandable that in related technologies, the general approach to generating fog of war masks is through CPU computation. This approach results in a high CPU workload in complex scenarios. While generating fog of war masks using GPU computing cores can accelerate computation and reduce the CPU burden, it relies on support for Compute Shader. Furthermore, Compute Shader, as a shader program type within OpenGL ES and OpenGL, generally only supports higher versions of OpenGL ES and OpenGL (OpenGL ES 3.1 and above, OpenGL 4.3 and above).

[0043] It is not difficult to see that, compared with related technologies, the solution provided in this application, which generates fog of war based on GPU, can leverage the advantages of GPU parallel computing to accelerate computation. Static and dynamic objects are determined according to their update frequency during game execution. Thus, after identifying different objects, frame-by-frame updates are unnecessary, further reducing CPU load. Then, following a classification approach, a first rendering texture and / or a second rendering texture are determined based on static and dynamic objects. The first rendering texture represents the state of the area covered by the view of static objects, and the second rendering texture represents the state of the area covered by the view of static and / or dynamic objects. This process does not rely on Compute Shader; it only requires creating and managing Render Textures in the GPU. This can improve adaptability to low-end devices to a certain extent and adapt to multiple platforms such as mobile devices, PCs, and consoles with different rendering interfaces, offering better scalability and wider device compatibility. Finally, fog of war is generated based on the first and / or second rendering textures, flexibly accommodating both static and dynamic objects. Thus, by providing a GPU-based fog of war generation method, we can avoid overloading the CPU and relying on interface applets. When facing complex game graphics processing scenarios, the processing speed is faster, and it is less prone to frame drops or stuttering on the monitor. It is also compatible with both high-end and low-end devices.

[0044] Second Embodiment

[0045] The second embodiment of this application relates to a method for generating fog of war. The second embodiment is an improvement upon the first embodiment, specifically in that it provides a method for determining static and dynamic objects based on update frequency, as well as a method for determining the first rendering texture.

[0046] Optionally, in some embodiments, determining static and dynamic objects based on their update frequency during game execution, i.e., step S10, may include:

[0047] Step S101: Objects with an update frequency greater than a preset threshold are identified as static objects;

[0048] Step S102: Objects with an update frequency less than or equal to the preset threshold are identified as dynamic objects; wherein the number of dynamic objects is less than the number of static objects.

[0049] The following explanation uses the GPU as the primary execution mechanism.

[0050] Specifically, in steps S101 and S102, by determining the relationship between the object's update frequency and a preset threshold, objects with an update frequency greater than the preset threshold are identified as static objects, while objects with an update frequency less than or equal to the preset threshold are identified as dynamic objects. For example, the preset threshold can be 1 minute / time. Since the number of dynamic objects in the game design is less than the number of static objects, although the update frequency of dynamic objects is lower than that of static objects, static objects can be merged to reduce the communication pressure between the CPU and GPU. Furthermore, the fewer the number of dynamic objects, the less computation the GPU needs to perform. This distinction method can significantly reduce the computational burden.

[0051] Regarding steps S101-S102, for example, in an open-world survival game, it's necessary to distinguish between static and dynamic objects to optimize the fog of war calculation. Assuming a preset threshold of 2 minutes per instance, step S101 determines that trees, whose positions and states remain almost unchanged, can be marked as static objects. Step S102 determines that player characters, due to their multiple movements per second, and monsters, which roam randomly, can be marked as dynamic objects. Furthermore, there may be thousands of static trees on the map, but typically only a few dozen players and monsters, fitting the setting that the number of dynamic objects is less than that of static objects. Since static objects do not require recalculation every frame, the real-time visibility of dynamic objects is maintained.

[0052] Optionally, in some embodiments, step S20, the method for determining the first rendered texture may include:

[0053] Step S2010: When the state update of the static object is detected, the first initial rendering texture is set as the rendering target; the first initial rendering texture is used to represent a single-channel texture that has been pre-created and initialized to be all black.

[0054] Step S2011: Obtain the first parameter set; the first parameter set includes at least: map size parameters in the world scene, texture scale parameters, and position coordinates and field of view parameters of all static objects;

[0055] Step S2012: Determine the first rendering texture based on the first initialization rendering texture and the first parameter set.

[0056] Specifically, in step S2010, two rendering textures are created at the beginning of the rendering process. The initial default value of the pixels is black. When a static object state update is detected, one of the pre-created rendering textures is used as the first initial rendering texture and set as the rendering target.

[0057] Specifically, for step S2011, it is necessary to obtain relevant parameters of the world scene and static objects. The first parameter set, composed of these parameters, includes at least: map size parameters of the world scene, texture-to-world ratio parameters, position coordinates of all static objects, and view range parameters. The map size parameter of the world scene can be used to determine the coverage area of ​​the rendered texture. If the world scene map is large, the rendered texture needs to be segmented. The texture-to-world ratio parameter can be used to avoid texture stretching or pixel misalignment. Since the size of the rendered texture differs from the size of the game world, the ratio of the rendered texture to the world needs to be adjusted to match; otherwise, the content of the rendered texture will be distorted or blurred. The position coordinates of static objects can be used to determine the pixel coverage area; the view range parameter can be used to determine the view range of static objects, controlling the rendering area of ​​the rendered texture. The view range area is the area visible to the player from the game's perspective.

[0058] Specifically, in step S2012, the position coordinates of each static object are traversed in the fragment shader. The pixels covered by the static object are drawn as white according to the field of view parameter. For pixels that are not covered, the initial default value, i.e., black, can be retained. When the state of the static object changes, the inspection flag can be reset and the inspection process can be re-executed to update the visible area of ​​the static object.

[0059] For steps S2010-S2012, for example, in a strategy war game, the game map contains the following static objects: a watchtower with a circular field of view of 5 meters in radius; and a city wall used to block the field of view. According to step S2010, a pre-created rendering texture is used as the first initial rendering texture, with an initial value of RGB(0,0,0), indicating initial fog of war coverage. According to step S2011, the map size parameters in the world scene are obtained. Since the map size is 100m × 100m, the resolution of the first initial rendering texture can be 1024 pixels × 1024 pixels. The ratio parameters between the texture and the world scene are obtained, where 1 pixel = 0.1 meters. The position coordinates and field of view parameters of the static objects are obtained, where the position coordinates of watchtower 1 are (20m, 30m) with a field of view radius of 5m, the position coordinates of watchtower 2 are (70m, 50m) with a field of view radius of 5m, and the position coordinates of the city wall are (40m-60m, 40m), with a width of 20m and completely blocking the view behind. According to step S2012, a white circle with a radius of 50 pixels is drawn with the position coordinates of watchtower 1 as the center, representing the visible area; a white circle with a radius of 50 pixels is also drawn with the position coordinates of watchtower 2 as the center, representing the visible area; the city wall area is marked in black to indicate occlusion, so that when the view of a watchtower covers the city wall, the area behind it remains invisible. Finally, the result is output to the first rendering texture, thus the field of view of static objects can be reflected in the first rendering texture.

[0060] Optionally, in some embodiments, the step of determining the first rendering texture based on the first initialization rendering texture and the first parameter set, i.e., step S2012, includes:

[0061] Step S20121: Generate a first geometric primitive based on the size of the first initialized rendering texture, and establish a first mapping relationship from geometric vertices to texture coordinates;

[0062] Step S20122: For each pixel covered by the first geometric primitive, perform the following operations: obtain the current texture coordinates according to the first mapping relationship; convert the texture coordinates into world coordinates according to the map size parameters and scale parameters; determine the coverage state of the world coordinates according to the position coordinates and field of view parameters of the static object; determine the static visibility value according to the coverage state; the static visibility value is used to characterize whether the current pixel position is covered by the field of view of the static object.

[0063] Step S20123: Write the static visibility value into the corresponding position of the first initialized rendering texture to determine the first rendering texture.

[0064] Specifically, in step S20121, the texture cannot be rendered directly; it must be mapped onto geometric primitives for rendering. After mapping, a first geometric primitive covering the first initialized rendering texture can be generated. Since the world scene coordinates in the game are 3D coordinates and the coordinates of the rendered texture are 2D coordinates, a mapping relationship from three dimensions to two dimensions can be established. Specifically, a first mapping relationship is established from the vertices of the 3D model in the world scene to the texture coordinates, so that the information that needs to be rendered in the 3D model can be found based on the texture coordinates.

[0065] Texture coordinates are typically represented using S,T, but can also be represented using U,V, also known as UV coordinates. For specific calculation methods, please refer to the following:

[0066] Assume the map has a length of h and a width of w, and the origin of the map is (o). x ,o y The input point is p. i =(x i ,y i If the current UV coordinates are (u...), then the current UV coordinates are (u...). i ,v i )=((x i -o x ) / w,(y i -o y ) / h).

[0067] Specifically, for step S20122, for each pixel mapped from the rendered texture onto the first geometric primitive, its actual position in the game, i.e., world coordinates, is deduced using the UV coordinate calculation method described above. Then, static view detection is performed to determine whether the world coordinates corresponding to the current pixel are covered by at least one static object. Specifically, the following judgment is performed based on the position coordinates of the static object and the view range parameter:

[0068] If the field of view is circular, calculate the distance between the world coordinates and the position coordinates. If the distance is less than or equal to the radius of the circle, it is determined to be a covered state.

[0069] If the field of view is rectangular, then determine whether the world coordinates are within the rectangular boundary centered on the position coordinates. If they are within the rectangular boundary, then it is determined to be in a covered state.

[0070] For specific calculation methods, please refer to the following:

[0071] 1. Determine whether the current input (u,v) is within the radius range.

[0072] AND((uu i )<=r u ,(vv i )<=r v ) = true

[0073] If the condition is met, set the color to white; otherwise, set it to black.

[0074] 2. When the current input is a rectangle, the width of the input is w. i The input length is h i

[0075] Calculate the UV coordinates corresponding to the maximum and minimum values.

[0076] (Max u Max v )=(u i +w i / 2w,v i +h i / 2h)

[0077] (Min u Min v )=(u i -w i / 2w,v i -h i / 2h)

[0078] Determine whether the current input (u,v) is inside the rectangle.

[0079] AND(Min u <= u <= Max u Min v <= v <= Max v )==true

[0080] If the condition is met, set it to white; otherwise, set it to black.

[0081] For example, the static visibility value can be a binary value. When the static visibility value is 1, it indicates that there is an overlay state; when the static visibility value is 0, it indicates that there is no overlay state.

[0082] Specifically, in step S20123, the static visibility value is stored in the corresponding pixel position in the first initialized rendering texture, thereby determining the first rendering texture for the generation of fog of war.

[0083] For steps S20121-S20123, for example, assume the map size is a terrain grid of 1000m×1000m, the sentry tower's field of view is a circle with a radius of 20m, the coordinates in the world scene are (200m, 50m, 10m), the rendered texture resolution is 1024×1024 pixels, and 1 pixel ≈ 0.98m. According to step S20121, the XZ plane of the 3D world is projected onto the UV coordinates to create a 2D rectangle covering the entire map, with its vertex UV range from (0,0) to (1,1), which is used to carry the rendering texture and establish the first mapping relationship; according to step S20122, assuming that for a certain pixel in the texture, the coordinates are (205,51), the world coordinates (200m,50m) are derived by reverse calculation. By calculating the distance between this pixel and the watchtower, it is determined that the pixel is within the watchtower's field of view, so the pixel can be white and the static visibility value can be 1; according to step S20123, the static visibility value is written to the corresponding position of the first initialized rendering texture to determine the first rendering texture.

[0084] It is easy to see that, in the embodiments of this application, by providing a classification of static and dynamic objects based on update frequency, the workload of the GPU can be reduced. The provided first rendering texture determination method initializes the rendering texture, then maps the texture to primitives, establishes a mapping relationship between the world scene and texture coordinates, uses a first parameter set to help determine whether the world coordinates corresponding to the current pixel are covered by static objects, then determines the visible range of the fog of war of static objects, and generates the first rendering texture. This facilitates marking invisible areas without recalculation, ensures pixel-level accuracy without omissions, and renders only the visible areas, simplifying the GPU workflow.

[0085] Third Embodiment

[0086] The third embodiment of this application relates to a method for determining a second rendering texture. The third embodiment is an improvement upon the first embodiment, specifically in that it provides a method for determining the second rendering texture.

[0087] Optionally, in some embodiments, the method for determining the second rendered texture in step S20 may include:

[0088] Step S2020: When the state update of the dynamic object is detected, the second initialization rendering texture is set as the rendering target; the second initialization rendering texture is used to represent a single-channel texture that has been pre-created and initialized to be all black.

[0089] Step S2021, obtain the second parameter set; the second parameter set includes at least: the map size parameter and the scale parameter in the first parameter set, the position coordinates and field of view parameters of all dynamic objects, and the pixel data of the first rendering texture;

[0090] Step S2022: Determine the second rendering texture based on the second initialization rendering texture and the second parameter set.

[0091] Specifically, in step S2020, at the start of the rendering process, two black and white textures have been created, with the initial default value of the pixels being black. When a dynamic object state update message is received, one of the pre-created black and white textures is used as the second initial rendering texture and set as the rendering target.

[0092] Specifically, for step S2021, it is necessary to obtain relevant parameters of the dynamic object. The second parameter set related to the dynamic object includes at least: map size and scale parameters from the first parameter set, the position coordinates and view range parameters of the dynamic object, and pixel data of the first rendering texture. The map size and scale parameters from the first parameter set are introduced to ensure that the dynamic object is aligned with the map scale of the world scene and that coordinate transformations are consistent. The pixel data of the first rendering texture provides visibility information for static objects, allowing for optimized rendering of the dynamic object. The position coordinates of the dynamic object determine the pixel coverage area, and the view range parameter determines the view range of the dynamic object, controlling the rendering area of ​​the rendering texture. The view range area is the area visible from the player's perspective in the game.

[0093] Specifically, in step S2022, the position coordinates of each dynamic object are traversed in the fragment shader. The pixels covered by the static object are drawn as white according to the field of view parameter. For the pixels that are not covered, the initial default value, i.e., black, can be retained. When the state of the dynamic object changes, the inspection flag can be reset and the inspection process can be re-executed to update the visible area of ​​the dynamic object.

[0094] For steps S2020-S2022, for example, assume that a first rendering texture has been generated based on static objects. In the first rendering texture, the circular field of view of the watchtower is white, and the rest is black. The player character, as a dynamic object, has coordinates (150m, 200m) and a field of view radius of 15m in the world scene, and the map size is 500m × 500m. First, the initial all-black rendering texture is selected and set as the second rendering texture. The data of the second parameter set mentioned above is passed in, where the scale parameter is 1 pixel ≈ 0.49m. Then, the fragment shader performs coordinate transformation and dynamic field of view detection on the pixels. Taking pixel (300, 400) as an example, the coordinate transformation yields world scene coordinates (147m, 196m). The distance between the pixel and the player is calculated to be 5.85m. Therefore, this pixel is within the dynamic field of view and can be marked as white, with a dynamic visibility value of 1. According to step S2022, the dynamic visibility value is written to the corresponding position of the second initial rendering texture to determine the second rendering texture.

[0095] Optionally, in some embodiments, the step of determining the second rendering texture based on the second initialization rendering texture and the second parameter set, i.e., step S2022, includes:

[0096] Step S20221: Generate a second geometric primitive based on the size of the second initialized rendering texture, and establish a second mapping relationship from geometric vertices to texture coordinates:

[0097] Step S20222: For each pixel covered by the second geometric primitive, perform the following operations: obtain the current texture coordinates according to the second mapping relationship; convert the texture coordinates into world coordinates according to the map size parameters and scale parameters; determine the coverage state of the world coordinates according to the position coordinates and field of view parameters of the dynamic object; determine the dynamic visibility value according to the coverage state; sample the first rendered texture data to obtain the static visibility value; determine the mixed visibility value according to the static visibility value and the dynamic visibility value.

[0098] Step S20223: Write the mixed visibility value into the corresponding position of the second initial rendering texture to determine the second rendering texture.

[0099] Specifically, for step S20221, it is necessary to map the texture onto geometric primitives for rendering, generating a second geometric primitive that covers the second initial rendering texture. Additionally, it is necessary to establish a coordinate mapping from the game's world scene to the rendering texture to coordinate with the second geometric primitive for subsequent rendering. Specifically, establishing a second mapping relationship from the vertices of the 3D model in the world scene to texture coordinates allows the information corresponding to be rendered in the 3D model to be found based on the texture coordinates. The conversion from 3D world scene coordinates to texture coordinates can use the UV coordinate calculation method in the second embodiment.

[0100] Specifically, for step S20222, for each pixel mapped from the rendered texture onto the second geometric primitive, its actual position in the game, i.e., world coordinates, is deduced using the UV coordinate calculation method. Then, dynamic view detection is performed to determine whether the world coordinates corresponding to the current pixel are covered by at least one dynamic object. Specifically, based on the position coordinates of the dynamic object and the view range parameter, the following judgment is performed:

[0101] If the field of view is circular, calculate the distance between the world coordinates and the position coordinates. If the distance is less than or equal to the radius of the circle, it is determined to be a covered state.

[0102] If the field of view is rectangular, then determine whether the world coordinates are within the rectangular boundary centered on the position coordinates. If they are within the rectangular boundary, then it is determined to be in a covered state.

[0103] For example, the dynamic visibility value can be a binary value. When the dynamic visibility value is 1, it indicates that there is an overlay state; when the dynamic visibility value is 0, it indicates that there is no overlay state. Then, the static visibility value is obtained by sampling the first rendered texture data. Based on the static visibility value and the dynamic visibility value, a mixed visibility value is determined. In this process, logical operations can be performed on the static visibility value and the dynamic visibility value. For example, when performing an OR operation, if either visibility value is 1, then it is ultimately visible; when performing an AND operation, both must be 1 for it to be visible.

[0104] Specifically, in step S20223, the blended visibility value after logical operation is stored in the corresponding pixel position in the second initialization rendering texture, thereby determining the second rendering texture for generating the fog of war.

[0105] For steps S20121-S20123, for example, suppose the map size is a terrain grid of 1000m×1000m, the sentry tower's field of vision is a circle with a radius of 20m, the coordinates in the world scene are (200m, 50m, 10m), the rendered texture resolution is 1024×1024 pixels, 1 pixel ≈ 0.98m, the player's current position is (150m, 200m, 0m), and the field of vision radius is 15m. First, the XZ plane of the 3D world is projected onto the UV coordinates to create a 2D rectangle covering the entire map, with its vertex UV range from (0,0) to (1,1), which is used to carry the rendering texture and establish the second mapping relationship. Second, assuming that the coordinates (300,400) of a certain pixel in the texture are converted to the coordinates (293m,391m) of the world scene, dynamic field of view detection is then performed. After calculation, the distance between the pixel and the player is 238.5m, which is outside the player's field of view. Therefore, the pixel can be black, and the dynamic visibility value is 0. Assuming that after sampling the first rendering texture, the static visibility value of the pixel is 1, after the OR operation of the Boolean operation, the final blend value is 1. This blend value is written to the corresponding position of the first initial rendering texture to determine the second rendering texture.

[0106] It should be noted that this embodiment can also be an improvement based on the second embodiment.

[0107] It is not difficult to see that the embodiments of this application provide a method for determining the second rendering texture. The rendering texture is initialized, then mapped onto primitives, and a mapping relationship is established between the world scene and texture coordinates. Furthermore, to ensure that the dynamic object's map scale is aligned with the world scene and that the coordinate transformation is consistent with that of the static object, a first parameter set is introduced. Then, based on the dynamic object's position coordinates and field of view parameters, it is determined whether the world coordinates corresponding to the current pixel are covered by the dynamic object. The visible range of the dynamic object's fog of war is then determined, and the second rendering texture is generated. Thus, the second rendering texture is obtained by blending the first rendering texture of the static object, ensuring consistency between static and dynamic objects.

[0108] Fourth embodiment

[0109] The fourth embodiment of this application relates to a method for generating fog of war. The fourth embodiment is an improvement on any one or more of the first to third embodiments. Specifically, the improvement is that a method for generating fog of war based on a first rendering texture and / or a second rendering texture is provided in this embodiment.

[0110] Optionally, in some embodiments, the step of generating fog of war based on the first rendering texture and / or the second rendering texture, i.e., step S30, includes:

[0111] Step S301: Render a semi-transparent geometric patch covering the game map area;

[0112] Step S302: Obtain the texture coordinates corresponding to the current pixel in the semi-transparent geometric patch;

[0113] Step S303: Determine the visibility value based on the first rendering texture and / or the second rendering texture: wherein, if the visibility value indicates an overlay state, output a pixel color with an opacity of 0; if the visibility value indicates an uncovered state, output a fog of war color with a preset opacity.

[0114] Step S304: Write the pixel color into the screen buffer to generate fog of war.

[0115] For example, refer to Figure 2 This example demonstrates the formal rendering phase of the fog of war:

[0116] 1. Rendering a semi-transparent geometric surface: Overlay a semi-transparent surface on top of the game map as a canvas for the fog of war. The default color is RGB(0.2,0.2,0.2) dark gray with an opacity of 0.5.

[0117] 2. Obtain the texture coordinates of the current pixel. By establishing a coordinate mapping relationship, obtain the texture coordinates (UV coordinates) corresponding to the pixel.

[0118] 3. Determine the visibility value: Determine the visibility value based on the first and / or second rendering textures. Specifically, determine the content displayed on the screen based on whether a pixel is covered by the field of view. For example, when the visibility value is 1, it means that the position of the current pixel in the game world scene is covered by the field of view, and the output color is completely transparent, without displaying fog; when the visibility value is 0, it means that the position is not within the field of view, and the output color is the fog color with preset transparency, such as black.

[0119] 4. Write the pixel colors into the screen buffer to generate fog of war. Specifically, white, as a visible area, is displayed as completely transparent, revealing the underlying game world scene, while black, as an invisible area, is displayed as a semi-transparent gray.

[0120] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0121] Fifth embodiment

[0122] Some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0123] The electronic device includes: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the methods provided in any one or more of the above embodiments. Figure ×× discloses an exemplary structural diagram of the electronic device. The electronic device includes: one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected using different buses and can be mounted on a common motherboard or otherwise mounted as needed. The processor can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0124] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103 and output device 1104 may be connected by a bus or other means, as shown in the figure, which is connected by a bus.

[0125] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0126] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0127] In this embodiment, a computer-readable medium stores a computer program / instructions that, when executed by a processor, implement the steps of the methods provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into that device. The aforementioned computer-readable medium carries one or more computer-readable instructions.

[0128] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0129] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0130] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0131] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0132] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0133] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0134] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0135] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0136] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first," "second," etc., are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0137] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A method for generating fog of war, characterized in that, The method is applied to a graphics processor, and the method includes: Based on the update frequency of objects during game operation, determine static and dynamic objects; Based on the static object and the dynamic object, a first rendering texture and / or a second rendering texture are determined; the first rendering texture is used to characterize the state of the area covered by the view of the static object, and the second rendering texture is used to characterize the state of the area covered by the view of the static object and / or the dynamic object. Generate fog of war based on the first and / or second rendering textures.

2. The method according to claim 1, characterized in that, The process of determining static and dynamic objects based on their update frequency during game execution includes: Objects with an update frequency greater than a preset threshold are identified as static objects; Objects with an update frequency less than or equal to the preset threshold are defined as dynamic objects; wherein the number of dynamic objects is less than the number of static objects.

3. The method according to claim 1, characterized in that, The method for determining the first rendered texture includes: When a state update of the static object is detected, the first initial rendering texture is set as the rendering target; the first initial rendering texture is used to represent a single-channel texture that has been pre-created and initialized to be all black; Obtain the first parameter set; the first parameter set includes at least: map size parameters in the world scene, texture scale parameters relative to the world, and position coordinates and field of view parameters of all static objects; The first rendering texture is determined based on the first initial rendering texture and the first parameter set.

4. The method according to claim 3, characterized in that, The step of determining the first rendering texture based on the first initialized rendering texture and the first parameter set includes: Generate a first geometric primitive based on the size of the first initialized rendering texture, and establish a first mapping relationship from geometric vertices to texture coordinates: For each pixel covered by the first geometric primitive, perform the following operations: obtain the current texture coordinates according to the first mapping relationship; convert the texture coordinates into world coordinates according to the map size parameters and scale parameters; determine the coverage state of the world coordinates according to the position coordinates and field of view parameters of the static object; determine the static visibility value according to the coverage state; the static visibility value is used to characterize whether the current pixel position is covered by the field of view of the static object. Write the static visibility value to the corresponding position of the first initialized rendering texture to determine the first rendering texture.

5. The method according to claim 3, characterized in that, The method for determining the second rendered texture includes: When a state update of the dynamic object is detected, the second initialization rendering texture is set as the rendering target; the second initialization rendering texture is used to represent a single-channel texture that has been pre-created and initialized to be all black; Obtain a second parameter set; the second parameter set includes at least: the map size parameter and the scale parameter in the first parameter set, the position coordinates and field of view parameters of all dynamic objects, and the pixel data of the first rendering texture; The second rendering texture is determined based on the second initialization rendering texture and the second parameter set.

6. The method according to claim 5, characterized in that, The step of determining the second rendering texture based on the second initialized rendering texture and the second parameter set includes: Generate a second geometric primitive based on the size of the second initialized rendering texture, and establish a second mapping relationship from geometric vertices to texture coordinates: For each pixel covered by the second geometric primitive, perform the following operations: obtain the current texture coordinates according to the second mapping relationship; convert the texture coordinates into world coordinates according to the map size parameters and scale parameters; determine the coverage state of the world coordinates according to the position coordinates and field of view parameters of the dynamic object; determine the dynamic visibility value according to the coverage state; sample the first rendered texture data to obtain the static visibility value; determine the mixed visibility value according to the static visibility value and the dynamic visibility value. The mixed visibility value is written to the corresponding position of the second initial rendering texture to determine the second rendering texture.

7. The method according to any one of claims 1 to 6, characterized in that, The step of generating the fog of war based on the first rendering texture and / or the second rendering texture includes: Render semi-transparent geometric patches covering the game map area; Obtain the texture coordinates corresponding to the current pixel in the semi-transparent geometric patch; Based on the first rendering texture and / or the second rendering texture, a visibility value is determined: if the visibility value indicates an overlay state, a pixel color with an opacity of 0 is output; if the visibility value indicates an uncovered state, a fog of war color with a preset opacity is output. The pixel colors are written to the screen buffer to generate fog of war.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method as described in any one of claims 1 to 7.

9. A computer-readable medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7.

Images