Rainwater rendering method and device in virtual scene, equipment, medium and program product

Abstract

The embodiment of the invention provides a rainwater rendering method and device in a virtual scene, equipment, a medium and a program product, and the method comprises the steps: detecting a rain event in the virtual scene, obtaining the pre-configured static depth information, the static depth information is depth information of each scene preset object in the virtual scene under an overhead view angle; in response to the rendering trigger condition, performing depth rendering on each non-preset dynamic object in the virtual scene to obtain dynamic depth information, the dynamic depth information being depth information of each non-preset dynamic object in the virtual scene under an overhead view angle; determining rainwater shielding information based on the static depth information and the dynamic depth information; and for the target rainwater particles in the virtual scene, the rendering state of the target rainwater particles is adjusted based on the rainwater shielding information. The problem of rainwater penetration caused by the fact that the non-preset dynamic object is not included in shielding judgment is avoided, and the authenticity of rainwater rendering is improved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of virtual scene rendering, in particular to a rain rendering method and device in a virtual scene, equipment, medium and program product. BACKGROUND

[0002] In virtual scene rendering, realistic weather effects (such as rain) are crucial to enhancing immersion. Realistic rain needs to accurately respond to scene geometry, avoiding appearing under occluders such as roof or eave interiors.

[0003] However, when the scene contains user-created objects (such as player-built houses), traditional occlusion culling methods based on offline baking are difficult to apply - such objects are dynamically generated at runtime and cannot be pre-included in static depth maps, causing rain to incorrectly penetrate or fall inside user-constructed structures, disrupting visual realism and interactive experience.

[0004] Therefore, there is an urgent need for a rain rendering method that improves the realism of rain rendering. SUMMARY

[0005] Therefore, the embodiments of the present application provide a rain rendering method in a virtual scene. One or more embodiments of the present application also relate to a rain rendering device in a virtual scene, a computing device, a computer-readable storage medium and a computer program product to solve the technical defects in the prior art.

[0006] According to a first aspect of the embodiments of the present application, a rain rendering method in a virtual scene is provided, comprising: detecting a rain event in a virtual scene, and obtaining pre-configured static depth information, wherein the static depth information is depth information of each scene preset object in the virtual scene from a bird's-eye view; in response to a rendering trigger condition, performing depth rendering on each non-pre-set dynamic object in the virtual scene to obtain dynamic depth information, wherein the dynamic depth information is depth information of each non-pre-set dynamic object in the virtual scene from a bird's-eye view; based on the static depth information and the dynamic depth information, determining rain occlusion information; based on the rain occlusion information, adjusting the rendering state of a target rain particle in the virtual scene.

[0007] According to a second aspect of the embodiments of the present application, a rain rendering device in a virtual scene is provided, comprising: The acquisition module is configured to detect a raining event in a virtual scene, and acquire pre-configured static depth information, wherein the static depth information is depth information of preset objects in the virtual scene in a bird's-eye view. The first rendering module is configured to perform depth rendering on each non-pre-set dynamic object in the virtual scene in response to a rendering trigger condition, to obtain dynamic depth information, wherein the dynamic depth information is depth information of the each non-pre-set dynamic object in the virtual scene in the bird's-eye view. The determination module is configured to determine rainwater shielding information based on the static depth information and the dynamic depth information. The second rendering module is configured to adjust a rendering state of a target rainwater particle in the virtual scene based on the rainwater shielding information.

[0008] According to a third aspect of an embodiment of the present application, a computing device is provided, comprising: a memory and a processor; The memory is configured to store computer programs / instructions, and the processor is configured to execute the computer programs / instructions, which realize the steps of the rainwater rendering method in the virtual scene.

[0009] According to a fourth aspect of an embodiment of the present application, a computer readable storage medium is provided, which stores computer programs / instructions, which realize the steps of the rainwater rendering method in the virtual scene when executed by a processor.

[0010] According to a fifth aspect of an embodiment of the present application, a computer program product is provided, comprising computer programs / instructions, which realize the steps of the rainwater rendering method in the virtual scene when executed by a processor.

[0011] An embodiment of the present application realizes detecting a raining event in a virtual scene, acquiring pre-configured static depth information, wherein the static depth information is depth information of preset objects in the virtual scene in a bird's-eye view, performing depth rendering on each non-pre-set dynamic object in the virtual scene in response to a rendering trigger condition, to obtain dynamic depth information, wherein the dynamic depth information is depth information of the each non-pre-set dynamic object in the virtual scene in the bird's-eye view, determining rainwater shielding information based on the static depth information and the dynamic depth information, and adjusting a rendering state of a target rainwater particle in the virtual scene based on the rainwater shielding information.

[0012] The static depth information of the preset objects in the scene and the dynamic depth information of the non-preset dynamic objects are acquired by separation, and the rain shielding information is generated by fusing the two in the bird's eye view, so that the rendering state of the rain particles can respond to the shielding relationship of the preset structure and the user-created content. Thus, the problem of rain penetration caused by the non-preset dynamic objects not being included in the shielding judgment is avoided, and the authenticity and consistency of rain rendering in the virtual scene containing UGC content are improved. BRIEF DESCRIPTION OF DRAWINGS

[0013] Figure 1 is a flow chart of a rain rendering method in a virtual scene provided by an embodiment of the present application; Figure 2 is a flow chart of a processing procedure of a rain rendering method in a virtual scene provided by an embodiment of the present application; Figure 3 is a structural schematic diagram of a rain rendering device in a virtual scene provided by an embodiment of the present application; Figure 4 is a structural block diagram of a computing device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0014] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present application. However, the present application can be practiced without the specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the present application.

[0015] The terminology used in the description of the one or more embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to limit the one or more embodiments of the present application. As used in the description of the one or more embodiments of the present application and the appended claims, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0016] It will be understood that, although the terms first, second, etc. can be used herein to describe various information, these terms are not intended to denote a temporal sequence. Rather, these terms are used only as distinguish one from another. For example, without departing from the scope of the one or more embodiments of the present application, first can be termed second, and similarly, second can be termed first. The term "if' as used herein means "when" or "upon" or "in response to the determination" depending on the context.

[0017] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of the present invention are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0018] First, the terminology used in one or more embodiments of the present invention will be explained.

[0019] PCF, or Percentage-Closer Filtering, is a graphics rendering technique used to soften shadow edges. This method calculates a smooth occlusion ratio by comparing and weighting multiple depth values ​​in the neighborhood surrounding a target sampling point in the depth map. This transforms harsh shadows into soft shadows with penumbra areas, effectively enhancing visual realism.

[0020] In modern 3D virtual scenes, especially immersive games, realistic weather systems are a key element in enhancing the realism of the environment and the player experience. Among them, rain scenes, as the most common dynamic weather effects, not only need to present the visual appearance of raindrops falling, but also need to interact reasonably with the geometric structure of the scene to avoid visual errors that violate the laws of physics, such as "rain falling indoors" or "rainwater penetrating the roof".

[0021] The core of this realism lies in the fact that when a player character or camera enters an occluded area (such as under a building, eaves, or bridge), the rainwater in that area should be correctly removed, i.e., rendering should stop, thus reflecting the natural phenomenon of "no rain in the occluded area." This requirement places high demands on the accuracy, real-time performance, and coverage of occlusion detection.

[0022] Currently, the mainstream rain occlusion technologies mainly fall into three categories: First, physical ray detection, which emits rays downwards from each raindrop position to determine whether it intersects with scene objects. Although it has high accuracy, the computational load is too large, making it difficult to support the real-time requirements of large-scale particle systems. Second, screen-space post-processing methods, which use the depth and normal information of the current frame to infer occlusion relationships. However, it is limited by the screen field of view and cannot handle occlusion outside the view frustum or complex geometric occlusion. Furthermore, it is prone to flickering or missed detection when the camera moves quickly. Third, a solution based on a global top-down depth map, which pre-baks a static occlusion map for raindrop sampling. This is highly efficient, but it is only applicable to fixed scene structures during the development phase and cannot respond to dynamically generated content at runtime.

[0023] The methods described above are all ineffective in handling open scenarios that include user-generated content (UGC). For example, when players build houses, place obstacles, or control mobile vehicles in the game, these dynamically appearing structures cannot be covered by pre-baked solutions. Real-time raycasting or screen-space methods cannot provide stable and efficient global occlusion information due to performance or viewpoint limitations, causing rain to appear incorrectly inside user-created occlusion areas, severely damaging immersion and logical consistency.

[0024] To address the above problems, this invention provides a method for rendering rain in a virtual scene. This invention also relates to a rain rendering device in a virtual scene, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0025] See Figure 1 , Figure 1 A flowchart of a rain rendering method in a virtual scene according to an embodiment of the present invention is shown, which specifically includes the following steps.

[0026] Step 102: Detect a rain event in the virtual scene and obtain pre-configured static depth information, where the static depth information is the depth information of each scene preset object in the virtual scene from the overhead view.

[0027] Among them, static depth information refers to the two-dimensional depth map generated by depth rendering of immutable scene preset objects in the scene from an overhead view during the game development stage. This map records the projection depth value of each preset object from top to bottom in a unified world coordinate system.

[0028] In practical applications, the system first monitors changes in weather conditions within the virtual scene. When a rain event is detected, it immediately reads pre-configured static depth information from a local program file. This program file embeds the static depth information as a resource during the game packaging stage. Its generation process is based on an orthographic projection camera fixed above the scene, which observes the entire scene vertically downwards and renders only the scene's pre-defined objects, ignoring all non-pre-defined dynamic objects and elements. The rendered depth buffer data is converted into a texture format and stored in the program resource directory as a mask map. At runtime, the system directly calls this texture through the resource loading interface without recalculating or rendering, thus ensuring that the initialization of static occlusion data is completed within milliseconds. The coordinate system of the static depth information is strictly aligned with the world coordinate system of the virtual scene, allowing subsequent rain particles to be directly mapped to the corresponding sampling points in the depth map based on their world positions.

[0029] In one specific embodiment of the present invention, the system continuously monitors the status signals of the weather system during game operation. When the weather system issues a "start raining" command, the system recognizes the command as a rain event and immediately executes the static depth information loading process. At this time, the system accesses the resource management module in the program file and locates a texture resource named "RainOcclusion_StaticDepth". This resource is automatically generated by the editor tool during the development phase: after the scene is edited, the editor automatically creates an orthographic camera 100 units above the center of the scene, with the view frustum covering the entire playable area. Then, all dynamic objects and user-generated layers are turned off, leaving only scene preset objects such as terrain, buildings, and rocks. A depth rendering is performed, and the result is saved as a 16-bit floating-point format texture. The system fully loads this texture into the GPU memory and binds it to the sampler unit used for subsequent occlusion detection. The entire process does not involve any runtime geometry processing or shader compilation; it only performs resource reading and memory mapping operations.

[0030] Furthermore, before detecting a rain event in the virtual scene and obtaining pre-configured static depth information, the method further includes: responding to the front-end marking operation to determine at least one marked scene preset object; setting an occluding camera with a top-down view at a preset top-down position in the virtual scene; determining the depth value of the at least one marked scene preset object by using the occluding camera, and generating static depth information; and packaging the static depth information into a program file.

[0031] Non-preset dynamic objects refer to those whose movement or changes cannot be predicted through preset paths or patterns. Unlike predictable dynamic objects such as vehicles moving along fixed trajectories in a scene, the behavior of these objects is highly uncertain and real-time, as their changes depend on the user's real-time actions or interactions or random events in the system. Front-end marking operations refer to the explicit annotation behavior performed by developers on specific scene-preset objects in the scene editor or development tools, used to declare that the object should participate in rain occlusion calculations; the occlusion camera refers to a dedicated rendering camera located at a fixed position above the virtual scene, using orthographic projection and pointing vertically downwards; static depth information is the depth map data generated by this camera only rendering the marked objects.

[0032] In practical applications, the system initiates a preprocessing process during game development. First, developers mark pre-defined scene objects (such as rooftops, bridges, and rocks) that need to produce rain occlusion effects in the scene editing interface, for example, by checking the "Participate in Rain Occlusion" attribute or grouping them into specific logical groups. The system responds to this operation by recording a list of references for all marked objects. Next, the system creates an occlusion camera at a preset height (e.g., 100 units) directly above the world coordinate system origin of the virtual scene. This camera faces the negative Y-axis of the world (i.e., vertically downwards), using orthographic projection, and its view frustum covers the entire playable area. Then, the system configures the rendering pipeline, enabling only the rendering queues for the marked scene pre-defined objects and disabling unnecessary functions such as lighting, textures, and color output, retaining only depth writing. The system drives the occlusion camera to perform a depth rendering, projecting the geometric surfaces of the marked objects onto the depth buffer to obtain the minimum depth value corresponding to each pixel. Finally, the system exports the depth buffer as a texture format (such as 16-bit floating-point R16F) and embeds it as a static resource in the program file's resource directory for direct runtime access. The entire process is completed offline during the build phase and does not consume game runtime resources.

[0033] In one specific embodiment of the present invention, the developer opens a virtual scene containing houses, trees, terrain, and decorations in the editor. For the main building roof, pavilion roof, and large rocks, the developer selects each one and checks the "Participate in Rain Occlusion" checkbox in the properties panel. The system collects the instance IDs of these marked objects in real time and adds them to the occlusion object list. Then, the developer clicks the "Generate Rain Occlusion Map" button, and the system automatically creates an orthographic camera 100 units directly above the scene center point (0,0,0), setting its near clipping plane to 1 unit and its far clipping plane to 200 units, with the viewport size matching the target occlusion map resolution (e.g., 2048×2048). The system temporarily switches the rendering context, turning off the rendering switches for all unmarked objects, retaining only the marked objects, and binding a shader that only outputs depth. The occlusion camera performs a complete rendering, and the GPU generates the corresponding depth buffer data. The system converts this data into a single-channel floating-point texture and packages it into the "Textures / Occlusion / " directory of the game's resource package under the name "StaticRainOcclusion.dds". This file is then included in the program files during the subsequent game build process, becoming a static resource that can be directly loaded at runtime.

[0034] Based on this, the system can accurately extract effective occlusion structures and generate spatially aligned static depth information during the development phase, avoiding the processing of irrelevant geometry at runtime, while ensuring that the occlusion data is strictly consistent with the scene design intent, providing a reliable foundation for efficient and accurate rainwater removal.

[0035] Step 104: In response to the rendering trigger condition, perform depth rendering on each non-preset dynamic object in the virtual scene to obtain dynamic depth information, wherein the dynamic depth information is the depth information of each non-preset dynamic object from the top-down view in the virtual scene.

[0036] Dynamic depth information refers to the depth map data obtained by the system in real time drawing the depth of existing non-preset dynamic objects based on the overhead view during the game. This data reflects the vertical projection depth value of these objects in a unified world coordinate system and is used to merge with static depth information to form a complete occlusion basis.

[0037] In practical applications, the system continuously monitors whether rendering trigger conditions are met. These conditions include, but are not limited to: detecting at least one non-preset dynamic object entering or leaving the view frustum of the occluding camera, a non-preset dynamic object undergoing a position or shape change, or reaching a preset occlusion map update cycle. When the conditions are met, the system activates the depth rendering process. First, it configures an orthographic camera with parameters identical to those in the static depth information baking stage, including the same camera height, orientation, viewport size, and projection matrix, to ensure coordinate system alignment. Subsequently, the system disables rendering output for scene preset objects, enabling only the rendering queue for non-preset dynamic objects and replacing their materials with a dedicated depth output shader. This shader does not perform lighting, texture sampling, or color calculations during rendering; it only writes the vertices of each non-preset dynamic object into the depth buffer after MVP transformation. Finally, the system copies the contents of the depth buffer into a texture, temporarily storing it in memory as dynamic depth information for subsequent occlusion compositing. The entire process is completed within a single rendering pass, avoiding performance degradation caused by multiple rendering passes.

[0038] In one specific embodiment of the present invention, at the beginning of each frame, the system checks whether there are any non-preset dynamic objects. If so, it further determines whether these objects have undergone position changes or addition / deletion operations since the last update. Assuming the player places a new house in the game, the system recognizes this addition as a valid rendering trigger condition. At this time, the system calls a pre-configured occlusion camera located 100 units directly above the scene center, using orthographic projection and its view frustum covering the entire map area. The system temporarily switches the rendering target to an off-screen rendering buffer with the same resolution as the static depth map and sets the rendering state to write depth only, disabling color writing. Next, the system iterates through all non-preset dynamic objects (including the newly placed house and existing vehicles, fences, etc.), submits them to the graphics pipeline, and draws them using shaders dedicated to depth output. After drawing, the system exports the depth data from the buffer as a texture named "DynamicDepth_Current" and marks it as valid dynamic depth information. The entire process does not involve any processing of scene-preset objects, nor does it change the rendering state of the main camera, ensuring minimal impact on the main thread performance.

[0039] Furthermore, the rendering triggering events include non-preset dynamic objects entering the camera's field of view and / or non-preset dynamic objects leaving the camera's field of view; in response to the rendering triggering conditions, depth rendering is performed on each non-preset dynamic object in the virtual scene to obtain dynamic depth information, including: setting an occluding camera with a top-down view at a preset top-down position in the virtual scene; in response to non-preset dynamic objects entering the camera's field of view and / or non-preset dynamic objects leaving the camera's field of view, determining the dynamic depth information of the non-preset dynamic objects by occluding the camera.

[0040] Among them, the rendering trigger event refers to the change in the spatial state of a non-preset dynamic object relative to the main camera's view frustum, including the object entering the field of view for the first time or completely leaving the field of view; the occlusion camera refers to a dedicated rendering camera located at a preset overhead position in the virtual scene, using orthographic projection and pointing vertically downwards; the dynamic depth information is the depth map data generated by the camera performing depth rendering on the currently visible non-preset dynamic objects when the trigger event occurs.

[0041] In practical applications, the system continuously monitors the intersection relationship between the view frustum of the main camera and the bounding volumes of each non-preset dynamic object during runtime. When it detects that the bounding volume of any non-preset dynamic object changes from being completely outside the view frustum to being partially or completely inside the view frustum (entering the field of view), or from being inside the view frustum to being completely outside (leaving the field of view), the system determines that a rendering trigger event has occurred. In response to this event, the system first sets up an occluded camera at a preset height directly above the origin of the world coordinate system of the virtual scene. This camera uses orthographic projection parameters that are completely consistent with those in the static depth information generation stage, including the same viewport range, near and far clipping planes, and orientation. Subsequently, the system enables the occluded camera and configures the rendering state to output depth only and disable color writing. The system traverses all non-preset dynamic objects in the current scene (regardless of whether they are within the view of the main camera) and submits them to the graphics pipeline for rendering using shaders dedicated to depth output. The GPU generates a depth buffer based on the viewpoint of the occluded camera, and the system exports the contents of this buffer as dynamic depth information for subsequent fusion with static depth information. The entire process ensures that dynamic depth information covers the spatial state of all non-preset dynamic objects, not just the part visible to the current main camera, thus avoiding omissions due to occlusion caused by field of view switching.

[0042] In one specific embodiment of the present invention, the system maintains a list of non-preset dynamic objects during game operation, including houses built by the player, moving vehicles, and temporarily placed occlusions. The main camera updates its view frustum parameters every frame. When a player drives a truck that was originally out of view into the screen range, the system detects that the truck's bounding box intersects with the main camera's view frustum for the first time, which is determined as an "entry into view" event. At the same time, another player's house in the distance completely moves out of the view frustum due to the camera zooming in, which the system determines as an "exit from view" event. The two events together trigger a rendering update. The system then activates a preset occlusion camera—located 100 units directly above the center of the scene, with orthographic projection covering the entire map area. The system disables the rendering of preset scene objects and only enables depth rendering for all non-preset dynamic objects (including the truck that just entered the view, the house that left the view, and other unchanged objects). The occlusion camera performs a complete depth rendering, generating a depth map containing the current spatial positions of all non-preset dynamic objects. The system temporarily stores this map as dynamic depth information for subsequent occlusion compositing. The entire process is completed within a single frame and is triggered only when the occlusion relationship may change.

[0043] Based on this, the system uses changes in the field of view as a trigger condition to achieve on-demand updates of dynamic depth information. This avoids unnecessary redrawing costs per frame and ensures that non-preset dynamic objects can be included in the occlusion judgment in a timely manner when their spatial positions change, effectively preventing rainwater from penetrating newly appeared or moved structures.

[0044] Furthermore, by occluding the camera, the dynamic depth information of non-preset dynamic objects is determined, including: creating a rain mask map, wherein the rain mask map is used to represent the depth information of each object in the virtual scene from the overhead view of the overhead position; writing static depth information into the rain mask map; and by occluding the camera, scheduling a dynamic shader to render the non-preset dynamic objects in the rain mask map to obtain the dynamic depth information of the non-preset dynamic objects, wherein the dynamic shader is a shader used to render the non-preset dynamic objects.

[0045] Among them, the rain mask map is a depth texture that covers the entire virtual scene from an overhead view and is used to uniformly store the occlusion depth of static and dynamic objects; the static depth information is the offline baked depth data of the scene's preset objects; the dynamic shader is a rendering program specifically for outputting the depth of non-preset dynamic objects. When it is executed, it does not calculate color or lighting, but only outputs the transformed depth value.

[0046] In practical applications, the system first creates an off-screen rendering target with the same resolution as the static depth information and initializes its depth appendage to empty or maximum depth values; this target is the rain occlusion map. Subsequently, the system writes the pre-loaded static depth information as the base data into the depth buffer of this rain occlusion map, which can be achieved through a full-screen copy or by directly binding a static texture as the initial depth state. After initialization, the system enables the occlusion camera, located at a preset overhead position in the virtual scene, using the same orthographic projection parameters as the static depth baking stage. Next, the system switches the rendering state: disabling color writing and enabling only depth writing, and enabling depth testing with the test function set to "less than (GL_LESS)" to preserve closer occlusion surfaces. The system iterates through all current non-preset dynamic objects, submits them to the graphics pipeline, and schedules the dynamic shader for rendering. During the vertex stage, the dynamic shader transforms the vertex coordinates of the non-preset dynamic objects to clip space using the occlusion camera's MVP matrix. During the fragment stage, it does not output color, only allowing the GPU to automatically write depth values ​​based on the transformed geometric positions. With depth testing enabled, the depth values ​​of non-preset dynamic objects are automatically compared with the existing static depth values ​​in the rain mask image, and the original value is overwritten only when the object is closer to the camera (i.e., has a smaller depth value). Ultimately, the rain mask image contains the nearest occlusion depths of both static and dynamic objects, forming complete dynamic depth information.

[0047] In one specific embodiment of the present invention, after detecting a change in the field of view of a non-preset dynamic object, the system initiates a dynamic depth information generation process. First, the system creates a 2048×2048 resolution rendering target and initializes its depth buffer to the maximum depth value (e.g., 1.0). Then, the system binds the loaded static depth texture as the source and writes the static depth value into the depth buffer of the rendering target through a single full-screen quadrilateral rendering, completing the initialization of the rain mask map. Next, the system activates the occlusion camera, located at world coordinates (0,100,0), facing the negative Y-axis, with an orthogonal projection range covering ±512 units on both the X and Z axes. The system sets the rendering state: color writing is off, depth writing is on, and the depth comparison function is "less than". The system traverses all non-preset dynamic objects in the current scene, including a newly placed cabin and a moving truck, submitting their mesh data to the GPU. Each object is drawn using a dynamic shader, which only contains vertex transformation logic and no fragment color output. The GPU calculates the depth of these objects based on the occluded camera's view and automatically compares it with the existing depth in the rain mask map during rasterization, updating the corresponding pixels only when the new depth is smaller. After rendering, the depth buffer of the rain mask map contains the blended depth data of static buildings and dynamic user objects, serving as dynamic depth information for subsequent use.

[0048] Based on this, the system ensures the spatial consistency between dynamic depth information and static data by sequentially writing static base and dynamic increment into a unified masking graph and automatically fusing them using a GPU depth testing mechanism.

[0049] Step 106: Determine rainwater shading information based on static and dynamic depth information.

[0050] Among them, rain occlusion information refers to a depth mask map that covers the entire virtual scene from an overhead view. Each pixel stores the nearest occlusion depth value in the vertical direction at that location. This value is determined by the smaller depth value of the corresponding location in the static depth information and the dynamic depth information, and is used for subsequent occlusion judgment of rain particles.

[0051] In practical applications, the system first allocates a temporary texture with the same resolution as the static depth information as the output target for the rain occlusion map. Then, the system completely copies the pre-loaded static depth information into this temporary texture as the occlusion basis. Next, the system uses the dynamic depth information as an overlay layer, comparing it pixel-by-pixel with the depth value at the corresponding position in the temporary texture: if the effective depth value of a pixel in the dynamic depth information is less than the currently stored depth value in the temporary texture, the pixel is updated with the dynamic depth value; otherwise, the original value is retained. This comparison and update operation is implemented through the depth testing mechanism in the graphics pipeline, specifically: the temporary texture is bound as a depth buffer, depth writing and depth testing are enabled, and the dynamic depth information is rendered in a full-screen quadrilateral format. Its fragment shader outputs the dynamic depth value, and the GPU hardware automatically completes the "minimum depth" fusion logic. The entire process does not require CPU pixel-by-pixel processing and can be efficiently completed within a single draw call. The final generated rain occlusion information includes the occlusion contributions of both scene-preset objects and non-preset dynamic objects, and the spatial coordinates are strictly aligned, allowing direct use for rain particle sampling and judgment.

[0052] In one specific embodiment of the present invention, after completing the loading of static depth information and the generation of dynamic depth information, the system initiates the occlusion map synthesis process. First, the system creates a rendering target with the same size as the static depth map (e.g., 2048×2048) and initializes its depth attachments to the content of the static depth information. Then, the system binds the rendering target and sets the depth comparison function to "less than (GL_LESS)," while enabling depth writing. Next, the system binds the dynamic depth information to a texture, draws a quadrilateral covering the entire screen space, and its vertex shader maps the quadrilateral to the NDC space above the camera. The fragment shader samples the depth value corresponding to the current fragment from the dynamic depth texture and uses it as the fragment's output depth. During rasterization, the GPU automatically performs a depth test: if the sampled dynamic depth value is less than the value in the current depth buffer, the depth at that position is updated; otherwise, it is discarded. After drawing is complete, the depth buffer of the rendering target becomes the final rain occlusion information. The entire process is completed within the GPU, with no CPU-GPU data round trips, resulting in extremely low latency.

[0053] Furthermore, based on static and dynamic depth information, rainwater occlusion information is determined, including: for a target location, determining the static and dynamic depth values ​​of the target location based on the static and dynamic depth information, wherein the target location is any two-dimensional coordinate position on the overhead projection plane of the virtual scene; determining the occlusion depth value of the target location based on the static and dynamic depth values; and determining rainwater occlusion information based on the occlusion depth values ​​of each position on the overhead projection plane.

[0054] Among them, the target position refers to any two-dimensional coordinate position of the virtual scene on the overhead projection plane, which corresponds to a vertical projection point in world space; the static depth value is the depth of the scene's preset objects at that position, sampled from the static depth information; the dynamic depth value is the depth of the non-preset dynamic objects at that position, sampled from the dynamic depth information; the occlusion depth value is the smaller of the static depth value and the dynamic depth value, representing the depth of the occlusion surface closest to the overhead camera at that horizontal position; and the rain occlusion information is a complete depth mask map composed of the occlusion depth values ​​of all target positions.

[0055] In practical applications, the system first establishes a two-dimensional coordinate grid with the same resolution as the static depth information. This grid covers the entire overhead projection plane of the virtual scene, with each grid point corresponding to a target location. For each target location, the system performs the following operations in parallel or point-by-point: using the two-dimensional coordinates of this location as texture sampling coordinates, it samples both the static and dynamic depth information to obtain the corresponding static and dynamic depth values. Then, the system compares these two depth values ​​and selects the smaller value as the occlusion depth value for that target location. This comparison can be based on floating-point numbers; if a depth value is invalid (such as the maximum depth or a null value), the other valid value is directly used. After calculating the occlusion depth values ​​for all target locations, the system organizes these values ​​in spatial order into a two-dimensional depth texture, i.e., rain occlusion information. Each pixel of this texture stores an occlusion depth value, and its coordinate system is strictly aligned with the overhead projection plane, allowing direct use for subsequent rain particle occlusion queries. The entire process can be processed pixel-by-pixel on the CPU or efficiently completed using a GPU shader in full-screen rendering mode.

[0056] In a specific embodiment of the present invention, after completing the loading of static depth information and the generation of dynamic depth information, the system initiates the occlusion information synthesis task. The system creates an output texture of the same size as the static depth map (e.g., 2048×2048) as a container for the rain occlusion information. Subsequently, the system binds a full-screen quadrilateral and enables a dedicated compositing shader. This shader receives two texture inputs: one is a static depth information texture, and the other is a dynamic depth information texture. During the fragment shading stage, the shader samples the depth values ​​d_static and d_dynamic from the two textures according to the screen coordinates (normalized) of the current fragment. If d_static is an invalid value (e.g., equal to the far clipping plane depth of 1.0), d_dynamic is used directly; if d_dynamic is an invalid value, d_static is used; if both are valid, min(d_static, d_dynamic) is taken as the output depth of the fragment. The system writes this depth value to the corresponding pixel position of the output texture. The entire rendering process is completed in a single GPU call, covering all target positions on the overhead projection plane. The final output texture is the complete rain occlusion information, where each pixel accurately reflects the depth of the nearest occluder at that horizontal position.

[0057] Based on this, the system compares the static and dynamic depth values ​​at each location and takes the minimum value to ensure that the rainwater shading information reflects the frontmost shading surface at each horizontal coordinate, avoiding misjudgment of shading caused by data coverage order or missing data, and providing an accurate basis for spatial removal of rainwater particles.

[0058] Step 108: For the target rain particles in the virtual scene, adjust the rendering state of the target rain particles based on the rain occlusion information.

[0059] Among them, the target rain particle refers to any rain particle to be processed in the virtual scene, which has a world coordinate position; the rain occlusion information is a depth mask map from an overhead view, which records the minimum occlusion depth at each horizontal position in the scene; adjusting the rendering state refers to controlling whether the particle is drawn, whether the transparency is set to zero, or whether to skip subsequent processing in the rendering pipeline based on the occlusion judgment result.

[0060] In practical applications, when rendering rain particles in each frame, the system iterates through all rain particles in the particle system. For the target rain particle being processed, the system first transforms its world coordinates to a top-down projection space consistent with the rain occlusion information, obtaining the corresponding two-dimensional texture coordinates and depth value. Then, the system uses these two-dimensional coordinates to perform texture sampling on the rain occlusion information, obtaining the occlusion depth value at that horizontal position. Next, the system compares the target rain particle's own depth value with the sampled occlusion depth value: if the particle's depth is greater than the occlusion depth (i.e., the particle is below the occluder), it is determined to be occluded; otherwise, it is determined to be visible. Based on this determination, the system adjusts the particle's rendering state—if occluded, its opacity is set to zero or the particle's drawing call is skipped; if not occluded, it is submitted to the rendering pipeline for shading and output according to the normal process. This judgment process is usually completed in the vertex shader or fragment shader of particle rendering, utilizing the GPU's parallel capabilities to achieve real-time processing of tens of thousands of particles.

[0061] In a specific embodiment of the present invention, when rendering rain, the system performs the following operations on each target rain particle in the particle system: First, it obtains the world coordinates (x, y, z) of the particle. Then, using the same top-view orthogonal projection matrix as when generating rain occlusion information, it transforms the coordinates to clip space and further converts them into texture sampling coordinates (u, v), where u and v correspond to the horizontal and vertical indices of the occlusion map, and the y coordinate is used as the vertical depth value of the particle. The system reads the occlusion depth d_occlude from the rain occlusion information using (u, v) as coordinates through the GPU texture sampling unit. Subsequently, it compares y with d_occlude in the shader: if y ≤ d_occlude, the particle is considered to be above or on the surface of the occlusion and should be rendered normally; if y > d_occlude, the particle is located inside or below the occlusion and should be culled. Based on this, the system sets the color output of the particle to completely transparent, or directly discards the fragment on hardware that supports early-z. The entire process is executed independently for each particle and is completed entirely in the GPU shader stage without CPU intervention.

[0062] Furthermore, a pre-defined overhead view position in the virtual scene is equipped with an occlusion camera with an overhead view. For target rain particles in the virtual scene, the rendering state of the target rain particles is adjusted based on rain occlusion information, including: determining the world coordinates of the target rain particles in the virtual scene; mapping the world coordinates to the clip space coordinates of the occlusion camera based on the coordinate transformation matrix of the occlusion camera; and adjusting the rendering state of the target rain particles based on the clip space coordinates and rain occlusion information.

[0063] Among them, the occlusion camera refers to a dedicated rendering camera set at a preset overhead position in the virtual scene, using orthogonal projection and vertically downward; the target rain particle is any rain particle to be processed in the virtual scene; the clipping space coordinates are standardized coordinates after transformation between the occlusion camera view and the projection matrix; the rain occlusion information is a depth mask map defined in the clipping space of the occlusion camera, used to determine whether there is occlusion at a certain horizontal position.

[0064] In practical applications, when rendering rain particles in each frame, the system performs spatial mapping and occlusion lookup for each target rain particle. First, the system obtains the particle's current world coordinates (x, y, z). Then, the system calls a pre-calculated coordinate transformation matrix from the occlusion camera. This matrix, obtained by multiplying the occlusion camera's view matrix by its orthogonal projection matrix, is used to convert the world coordinates to clip space coordinates. The system multiplies the particle's world coordinates by this matrix to obtain the corresponding clip space coordinates (x_clip, y_clip, z_clip). Next, the system normalizes the clip space coordinates to the texture sampling range: mapping x_clip and z_clip (or x_clip and y_clip, depending on the coordinate system convention) to the [0,1] interval, as the two-dimensional texture coordinates (u, v) for the rain occlusion information; simultaneously, y_clip (or z_clip) is retained as the particle's depth value in the vertical direction. The system uses (u, v) to perform texture sampling on the rain occlusion information to obtain the occlusion depth value d_occlude at that horizontal position. The system then compares the particle's depth value with `d_occlude`: if the particle's depth is greater than `d_occlude`, it is determined that it is located below an occluded object and should be culled; otherwise, it is retained. Based on this determination, the system adjusts the particle's rendering state, such as setting its opacity to zero, discarding the fragment, or skipping the draw call. This process is typically completed in the vertex or fragment shader of the particle rendering, leveraging the GPU's parallel capabilities to efficiently process a large number of particles.

[0065] In a specific embodiment of the present invention, the system processes a target rain particle located at world coordinates (120, 45, -80) during the rendering stage. The occlusion camera is located at (0, 100, 0), facing the negative Y-axis, using orthogonal projection, with a view frustum range of X∈[-512, 512], Z∈[-512, 512], Y∈[0, 100]. The system calls the camera's MVP matrix (view × projection) to transform the particle coordinates into clip space coordinates, obtaining (x_clip≈0.234, y_clip≈0.55, z_clip≈-0.312). The system linearly maps x_clip and z_clip to [0, 1], obtaining texture coordinates u=(0.234+1) / 2≈0.617, v=(-0.312+1) / 2≈0.344. The system samples the rain occlusion information using (u, v) to obtain an occlusion depth value of d_occlude = 0.62 (corresponding to a world Y coordinate of approximately 38). The particle's own y_clip = 0.55 corresponds to a world Y ≈ 45, which is greater than 38, meaning it is located below the occluded object. The system determines that the particle is occluded in the fragment shader and executes a discard instruction, preventing it from participating in the final color output. The entire process is executed independently for each particle and is completed entirely within the GPU shader.

[0066] Based on this, the system achieves spatial alignment between particle position and occlusion information through the coordinate transformation matrix of the occlusion camera, ensuring that depth comparison is performed in a unified coordinate system, thereby avoiding occlusion misjudgment caused by inconsistency in coordinate systems and improving the geometric accuracy of rainwater removal.

[0067] Furthermore, based on the clipping space coordinates and rain occlusion information, the rendering state of the target rain particles is adjusted, including: determining the top-view coordinates and rain depth information of the target rain particles based on the clipping space coordinates; determining the rendering status of the target rain particles based on the rain depth information and rain occlusion information; rendering the target rain particles when the rendering status indicates that the target rain particles are not occluded; and occluding the target rain particles when the rendering status indicates that the target rain particles are occluded.

[0068] Among them, the overhead coordinates refer to the two-dimensional texture sampling coordinates corresponding to the particle on the overhead projection plane; the rain depth information refers to the depth value of the particle in the vertical direction; the rain occlusion information is a texture that records the minimum occlusion depth at each horizontal position; the rendering status refers to the judgment result of whether the particle is occluded after comparing the rain depth information and the rain occlusion information.

[0069] In practical applications, the system first extracts the horizontal components (such as x_clip and z_clip) from the clipping space coordinates of the target raindrop particles, linearly mapping them to the [0,1] interval to obtain the overhead coordinates (u,v); simultaneously, it extracts the vertical components (such as y_clip) as raindrop depth information. Subsequently, instead of sampling raindrop occlusion information only once at (u,v), the system performs multiple offset samplings around this point within a preset neighborhood window (such as 3×3 or 5×5 pixels). For each sampling point, the system obtains its occlusion depth value and compares it with the raindrop depth information: if the raindrop depth is greater than the occlusion depth, it is counted as "occluded"; otherwise, it is "unoccluded." The system calculates the proportion of "unoccluded" points among all sampling points; this proportion is the visibility weight calculated by PCF. Then, the system judges the rendering status based on this weight: if the weight is higher than a preset threshold (such as 0.5), it indicates that the target raindrop particles are not completely occluded; otherwise, they are considered occluded. During the rendering phase, if the rendered representation is not occluded, the system renders the rain particle normally; if the representation is occluded, the particle is occluded by setting the particle opacity to zero, skipping the drawing, or performing a fragment discard operation. The entire PCF sampling and judgment process is completed in the fragment shader, which is efficiently implemented using the GPU texture sampling unit.

[0070] In a specific embodiment of the present invention, the system processes a target raindrop particle with clipping space coordinates of (x_clip=0.4, y_clip=0.6, z_clip=-0.2). The system maps x_clip and z_clip to overhead coordinates u=0.7, v=0.4, and y_clip=0.6 as raindrop depth information. The system enables a 5×5 PCF mode and generates 25 fixed offset sampling points around (u,v), each offset corresponding to a neighboring pixel in the occlusion map. The system sequentially samples the occlusion depth values ​​at these 25 locations to obtain a set of depth data. For each sampling point, if 0.6 > sampling depth, it is marked as occluded; otherwise, it is visible. Assuming 18 points are determined to be visible, the visibility weight is 18 / 25=0.72. Since this value is greater than the threshold of 0.5, the system determines that the particle is not completely occluded. In the fragment coloring stage, the system multiplies the particle's color by a transparency factor of 0.72 before outputting it. If another particle has a visibility weight of only 0.3, the system performs a discard operation, completely occluding that particle. The entire process is completed in a single fragment shader call, without requiring an additional rendering pass.

[0071] Based on this, the hard occlusion decision is transformed into a continuous visibility weight, which makes the rain particles present a natural transition at the occlusion boundary, effectively eliminating jaggedness and flicker, and significantly improving the visual softness and realism of rain occlusion.

[0072] In areas where rainwater occlusion occurs, judging the rendering based solely on single-point depth comparisons can lead to visual imperfections such as hard edges, jagged edges, or flickering at the occlusion boundaries, affecting the realism of the image. To address this, a further method is employed: determining the rendering status of target rainwater particles based on rainwater depth and occlusion information. This includes: sampling the rainwater occlusion information multiple times within the neighboring top-view coordinates to obtain multiple neighborhood occlusion depth values; comparing the rainwater depth information with each neighborhood occlusion depth value to calculate the proportion of unoccluded sampling points; determining the visibility weight of the target rainwater particles based on the proportion of unoccluded sampling points; and determining the rendering status of the target rainwater particles based on the visibility weight, where the rendering status includes at least one of occlusion, non-occlusion, and gradient occlusion. After determining the rendering status of the target rainwater particles based on the rainwater depth and occlusion information, the method further includes: if the rendering status indicates gradient occlusion, adjusting the transparency of the target rainwater particles according to the visibility weight, and rendering the target rainwater particles with the adjusted transparency.

[0073] Among them, the overhead coordinates refer to the two-dimensional sampling position of the target rain particles on the rain occlusion information texture; the neighborhood occlusion depth value refers to the occlusion map depth value obtained by sampling at multiple offset positions around the overhead coordinates; the proportion of unoccluded sampling points refers to the proportion of sampling points in all neighborhood samples whose rain depth is less than or equal to the occlusion depth; the visibility weight is the value of this proportion after mapping or weighting, used to characterize the light transmittance of the particles; gradient occlusion refers to an intermediate state between complete visibility and complete occlusion, which is a rendering effect of partial transparency.

[0074] In practical applications, the system first acquires the top-view coordinates (u,v) and rainwater depth information d_rain of the target rainwater particles. Then, the system performs multiple texture samplings within a preset neighborhood window centered at (u,v), for example, using a regular 3×3 or 5×5 grid distribution, or a randomized, Poisson disk distribution sampling mode. Each sampling point is offset by a fixed amount relative to the center coordinates. The system sequentially reads the neighborhood occlusion depth value d_occlude_i corresponding to each offset position from the rainwater occlusion information. For each sampling point, the system compares d_rain with d_occlude_i: if d_rain ≤ d_occlude_i, it is determined that the direction is not occluded; otherwise, it is occluded. The system counts the number of "unoccluded" sampling points across all sampling points and divides it by the total number of samples to obtain the proportion of unoccluded sampling points. This proportion can be directly used as a visibility weight, or it can be further adjusted through nonlinear functions (such as gamma correction or sigmoid mapping) to control the steepness of the transition curve. The system determines the rendering status based on visibility weights: a weight of 0 indicates "occluded"; a weight of 1 indicates "not occluded"; and a weight between 0 and 1 indicates "gradual occlusion". In subsequent rendering stages, the system performs corresponding operations based on this classification.

[0075] In one specific embodiment of the present invention, the system processes a target raindrop particle located at the edge of an obstruction, with its top-view coordinates being (u=0.632, v=0.418) and a raindrop depth d_rain=0.58. The system uses a 5×5 PCF mode with a total of 25 sampling points, each with a preset offset vector applied relative to the center. The system sequentially samples 25 neighboring occlusion depth values ​​from the raindrop occlusion information, obtaining a set of data, where the occlusion depth at 15 locations is greater than 0.58, and the remaining 10 are less than or equal to 0.58. The system determines that the 15 sampling points are "not occluded," accounting for 15 / 25=0.6. This value is the visibility weight. The system maps this weight to the particle's transparency α=0.6 and determines that it is in a "gradient occlusion" state. When rendering the particle, the system multiplies its base color by α before outputting it, making it appear as a semi-transparent falling effect, simulating the natural phenomenon of raindrops being partially blocked and partially passed through at the edge of an eave. The entire process is completed during the GPU fragment shading stage, without CPU involvement.

[0076] Based on this, the system transforms discrete occlusion judgments into continuous transparency adjustments through multi-point sampling and visibility weight calculation, enabling rain particles to present a natural transition between light and dark and a semi-transparent effect at the occlusion boundary, effectively eliminating hard edges and flickering, and significantly improving the visual softness and realism of rain occlusion.

[0077] One embodiment of the present invention provides a method for rendering rain in a virtual scene. By separating and acquiring the static depth information of preset objects and the dynamic depth information of non-preset dynamic objects, and fusing the two from a top-down perspective to generate rain occlusion information, the rendering state of rain particles can simultaneously respond to the occlusion relationship between preset structures and user-created content. This avoids the rain penetration problem caused by non-preset dynamic objects not being included in the occlusion judgment, and improves the realism and consistency of rain rendering in virtual scenes containing UGC content.

[0078] The following is in conjunction with the appendix Figure 2 Taking the application of the rain rendering method in a virtual scene provided by this invention in a game UGC scene as an example, the rain rendering method in the virtual scene will be further explained. Figure 2 The diagram illustrates a process flow of a rain rendering method in a virtual scene according to an embodiment of the present invention, which specifically includes the following steps.

[0079] Step 202: Offline static depth map baking.

[0080] During the scene editing or packaging stage, an offline baking process is performed. Using a top-down orthographic projection camera covering the entire or main game area, only all static objects in the scene are rendered, their depth information is recorded and saved as a static depth map. Because this process is completed offline, it does not affect the performance of the game during runtime.

[0081] Specifically, during the development and editing phase of a game scene, developers configure a camera to generate occlusion information, called an "occlusion camera." This camera typically has the following characteristics: Projection method: Orthographic projection.

[0082] Orientation: from top to bottom (e.g., rotated to (90,0,0)).

[0083] Clipping region: Its view frustum (a cuboid for orthographic cameras) needs to cover all game areas that may be obscured by rain. Its near and far clipping planes need to contain the height of all occlusions in the scene.

[0084] After configuring the occlusion camera, start the offline baking process. This process performs a special rendering that only renders all objects in the scene marked as "static" (such as terrain, mountains, fixed buildings, bridges, etc.). The output of this rendering is not a color image, but a depth map. The value of each pixel on the map records the depth value of the first static object encountered downwards by the occlusion camera at that location. This generated depth map is called a "static depth map," and it is saved as a texture resource and released with the game package.

[0085] Step 204: System initialization.

[0086] Once the game starts and is running, the rain occlusion system begins to function. During gameplay, the system creates a global, dynamic rain occlusion map (RenderTexture). This is updated in frames where occlusion information needs to be updated (or periodically).

[0087] Specifically, the system creates a temporary render texture in memory, called an "internalDepthBuffer". This texture is typically in a high-precision single-channel floating-point format (such as R32_SFloat) to accurately store depth values. Its resolution (e.g., 1024x1024) can be configured according to accuracy and performance requirements. The system loads the offline baked static depth map resource. The system holds an occlusion camera object (dynamicDepthCamera) with the same parameters as during offline baking, used to capture the depth of dynamic objects at runtime.

[0088] Step 206: Copy the static depth map to the rain cover map.

[0089] Step 206 is invoked when rain occlusion needs to be updated, for example, when a dynamic object enters or leaves the camera's field of view, or at fixed time intervals (such as updateTolerantDelta).

[0090] Specifically, the rain mask map is set as the current rendering target. Using a special shader (bakedMaterial) and a full-screen draw call (cmd.DrawProcedural), the entire contents of the static depth map are copied into the rain mask map. At this point, the rain mask map contains the occlusion information of all static objects.

[0091] Step 208: Render dynamic objects.

[0092] Using the same or identical overhead camera, only all objects in the scene marked as dynamic occluders (e.g., identified by a specific rendering layer mask) are rendered, and their depth information is plotted onto the same rain mask map. The depth test automatically handles the occlusion relationship between dynamic objects and the static background.

[0093] Specifically, with the rain mask map as the rendering target, the system then performs a second rendering. This time, it only renders dynamic objects that are set to specific rendering layers (dynamicObjectLayers). These objects are rendered by the same shader, which writes their depth information into the rain mask map. Thanks to the depth testing mechanism of the graphics API, dynamic objects are correctly occluded or obscured by the static background, and the depth values ​​are correctly written into the map.

[0094] After steps 206 and 208, the rain masking map is the final masking map containing information on all static and dynamic occlusions in the current frame.

[0095] Step 210: Coordinate transformation.

[0096] When the rain particle system in the game renders particles, each particle will undergo occlusion detection. For each particle, its world space position is obtained and transformed into the viewport space of the overhead camera.

[0097] Specifically, in the vertex shader or pixel shader, the world coordinates (worldPos) of the rain particles are obtained. Using the occluded camera's view matrix (_RainView) and projection matrix (_RainProj), the world coordinates are transformed to the occluded camera's clip space coordinates (rainCoord0). This process is completed in the CalculatRainUV function.

[0098] Step 212: Depth comparison.

[0099] By sampling the depth value at the corresponding location on the rain cover map and comparing it with the particle's own depth value, it can be determined whether the particle is under a certain obstruction.

[0100] Specifically, from the transformed clipping space coordinates, we can obtain the UV coordinates (rainPos.xy / rainPos.w) of the particle on the rain cover map and the particle's own depth value (rainPos.z / rainPos.w). Using the UV coordinates, we sample the rain cover map (_WeatherOcclusionTexture) to obtain the depth value (sampleDepth) of the occluder at that location. If the particle's depth value is greater than the occluder's depth value (considering a small offset _RainBias to avoid accuracy issues), it means the particle is below the occluder, i.e., it is occluded.

[0101] Step 214: PCF softens the edges.

[0102] When sampling the rain cover image, the edges are softened to avoid jagged or hard edges, resulting in a smoother and more natural transition effect.

[0103] Specifically, to achieve better visual effects, the SampleOcclusionDepthTexture_PCF function can be used instead of simple single-point sampling. This function performs multiple samplings (the number defined by _PCFSamples) around the current sampling point (the range defined by _PCFRadius). Each sampling involves a depth comparison, and the smoothstep function calculates a smooth occlusion value between 0 and 1 based on the depth difference and a soft transition range (_SoftTransition). Finally, the occlusion values ​​of all sampling points are averaged to obtain a soft occlusion result. This way, at the edges of the occluded object, rainwater will exhibit a natural fade-in / fade-out effect, rather than a harsh cut-off.

[0104] Through steps 202-214 above, by combining offline-processed static scene depth information with real-time updated dynamic object depth information, a highly efficient and high-quality rain occlusion effect is achieved. This significantly reduces runtime computational burden while perfectly supporting accurate occlusion detection for dynamically generated or moving objects in the game. Furthermore, by applying percentage nearest neighbor (PCF) filtering technology to soften occlusion edges, a smooth visual transition and natural appearance are ensured. This method not only enhances the realism and immersion of the game but also empowers developers to flexibly control the update frequency according to performance requirements, thereby optimizing performance without sacrificing quality.

[0105] Corresponding to the above method embodiments, the present invention also provides an embodiment of a rain rendering device in a virtual scene. Figure 3 A schematic diagram of a rain rendering device in a virtual scene according to an embodiment of the present invention is shown. Figure 3 As shown, the device includes: The acquisition module 302 is configured to detect a rain event in the virtual scene and acquire pre-configured static depth information, wherein the static depth information is the depth information of each scene preset object in the virtual scene from the overhead view. The first rendering module 304 is configured to perform depth rendering on each non-preset dynamic object in the virtual scene in response to the rendering triggering condition, and obtain dynamic depth information, wherein the dynamic depth information is the depth information of each non-preset dynamic object in the virtual scene from the top-down view. Module 306 is configured to determine rainwater occlusion information based on static depth information and dynamic depth information. The second rendering module 308 is configured to adjust the rendering state of the target rain particles in the virtual scene based on rain occlusion information.

[0106] Optionally, the rain rendering method in the virtual scene also includes an offline packaging module, configured to respond to the marking operation of the front end, determine at least one marked scene preset object; set an occluding camera with a top-down view at a preset top-down position in the virtual scene; determine the depth value of at least one marked scene preset object through the occluding camera, generate static depth information; and package the static depth information into the program file.

[0107] Optionally, the rendering triggering events include non-preset dynamic objects entering the camera's field of view and / or non-preset dynamic objects leaving the camera's field of view; accordingly, the first rendering module 304 is further configured to set the occlusion camera of the overhead view at a preset overhead position in the virtual scene; in response to non-preset dynamic objects entering the camera's field of view and / or non-preset dynamic objects leaving the camera's field of view, the dynamic depth information of the non-preset dynamic objects is determined by occluding the camera.

[0108] Optionally, the first rendering module 304 is further configured to create a rain mask map, wherein the rain mask map is used to represent the depth information of each object in the virtual scene from an overhead viewpoint; write static depth information into the rain mask map; and, by occluding the camera, schedule a dynamic shader to render non-preset dynamic objects in the rain mask map to obtain the dynamic depth information of the non-preset dynamic objects, wherein the dynamic shader is a shader used to render non-preset dynamic objects.

[0109] Optionally, the determining module 306 is further configured to determine the static depth value and dynamic depth value of the target location based on static depth information and dynamic depth information, wherein the target location is any two-dimensional coordinate position on the overhead projection plane of the virtual scene; determine the occlusion depth value of the target location based on the static depth value and dynamic depth value; and determine rainwater occlusion information based on the occlusion depth values ​​of each position on the overhead projection plane.

[0110] Optionally, a preset overhead view position in the virtual scene is equipped with an occlusion camera with an overhead view. Accordingly, the second rendering module 308 is further configured to determine the world coordinates of the target rain particles in the virtual scene; map the world coordinates to the clip space coordinates of the occlusion camera based on the coordinate transformation matrix of the occlusion camera; and adjust the rendering state of the target rain particles based on the clip space coordinates and rain occlusion information.

[0111] Optionally, the second rendering module 308 is further configured to determine the top-down coordinates and rain depth information of the target rain particles based on the clipping space coordinates; determine the rendering status of the target rain particles based on the rain depth information and rain occlusion information; render the target rain particles if the rendering status indicates that the target rain particles are not occluded; and occlude the target rain particles if the rendering status indicates that the target rain particles are occluded.

[0112] Optionally, the second rendering module 308 is further configured to sample the rain occlusion information multiple times within the overhead coordinate neighborhood to obtain multiple neighborhood occlusion depth values; compare the rain depth information with each neighborhood occlusion depth value to calculate the proportion of unoccluded sampling points; determine the visibility weight of the target rain particles based on the proportion of unoccluded sampling points; determine the rendering status of the target rain particles based on the visibility weight, wherein the rendering status includes at least one of occlusion, non-occlusion, and gradient occlusion; and when the rendering status indicates that the target rain particles are gradient occluded, adjust the transparency of the target rain particles according to the visibility weight, and render the target rain particles with the adjusted transparency.

[0113] One embodiment of the present invention provides a rain rendering device in a virtual scene. After detecting a rain event, the acquisition module 302 loads pre-baked static depth information of preset objects in the scene from a top-down view from a program file. The first rendering module 304, under rendering trigger conditions, performs real-time top-down depth rendering on non-preset dynamic objects to generate dynamic depth information. The determination module 306 merges the static and dynamic depth information to construct unified rain occlusion information. Finally, the second rendering module 308 adjusts the rendering state of the target rain particles based on this occlusion information. Thus, the visibility of rain particles responds simultaneously to the occlusion relationship between preset structures and user-created content, effectively avoiding rain penetration problems caused by non-preset dynamic objects not being included in the occlusion judgment, and significantly improving the realism and consistency of rain rendering in virtual scenes containing UGC content.

[0114] The above is a schematic scheme of a rain rendering device in a virtual scene according to this embodiment. It should be noted that the technical solution of the rain rendering device in the virtual scene and the technical solution of the rain rendering method in the virtual scene described above belong to the same concept. For details not described in detail in the technical solution of the rain rendering device in the virtual scene, please refer to the description of the technical solution of the rain rendering method in the virtual scene described above.

[0115] Figure 4 A structural block diagram of a computing device 400 according to an embodiment of the present invention is shown. The components of the computing device 400 include, but are not limited to, a memory 410 and a processor 420. The processor 420 is connected to the memory 410 via a bus 430, and a database 450 is used to store data.

[0116] The computing device 400 also includes an access device 440, which enables the computing device 400 to communicate via one or more networks 460. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 440 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0117] In one embodiment of the present invention, the above-mentioned components of the computing device 400 and Figure 4 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 4 The illustrated block diagram of the computing device is for illustrative purposes only and is not intended to limit the scope of the invention. Those skilled in the art can add or replace other components as needed.

[0118] The computing device 400 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 400 can also be a mobile or stationary server.

[0119] The processor 420 is used to execute the following computer program / instruction, which, when executed by the processor, implements the steps of the rain rendering method in the virtual scene described above.

[0120] The various embodiments in this invention are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the computing device embodiment is relatively simple in description because it is fundamentally similar to the rain rendering method embodiment in a virtual scene; relevant parts can be referred to in the description of the rain rendering method embodiment in a virtual scene.

[0121] An embodiment of the present invention also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the rain rendering method in the virtual scene described above.

[0122] The various embodiments in this invention are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the computer-readable storage medium embodiment is relatively simple in description because it is fundamentally similar to the rain rendering method embodiment in a virtual scene; relevant parts can be referred to in the description of the rain rendering method embodiment in a virtual scene.

[0123] An embodiment of the present invention also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the above-described rain rendering method in a virtual scene.

[0124] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the above-described rain rendering method in a virtual scene belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the above-described rain rendering method in a virtual scene.

[0125] The foregoing has described specific embodiments of the invention. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0126] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0127] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments of the present invention.

[0128] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0129] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments of the present invention. These embodiments are selected and specifically described to better explain the principles and practical applications of the present invention, thereby enabling those skilled in the art to better understand and utilize the invention. The present invention is limited only by the claims and their full scope and equivalents.

Claims

1. A method for rendering rain in a virtual scene, characterized in that, include: A rain event is detected in the virtual scene, and pre-configured static depth information is obtained, wherein the static depth information is the depth information of each scene preset object in the virtual scene from the overhead view. In response to the rendering triggering condition, depth rendering is performed on each non-preset dynamic object in the virtual scene to obtain dynamic depth information, wherein the dynamic depth information is the depth information of each non-preset dynamic object in the virtual scene from the overhead view. Based on the static depth information and the dynamic depth information, rainwater shading information is determined; For the target rain particles in the virtual scene, the rendering state of the target rain particles is adjusted based on the rain occlusion information.

2. The method according to claim 1, characterized in that, Before detecting the rain event in the virtual scene and obtaining the pre-configured static depth information, the method further includes: In response to the front-end's marking operation, identify at least one scene preset object that has been marked; In a virtual scene, set a camera that obstructs the view from a preset overhead position. Using the occluded camera, the depth value of at least one marked scene preset object is determined, and static depth information is generated; The static depth information is packaged into the program file.

3. The method according to claim 1, characterized in that, The rendering trigger events include non-preset dynamic objects entering the camera's field of view and / or non-preset dynamic objects leaving the camera's field of view. In response to the rendering trigger condition, depth rendering is performed on each non-preset dynamic object in the virtual scene to obtain dynamic depth information, including: In a virtual scene, set a camera that obstructs the view from a preset overhead position. In response to a non-preset dynamic object entering the camera's field of view and / or a non-preset dynamic object leaving the camera's field of view, the dynamic depth information of the non-preset dynamic object is determined by occluding the camera.

4. The method according to claim 3, characterized in that, The step of determining the dynamic depth information of the non-preset dynamic object through the occluded camera includes: Create a rain mask map, wherein the rain mask map is used to represent the depth information of each object in the virtual scene from the overhead view at the overhead position; Write the static depth information into the rain cover image; Using the occlusion camera, a dynamic shader is scheduled to render the non-preset dynamic object in the rain mask image to obtain the dynamic depth information of the non-preset dynamic object, wherein the dynamic shader is a shader used to render the non-preset dynamic object.

5. The method according to claim 1, characterized in that, The determination of rainwater obstruction information based on the static depth information and the dynamic depth information includes: For a target location, based on the static depth information and the dynamic depth information, the static depth value and dynamic depth value of the target location are determined, wherein the target location is any two-dimensional coordinate position on the overhead projection plane of the virtual scene; Based on the static depth value and the dynamic depth value, the occlusion depth value of the target location is determined; Rainwater occlusion information is determined based on the occlusion depth values ​​at various locations on the overhead projection plane.

6. The method according to claim 1, characterized in that, The virtual scene has a preset overhead view location with an occlusion camera; the process of adjusting the rendering state of target rain particles in the virtual scene based on the rain occlusion information includes: For the target rain particles in the virtual scene, determine the world coordinates of the target rain particles; Based on the coordinate transformation matrix of the occluded camera, the world coordinates are mapped to the clipping space coordinates of the occluded camera; Based on the clipping space coordinates and the rain occlusion information, adjust the rendering state of the target rain particles.

7. The method according to claim 6, characterized in that, The step of adjusting the rendering state of the target rain particles based on the clipping space coordinates and the rain occlusion information includes: Based on the clipping space coordinates, the overhead coordinates and rainwater depth information of the target rainwater particles are determined; Based on the rain depth information and the rain occlusion information, the rendering status of the target rain particles is determined; Render the target rain particles when the rendering condition indicates that the target rain particles are not occluded; When the rendering indicates that the target rain particles are occluded, the target rain particles are occluded.

8. The method according to claim 7, characterized in that, The step of determining the rendering status of the target rain particles based on the rain depth information and the rain occlusion information includes: The rainwater shading information is sampled multiple times within the neighborhood of the overhead coordinates to obtain multiple neighborhood shading depth values; The rainwater depth information is compared with the occlusion depth values ​​of each neighboring area, and the proportion of unoccluded sampling points is calculated. Based on the proportion of unobstructed sampling points, the visibility weight of the target raindrop particles is determined; Based on the visibility weight, the rendering status of the target rain particles is determined, wherein the rendering status includes at least one of being occluded, not being occluded, and gradient occlusion; After determining the rendering status of the target rain particles based on the rain depth information and the rain occlusion information, the method further includes: When the rendering condition indicates that the target rain particles are gradient occlusion, the transparency of the target rain particles is adjusted according to the visibility weight, and the target rain particles are rendered with the adjusted transparency.

9. A rain rendering device for a virtual scene, characterized in that, include: The acquisition module is configured to detect a rain event in the virtual scene and acquire pre-configured static depth information, wherein the static depth information is the depth information of each scene preset object in the virtual scene from the overhead view. The first rendering module is configured to perform depth rendering on each non-preset dynamic object in the virtual scene in response to a rendering trigger condition, thereby obtaining dynamic depth information, wherein the dynamic depth information is the depth information of each non-preset dynamic object in the virtual scene from an overhead view. The determination module is configured to determine rainwater occlusion information based on the static depth information and the dynamic depth information; The second rendering module is configured to adjust the rendering state of the target rain particles in the virtual scene based on the rain occlusion information.

10. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions. When the computer programs / instructions are executed by the processor, they implement the steps of the rain rendering method in the virtual scene according to any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, It stores a computer program / instruction that, when executed by a processor, implements the steps of the rain rendering method in the virtual scene as described in any one of claims 1-8.

12. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, implements the steps of the rain rendering method in the virtual scene according to any one of claims 1-8.

Images