Picture occlusion relation processing method and device and storage medium

Abstract

The invention discloses a picture occlusion relation processing method and device and a storage medium, and relates to the technical field of rendering, and the method comprises the steps: determining a vertical distance between a target element in a to-be-rendered frame and a preset base point; performing normalization processing on the vertical distance to generate a floating point value corresponding to each target element; encoding the floating point value to generate at least one integer channel value corresponding to the element; storing the integer channel value corresponding to the target element to vertex color information of the grid data corresponding to the target element to generate a rendering grid; and rendering the target element based on the rendering grid. According to the method, the normalized and coded depth value is borne through the vertex color information, so that the technical problem that the rendering performance is low due to the fact that the node tree needs to be traversed in each frame and massive elements need to be sorted in the prior art is solved, seamless fusion of the depth data of the rendered elements and the vertex colors is realized, and the rendering efficiency of the elements is improved.

Description

Technical Field

[0001] This application relates to the field of rendering technology, and in particular to a method, device and storage medium for processing screen occlusion relationships. Background Art

[0002] In the rendering process of traditional 2D games, multiple elements need to be processed. Different rendering scenes involve multiple elements, and the efficient processing of each element directly determines the rendering performance. Game engines typically organize all elements in the scene in the form of a node tree. When the occlusion relationship between elements needs to be adjusted, the relevant technology relies on sorting the nodes to change the rendering order. However, this process requires traversing the node tree and sorting a massive number of elements every frame, which leads to poor rendering performance.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a method for handling screen occlusion relationships, aiming to solve the technical problem that related technologies rely on sorting nodes to change the rendering order, but such sorting operations lead to low rendering performance.

[0005] To achieve the above objectives, this application proposes a method for processing image occlusion relationships, the method comprising:

[0006] Determine the vertical distance of the target element in the frame to be rendered relative to the preset base point;

[0007] The vertical distance is normalized to generate floating-point values ​​corresponding to each target element;

[0008] The floating-point value is encoded to generate at least one integer channel value corresponding to the element;

[0009] The integer channel value corresponding to the target element is saved to the vertex color information of the mesh data corresponding to the target element to generate the rendering mesh;

[0010] The target element is rendered based on the rendering mesh.

[0011] In one embodiment, the original elements are collected in the frame to be rendered by traversing the scene node tree;

[0012] The original elements are filtered to determine the target element;

[0013] Based on the preset base point and the target element, projection processing is performed to calculate the vertical distance of the target element relative to the preset base point.

[0014] In one embodiment, distributed extremum processing is performed on the vertical distance to calculate the minimum and maximum boundary values ​​of the vertical distance.

[0015] Based on the minimum boundary value and the maximum boundary value, the vertical distance is subjected to nonlinear mapping processing to generate depth data after the vertical distance is normalized.

[0016] The depth data is formatted to generate floating-point values ​​that conform to the internal format.

[0017] In one embodiment, the floating-point value is multiplied by a preset integer base sequence to perform scalar expansion processing, generating an expanded vector corresponding to the floating-point value;

[0018] The extended vector is discretized to generate at least one integer channel value corresponding to the element.

[0019] In one embodiment, the vertex color attribute storage bits corresponding to the mesh data are obtained according to the data structure of the mesh data corresponding to the target element;

[0020] The integer channel values ​​are bound to the vertex color attribute storage bits corresponding to the mesh data in a preset channel order;

[0021] The vertex color information of the mesh data is updated based on the integer channel value bound to the vertex color attribute storage bit to generate the rendered mesh.

[0022] In one embodiment, the vertex color value corresponding to the pixel is obtained according to the rendering instruction corresponding to the pixel of the target element;

[0023] The vertex color value is de-encoded and decoded to generate the floating-point value corresponding to the pixel;

[0024] The floating-point value is used as the reconstructed depth value of the pixel and compared with the buffered depth value in the depth buffer corresponding to the current pixel to generate a comparison result;

[0025] Based on the comparison results and the pixel rendering strategy, the pixel color values ​​in the depth buffer are updated or retained.

[0026] In one embodiment, if the comparison result is that the reconstructed depth value is greater than or equal to the buffer depth value, then the pixel color value corresponding to the reconstructed depth value is discarded, and the buffer depth value in the depth buffer remains unchanged.

[0027] If the comparison result is that the reconstructed depth value is less than the buffer depth value, then the reconstructed depth value is written into the depth buffer to replace the original buffer depth value.

[0028] In one embodiment, when the comparison result is that the reconstruction depth value is less than the buffer depth value, the corresponding rendering strategy is triggered;

[0029] According to the rendering strategy, the reconstructed depth value overwrites the original buffer depth value of the pixel;

[0030] According to the rendering strategy, the pixel color corresponding to the reconstructed depth value is output to the frame buffer of the pixel to update the pixel color of the frame buffer.

[0031] In addition, to achieve the above objectives, this application also proposes a processing device for screen occlusion relationships, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the screen occlusion relationship processing method described above.

[0032] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the screen occlusion relationship processing method described above.

[0033] This application provides a method for handling image occlusion relationships, including determining the vertical distance of a target element in a frame to be rendered relative to a preset base point; normalizing the vertical distance to generate floating-point values ​​corresponding to each target element; encoding the floating-point values ​​to generate at least one integer channel value corresponding to the element; saving the integer channel value corresponding to the target element to the vertex color information of the mesh data corresponding to the target element to generate a rendering mesh; and rendering the target element based on the rendering mesh. This application optimizes element rendering by using floating-point values ​​generated from the depth level of spatial position information for encoding, thus eliminating the need for sorting during element rendering and improving element rendering efficiency.

[0034] In summary, this application replaces the traditional depth management mechanism that relies on node tree sorting by carrying normalized and encoded depth values ​​in vertex color information. This overcomes the technical problem that related technologies rely on sorting nodes to change the rendering order, but this process requires traversing the node tree and sorting a massive number of elements every frame, which leads to low rendering performance. This application achieves seamless integration of depth data and vertex color of rendered elements, thereby improving the rendering efficiency of elements. Attached Figure Description

[0035] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0036] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0037] Figure 1 This is a flowchart illustrating the first embodiment of the method for handling screen occlusion relationships in this application;

[0038] Figure 2 This is a flowchart illustrating the third embodiment of the method for handling screen occlusion relationships in this application;

[0039] Figure 3 This is a flowchart illustrating the fifth embodiment of the method for handling screen occlusion relationships in this application;

[0040] Figure 4 This is a flowchart illustrating the sixth embodiment of the method for handling screen occlusion relationships in this application;

[0041] Figure 5 This is a flowchart of the encoding and decoding process for this application;

[0042] Figure 6 This is a flowchart illustrating the eighth embodiment of the method for handling screen occlusion relationships in this application;

[0043] Figure 7 This is a flowchart illustrating the rendering process of all elements in this application.

[0044] Figure 8 This is a schematic diagram of the structure of the device for processing screen occlusion relationships in this application.

[0045] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0046] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0047] The relevant technology relies on sorting nodes to change the rendering order, but this process requires traversing the node tree and sorting a massive number of elements every frame, resulting in poor rendering performance.

[0048] This application provides a solution: First, by determining the vertical distance of a target element in the frame to be rendered relative to a preset base point, the vertical distance is normalized to generate a floating-point value corresponding to each target element. Then, the floating-point value is encoded to generate at least one integer channel value corresponding to the element. Next, the integer channel value corresponding to the target element is saved to the vertex color information of the mesh data corresponding to the target element to generate a rendering mesh. Finally, the target element is rendered based on the rendering mesh.

[0049] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or a screen occlusion processing device capable of performing the above functions. The following description uses a screen occlusion processing device as an example to illustrate this embodiment and the subsequent embodiments.

[0050] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0051] This application provides a method for handling screen occlusion relationships, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the method for handling screen occlusion relationships in this application.

[0052] In this embodiment, the method for handling the image occlusion relationship includes steps S10 to S50:

[0053] Step S10: Determine the vertical distance of the target element in the frame to be rendered relative to the preset base point.

[0054] In this embodiment, the frame to be rendered refers to the current frame of the image that needs to be submitted to the GPU for rendering. The target element refers to the renderable object to be processed in the frame, such as an opaque element. The preset base point refers to the coordinate point used as the measurement reference, which is the camera position by default. The vertical distance refers to the straight-line distance along the vertical axis between the center of the target element's bounding box and the preset base point.

[0055] As an optional implementation, during the rendering preprocessing stage, the system establishes a reference coordinate system with a preset base point as the origin and obtains the coordinates of the center point of the world space bounding box corresponding to the target element. The difference between this center point and the preset base point along the vertical axis is calculated, and a signed floating-point vertical distance is generated based on this difference.

[0056] As an optional implementation method for obtaining spatial location information, during the game scene initialization phase, the CPU traverses all renderable elements in the scene node tree, extracts information from the transformation matrix of each element, and obtains the spatial location information corresponding to the element.

[0057] As an optional implementation method, during the game scene initialization phase, opaque elements are collected, information is extracted from the opaque elements, and the spatial position information corresponding to the opaque elements is obtained. Here, opaque elements refer to visual objects that completely obscure their background and do not present any transparency effect.

[0058] As an optional method for acquiring spatial location information, the world coordinates of the mesh vertices are analyzed to calculate the bounding box center position as the reference coordinates. The screen space depth value is then inferred by combining the model-view projection matrix in the shader. Spatial data is generated by adding a layer offset to the centroid coordinates of the colliders in the physics engine, or by directly reading a pre-baked depth texture and reconstructing pixel-level spatial location information through texture sampling.

[0059] Step S20: Normalize the vertical distance to generate floating-point values ​​corresponding to each target element.

[0060] In this embodiment, normalization refers to linearly mapping the vertical distance to a preset numerical range. Floating-point values ​​refer to single-precision binary real numbers conforming to the IEEE 754 standard.

[0061] As an optional implementation, the system calculates the global minimum and maximum boundary values ​​based on the vertical distance of the target elements in the current frame of the scene, using these as a normalized range benchmark. The minimum distance is subtracted from the current vertical distance to obtain a relative value. This relative value is then divided by the difference between the maximum and minimum boundary values ​​to obtain a scaling factor. This factor is then multiplied by a preset range span value and added to a preset lower limit value to generate a floating-point value within the target range. Floating-point values ​​with abnormal distances are truncated, and the final floating-point value corresponding to each element is output.

[0062] As an optional implementation method for generating floating-point values, the actual minimum and maximum depth levels are determined by reading the depth level of the corresponding target element in the scene. Based on the floating-point formula, the depth value of each element is linearly mapped to a preset range to generate a floating-point value.

[0063] As an optional implementation of the preset range, the floating-point values ​​within the preset range are specified as single-precision floating-point numbers in the interval [0, 1], where 0 represents the farthest point in the scene and 1 represents the nearest point.

[0064] As an alternative implementation of the floating-point formula, by determining the actual minimum depth level Lmin and the maximum depth level Lmax, the original depth value of each element is linearly mapped to the interval [0, 1] to generate a floating-point value according to the formula (current depth - Lmin) / (Lmax - Lmin).

[0065] Step S30: Encode the floating-point value to generate at least one integer channel value corresponding to the element.

[0066] In this embodiment, encoding refers to the process of discretizing continuous floating-point values ​​into fixed-bit integers. Integer channel values ​​refer to unsigned byte integers, corresponding to the data format of the color channels.

[0067] As an optional implementation, the normalized floating-point value is converted into a high-precision integer form, and then split into several octet segments through bitwise operations. Each octet corresponds to a color channel, and each segment is independently processed into an independent integer value in the range of zero to two hundred and fifty-five, which serves as at least one integer channel value corresponding to the element.

[0068] Step S40: Save the integer channel value corresponding to the target element to the vertex color information of the mesh data corresponding to the target element to generate a rendering mesh.

[0069] In this embodiment, mesh data refers to the vertex and face data structure that defines the geometry of an object. Vertex color information refers to the RGBA color attributes stored on each vertex of the mesh, where RGBA refers to a four-channel model describing color and transparency. Rendered mesh refers to a drawable mesh instance that integrates geometric data and material properties.

[0070] As an optional implementation, the system iterates through all target elements in the scene to obtain their vertex buffers for mesh data, and creates matching vertex color arrays based on the number of vertices. The encoded integer channel values ​​are then filled into the vertex color information of the element's corresponding mesh data according to a preset mapping rule. The updated mesh data is then combined with the original material to construct the rendering mesh corresponding to the target element.

[0071] As an optional implementation of storing integer channel values, the encoded integer channel values ​​are filled into the color attributes of each vertex according to a preset mapping rule: the red channel is written with the high-order data of the depth value, the green channel with the middle-order data, the blue channel with the low-order data, and the transparency channel is reserved or stored with the check value.

[0072] Step S50: Render the target element based on the rendering mesh.

[0073] In this embodiment, rendering refers to the complete process of generating a pixel image by executing drawing commands through a graphics API.

[0074] As an optional implementation, the system binds the mesh vertex buffer and index buffer to the GPU input slot, loads the associated material and configures the shader parameters, and then calls the graphics API drawing instructions to trigger vertex shader processing. After the vertex shader completes geometric transformation and rasterization, it enters the fragment shading stage, performs depth testing by reading vertex color depth information, and finally outputs the pixel color to the frame buffer to complete the visual rendering of the target element.

[0075] For example, during the game engine initialization phase, the system iterates through all renderable elements in the scene, accesses the transformation matrices of the elements, and extracts the X-axis and Y-axis positions in the world coordinate system, as well as the depth level values ​​that determine the occlusion order. Based on the global maximum and minimum depth levels of the current scene elements, the mapping range is determined, and the original depth value is linearly scaled to a normalized floating-point value between 0 and 1 (e.g., a depth of 2500 is mapped to 0.5 in the range [0, 5000]). This floating-point value is divided into consecutive 8-bit data segments from high to low binary bits, and each segment is converted into an integer value between 0 and 255 (e.g., a 32-bit floating-point value is split into four integer channels). The graphics interface is called to lock the mesh vertex buffer of the target element, and the generated integer channel values ​​are written to the red, green, blue, and opacity channels of each vertex's color attribute in a preset order. After completion, these are batch-submitted to the video memory to update the vertex color data stream, completing the physical binding of depth information and vertex colors, and updating the mesh data. Finally, the updated mesh data and the original material are combined to construct the rendering mesh corresponding to the target element. The vertex buffer of the element mesh is locked, and the integer channel values ​​are written to the RGBA channel storage bits of the vertex color attribute in a preset order (high bit → low bit) to construct a rendering mesh containing encoded depth information. Finally, the mesh is drawn in the GPU pipeline. The fragment shader reads the vertex color values ​​to reconstruct the depth and compares it with the depth buffer to achieve pixel-level rendering with depth testing.

[0076] By using vertex color information to carry normalized and encoded depth values, instead of the traditional depth management mechanism that relies on node tree sorting, this overcomes the technical problem that related technologies rely on sorting nodes to change the rendering order. However, this process requires traversing the node tree and sorting a massive number of elements every frame, which leads to low rendering performance. This achieves seamless integration of depth data and vertex color of rendered elements, improving the rendering efficiency of elements.

[0077] Based on any of the above embodiments, in Embodiment 2 of this application, step S10 includes steps A11 to A13:

[0078] Step A11: Collect the original elements in the frame to be rendered by traversing the scene node tree.

[0079] In this embodiment, the scene node tree refers to the tree-like data structure in the game engine that organizes scene objects according to parent-child hierarchical relationships. The collected raw elements refer to all unfiltered rendered objects obtained by traversing the scene node tree.

[0080] As an optional implementation, each acquired raw element is validated by traversing all child nodes of the scene node tree. This involves checking if the element is associated with valid mesh data, confirming that its material type is opaque and not marked as a static batching object, and finally verifying that the element's spatial transformation component is active. Valid elements are marked with Boolean flags, and raw elements to be processed are generated based on these marked valid elements.

[0081] Step A12: Filter the original elements to determine the target element.

[0082] In this embodiment, filtering refers to selecting a subset of objects that meet the processing criteria based on preset conditions. The elements to be processed refer to renderable objects that require depth information encoding and storage.

[0083] As an optional implementation, the system checks the activity state, rendering enable flag, and spatial visibility of each raw element through layers, while verifying whether the rendering layer matches the current rendering queue. Elements that pass the checks are added to the target element set to obtain the target element.

[0084] Step A13: Based on the preset base point and the target element, perform projection processing to calculate the vertical distance of the target element relative to the preset base point.

[0085] In this embodiment, projection processing refers to a calculation method that converts three-dimensional spatial positional relationships into distances along a specific axis.

[0086] As an optional implementation, the system establishes a local coordinate system based on the preset 3D coordinates of a base point. After obtaining the coordinates of the center point of the bounding box of the target element, it extracts the component of the line connecting the two points along the vertical axis through vector dot product operation. For scenes with an inclined base plane, the system calculates the perpendicular distance from the element's center point to the base plane. When processing elements without fixed shapes, such as particle systems, the system instead collects a set of sampling points at the location, calculates the average, and finally outputs a signed floating-point vertical distance value.

[0087] As an optional implementation of vertical distance generation, a view matrix is ​​constructed from the world coordinate system to the camera's local coordinate system by obtaining the position and orientation parameters of the currently active camera. All elements to be processed are traversed, and their world space coordinates are multiplied by the view matrix to perform a coordinate transformation, obtaining a relative position vector with the camera as the origin. The Z component of this vector is extracted as a spatial depth value, while the X / Y values ​​are retained for calculating the screen space position. The final output element contains spatial position information relative to the camera coordinates and the screen depth level, where the camera position refers to the coordinate point of the current rendering viewpoint in the world. The coordinate system refers to a local reference system established with the camera as the origin. Coordinate transformation refers to converting the element's world coordinates to local coordinates relative to the camera position. Information extraction refers to obtaining the object's spatial position data in the camera coordinate system from the transformed coordinates.

[0088] For example, before rendering each frame, the system initiates a scene node tree traversal, filtering the original elements to select a set of elements to be processed based on preset filtering conditions (including attributes such as valid meshes, non-UI controls, and dynamically transformed components). Then, a right-handed coordinate system (with the Z-axis pointing towards the camera) is established with the world coordinates of the currently active camera as the origin, and the global coordinates of the filtered elements are transformed into local camera coordinates using a view matrix. The local Z-axis coordinates of the transformed elements are extracted as the basic data for scene depth, while the XY plane positions are simultaneously preserved for frustum culling calculations. Finally, the system outputs the 3D spatial position information (X, Y, Z) of each element relative to the camera, and calculates the vertical distance of the target element relative to a preset base point using vector calculation based on the 3D spatial position information. The Z value directly represents the screen space occlusion priority, completing the preprocessing flow from dynamic filtering to spatial data transformation.

[0089] Since depth extraction based on the camera coordinate system ensures that the normalized depth value is stable and continuous under dynamic viewpoints, it solves the technical problem that traditional 2D rendering relies on world coordinate depth sorting, which causes depth value jumps and precision loss when the camera moves, thus improving the rendering efficiency and accuracy of elements.

[0090] Based on any of the above embodiments, in Embodiment 3 of this application, referring to Figure 2 , Figure 2 This is a flowchart illustrating the third embodiment of the method for handling screen occlusion relationships in this application. Step S20 includes steps B11 to B13:

[0091] Step B11: Perform distributed extremum processing on the vertical distance to calculate the minimum and maximum boundary values ​​of the vertical distance.

[0092] In this embodiment, the minimum boundary value refers to the global minimum value among all vertical distance values ​​of all elements. The maximum boundary value refers to the global maximum value among all vertical distance values ​​of all elements.

[0093] As an optional implementation, the system divides the scene space into uniformly sized grid cells, starts a parallel computing thread group on the GPU, performs local maximum and minimum value searches within each cell, and obtains the cell extrema through a shared memory reduction algorithm. After all cells have completed their calculations, the global reduction kernel function is started again, and the results of all cells are collected using a comparison and update method. Finally, the global minimum and maximum boundary values ​​of the entire scene are determined and output.

[0094] As an optional implementation method for generating depth levels, the system traverses the set of element spatial position data that has undergone coordinate transformation, and performs depth value separation operation on the spatial position information of each element. It directly reads the Z-axis coordinate component in the camera's local coordinate system, and according to the current camera projection mode, takes the reciprocal of the clipping space W component of the perspective projection and remaps it to a linear range. The original Z value is then projected based on the linear range to obtain the target Z value, which is then used as the depth level output.

[0095] Step B12: Based on the minimum boundary value and the maximum boundary value, perform nonlinear mapping processing on the vertical distance to generate depth data after the vertical distance is normalized.

[0096] In this embodiment, nonlinear mapping processing refers to the computational process of transforming input values ​​to a target range based on a specific function. Depth data refers to standard values ​​within a preset range generated after normalization processing.

[0097] As an optional implementation, the system calculates the effective range span based on the minimum and maximum boundary values. According to the corresponding mapping strategy, a square root enhancement function is used for near-field interactive objects to highlight detail sensitivity, a logarithmic compression function is used for distant environment objects to optimize large-scale distribution, and a linear scaling transformation is performed on UI controls to maintain uniformity. During the mapping process, the system dynamically detects boundary overflow risks and forcibly constrains values ​​exceeding the range to a preset range, ultimately generating floating-point depth data that conforms to single-precision standards.

[0098] As an optional depth data generation implementation method, the system dynamically calculates the minimum and maximum boundary values ​​of the original depths of all elements to be processed in the current scene. Based on a preset target interval, for each element's depth level, the system subtracts the minimum boundary value to obtain the relative depth difference, and then divides this by the difference between the maximum and minimum boundary values ​​to obtain a normalization scaling factor. Finally, the scaling factor is adjusted according to the upper limit of the preset range to generate the final depth data corresponding to the aforementioned depth level. Here, the preset range refers to the target numerical range for depth normalization. The minimum boundary value refers to the minimum value of all effective depths in the scene.

[0099] Step B13: Perform format standardization processing on the depth data to generate the floating-point value that conforms to the internal form.

[0100] In this embodiment, format specification processing refers to the operations of precision correction, range adjustment, and data type standardization of floating-point numbers. Internal form refers to the standardized floating-point number format supported by the engine's rendering pipeline.

[0101] As an optional implementation, the system verifies whether the data precision matches the single-precision floating-point format standard. If the input value is double-precision, the mantissa is forcibly truncated to limit its length. The validity of the numerical range is then checked to eliminate out-of-bounds exceptions. Denormalized floating-point numbers are forcibly set to zero for GPU processing unit compatibility. The final output is a single-precision floating-point value that conforms to the normalized floating-point format.

[0102] For example, the system extracts the original depth level values ​​from the spatial location information of the elements. Based on the real-time calculated minimum and maximum depth boundary values ​​of the scene (e.g., obtained through dynamic object bounding box analysis within the range of [-1500, 2000]), the system performs linear scaling on the original depth levels: each depth value is subtracted from the minimum boundary and then divided by the boundary difference to generate preliminary depth data. Outliers exceeding the boundaries are forcibly constrained to the [0, 1] interval. Subsequently, a floating-point format normalization operation is performed, checking whether the data precision is double-precision or denormalized. Double-precision values ​​are truncated to 23 bits for single-precision, and denormalized floating-point numbers are set to zero. Finally, a sequence of single-precision floating-point values ​​conforming to the IEEE 754 standard is output.

[0103] By extracting the depth level from the spatial location information and processing the depth level into floating-point values, the technical problems of loss of normalization precision caused by changes in depth boundaries in dynamic scenes and GPU calculation anomalies caused by non-standard floating-point numbers are solved. This achieves adaptive range scaling of depth values ​​and hardware-level format standardization, thereby improving the rendering efficiency of elements.

[0104] Based on any of the above embodiments, in Embodiment 4 of this application, step S30 includes steps C11 to C12:

[0105] Step C11: Multiply the floating-point value by a preset integer base sequence to perform scalar expansion processing, and generate the expanded vector corresponding to the floating-point value.

[0106] In this embodiment, the preset integer radix sequence refers to a predefined sequence of integer amplification coefficients. Scalar expansion processing refers to the operation of progressively amplifying a single-valued floating-point number according to the radix sequence and separating the integer and fractional parts. An expanded vector refers to a multidimensional numerical container composed of an integer part and a fractional part.

[0107] As an optional implementation, the system reads the normalized floating-point value, multiplies it by the radix of the first term of the sequence to generate an intermediate value, separates its integer part as the first component of the extended vector, takes the fractional part of the intermediate value, multiplies it by the radix of the next term, and separates the integer part as the second component. This process is repeated until all radix terms have been processed, and finally outputs an extended vector composed of integer components.

[0108] Step C12: Discretize the extended vector to generate at least one integer channel value corresponding to the element.

[0109] In this embodiment, discretization refers to the quantization operation that converts continuous values ​​into discrete integers.

[0110] As an optional implementation, the integer component is moduloed to obtain an integer value, the fractional component is multiplied, and a new integer is generated by rounding. A corresponding array of integer channel values ​​is generated in the order of the components. When a component value exceeds the byte range, the lower eight bits are automatically truncated to ensure that each output value strictly meets the preset integer range. The final output is an integer channel value with the same dimension as the extended vector.

[0111] For example, the system multiplies a normalized floating-point value by a preset integer base sequence (e.g., [65536, 256, 1]), and generates a multi-dimensional extended vector by separating the integer and fractional components through multi-level amplification. Each component of this extended vector is then discretized. The integer part is truncated using a bitwise AND operation to extract the lower eight bits, while the fractional part is rounded and scaled to the 0-255 range. Values ​​outside this range are forcibly constrained to byte boundaries. The final output is a sequence of integer channel values ​​matching the dimension of the base sequence.

[0112] By implementing 24-bit depth precision storage through radix expansion and discretization, the depth sorting error rate is reduced, while maintaining data compatibility of the vertex color RGBA channels, thus improving the rendering accuracy of elements.

[0113] Based on any of the above embodiments, in Embodiment 5 of this application, referring to Figure 3 , Figure 3 This is a flowchart illustrating the fifth embodiment of the method for handling screen occlusion relationships in this application. Step S40 includes steps D11 to D13:

[0114] Step D11: Based on the data structure of the mesh data corresponding to the target element, obtain the vertex color attribute storage bits corresponding to the mesh data.

[0115] In this embodiment, the data structure of the mesh data refers to the memory layout that stores attributes such as vertex coordinates, normals, UVs, and vertex colors. The vertex color attribute refers to the RGBA color data field bound to the mesh vertex. The vertex color attribute storage bit refers to the byte offset and channel index of the vertex color attribute in the vertex buffer memory.

[0116] As an optional implementation, the layout information of the vertex buffer corresponding to the target element is accessed to detect whether a vertex color channel declaration exists. If a vertex color channel declaration exists, its channel index number and byte offset are read. For dynamic mesh data, a real-time query mechanism is used, parsing the vertex color attribute storage bits in the shader input signature through graphics-related interfaces.

[0117] Step D12: Bind each of the integer channel values ​​to the vertex color attribute storage bit corresponding to the mesh data according to the preset channel order.

[0118] In this embodiment, the preset channel order refers to the order in which the channel values ​​are mapped to the vertex color attribute RGBA. Binding refers to the operation of writing data values ​​to the vertex attribute memory address.

[0119] As an optional implementation, based on the pre-parsed vertex color storage bit description information, channel binding operations are performed according to a preset channel order rule. By locking the vertex buffer memory block of the target mesh and using pointer arithmetic, the starting address of the first vertex color attribute is located. All vertices of the mesh are traversed in vertex index order, and each integer channel value is sequentially filled into the current vertex color attribute storage bit.

[0120] Step D13: Update the vertex color information of the mesh data according to the integer channel value bound to the vertex color attribute storage bit, and generate the rendering mesh.

[0121] In this embodiment, the vertex color information of the mesh data refers to the RGBA color attributes stored in the mesh vertex structure. Updating refers to the operation of writing the new channel value to the vertex color storage location and triggering data synchronization.

[0122] As an optional implementation, the system performs an update operation on each vertex of the mesh data using pre-calculated vertex color attribute storage information. It calculates the specific address of the target vertex in the video memory buffer based on the vertex index and writes the integer channel values ​​sequentially to the corresponding RGBA channel storage units according to a preset channel order. For batch vertex updates, memory mapping technology is used to lock the video memory area. Through direct memory access, each integer channel value is copied in batches to the vertex color attribute storage bit to update the vertex color information. Finally, the rendering mesh corresponding to the target element is generated based on the vertex color information.

[0123] As an optional implementation of updating vertex color information, after the update is completed, the video memory lock is released and a buffer failure notification is triggered, forcing the GPU to update the vertex buffer cache to ensure that the vertex color channel values ​​are accurately obtained by the shader program in subsequent rendering processes.

[0124] For example, the system first parses the vertex buffer structure description information of the mesh associated with the target element, locating the byte offset, channel index, and data format of its vertex color attributes in memory. Then, the sequence of integer channel values ​​to be written is mapped to the corresponding RGBA channel addresses according to preset rules (e.g., high-order depth values ​​are bound to the red channel, and median values ​​are bound to the green channel). The system calls the graphics API to lock the vertex buffer memory area, and uses direct memory access to batch write the channel values ​​to the specified vertex color attribute storage bits of each vertex, obtaining updated vertex color information. Finally, the system generates the rendering mesh corresponding to the target element based on the vertex color information.

[0125] By pre-computing storage bits and writing batch video memory directly, the technical problem of CPU and GPU data transfer bottleneck caused by the need to traverse a single vertex for dynamic vertex color updates has been solved, reducing update time and improving element rendering efficiency.

[0126] Based on any of the above embodiments, in Embodiment Six of this application, referring to Figure 4 , Figure 4 This is a flowchart illustrating the sixth embodiment of the method for handling screen occlusion relationships in this application. Step S50 includes steps E11 to E14:

[0127] Step E11: Obtain the vertex color value corresponding to the pixel of the target element according to the rendering instruction.

[0128] In this embodiment, the rendering instruction refers to the mesh drawing command included in the GPU drawing call. The corresponding pixel refers to the set of screen space pixels covered by the drawing instruction. The vertex color value refers to the pixel-level RGBA data generated from the mesh vertex attribute interpolation. Reading refers to the operation of obtaining the vertex color channel values ​​during the fragment shading stage.

[0129] As an optional implementation, when the GPU executes rendering instructions, the system maps the pixel coordinates covered by the triangle to the mesh vertex data, and calculates the vertex color interpolation weight based on the barycentric coordinates for each pixel corresponding to the target element. The input interpolator is accessed in the fragment shader, and the vertex color value corresponding to the RGBA channel value of the current pixel position is read from the pre-declared vertex color input structure.

[0130] Step E12: Perform a reverse encoding operation on the vertex color value to decode and generate the floating-point value corresponding to the pixel.

[0131] In this embodiment, decoding refers to the calculation process of reversing the discrete channel values ​​back to their original floating-point depth. Decoding refers to performing decoding operations to recover the original data.

[0132] As an optional implementation, the system obtains the vertex color value after interpolation of the current pixel in the fragment shader, calculates it according to the preset reverse encoding rules, generates an integer by weighting the values ​​of each channel, divides the integer by the total precision base, and converts it into a floating-point value within a preset range.

[0133] As an optional implementation for calculating floating-point values, the red channel value is first multiplied by the high-order weighting factor, the green channel value by the median weighting factor, and the blue channel value as the low-order base value. The products of these three parts are then added to generate a merged integer. This integer is then divided by the total precision base to convert it into a floating-point value in the range [0, 1]. If preset channel verification is enabled, an additional correction coefficient is added to this floating-point value to compensate for transmission errors, and the final reconstructed floating-point value is output.

[0134] Step E13: Use the floating-point value as the reconstructed depth value of the pixel and compare it with the buffered depth value in the depth buffer corresponding to the current pixel to generate a comparison result.

[0135] In this embodiment, the reconstructed depth value refers to the pixel depth value corresponding to the floating-point value. The depth buffer corresponding to the current pixel refers to the video memory area that stores the depth values ​​of rendered pixels. The buffered depth value refers to the depth value currently recorded at the pixel coordinates in the depth buffer. Comparison refers to comparing the numerical values ​​of two depth values. The comparison result refers to the reconstructed depth value and the buffered depth value.

[0136] As an optional implementation, the system obtains the reconstructed depth value in the fragment shader and simultaneously reads the buffered depth value already stored in the depth buffer for the current pixel. It then invokes the graphics hardware's depth test instruction, compares the reconstructed depth value and the buffered depth value according to predefined comparison rules, and obtains the comparison result.

[0137] Step E14: Update / retain the pixel color values ​​in the depth buffer based on the comparison results and pixel rendering strategy.

[0138] In this embodiment, the pixel rendering strategy refers to the logical rules that determine pixel color updates. The pixel color value refers to the RGBA color data of the corresponding pixel in the frame buffer. Update / Retain refers to determining whether to overwrite the original pixel color (update) or maintain the existing value (retain) according to the strategy.

[0139] As an optional implementation, the system determines pixel operations based on the depth comparison result and a preset rendering strategy. If the comparison result shows that the reconstructed depth value is less than the buffer depth value and the stencil test passes, the color update process is activated. The pixel color value output by the fragment shader is used to overwrite the corresponding pixel color in the frame buffer, and the depth buffer is refreshed with the reconstructed depth value. If the comparison result shows that the reconstructed depth value is greater than the buffer depth value or is rejected by the stencil test, the rendering pipeline is terminated, and the color and depth value write operations are skipped, while the pixel color value in the depth buffer is retained.

[0140] For example, refer to Figure 5 , Figure 5 This is a flowchart of the encoding and decoding process for this application. During CPU processing, the system traverses scene elements to obtain their spatial location information (e.g., the y-axis value in two-dimensional coordinates as the depth level), linearly normalizing the original depth value to a floating-point value z in the range [0, 1]. The z value is discretized into four integer channels of 0-255 using bit splitting technology (r stores the highest 8 bits, g stores the second highest 8 bits, b stores the third highest 8 bits, and a stores the checksum), and this RGBA data is batch-written into the vertex color attributes of the element mesh. During GPU rendering, the fragment shader reads the interpolated vertex color values, reconstructs the r / g / b / a channel values ​​into a floating-point depth z according to their weights, compares this z value with the current value in the depth buffer, and if the z value is less than the buffer value (i.e., not occluded), the depth buffer is updated and the pixel color is written. If the depth test fails, the pixel is discarded.

[0141] By using vertex color reading, reverse encoding calculation, depth comparison, and pixel decision-making, the technical problems of CPU computing bottleneck and rendering flicker caused by insufficient interpolation accuracy due to traditional dynamic depth sorting are overcome, thus improving the rendering efficiency of elements.

[0142] Based on any of the above embodiments, in Embodiment Seven of this application, step E14 includes steps F11 to F12:

[0143] Step F11: If the comparison result is that the reconstructed depth value is greater than or equal to the buffer depth value, then discard the pixel color value corresponding to the reconstructed depth value and keep the buffer depth value in the depth buffer unchanged.

[0144] In this embodiment, discarding means deleting the pixel color value corresponding to the reconstructed depth value when the reconstructed depth value is greater than the buffered depth value in the depth buffer.

[0145] As an optional implementation, when the GPU generates a reconstructed depth value during the fragment shading stage, it reads the buffered depth value stored at the same location in the depth buffer. The two values ​​are compared using a hardware depth test instruction. If the reconstructed value is greater than or equal to the buffered value, a pixel discarding process is triggered, terminating the pixel shading calculation. The color value corresponding to the pixel in the frame buffer is not updated, and the original depth value in the depth buffer remains unchanged.

[0146] As an optional dynamic precision allocation implementation, the system detects the view frustum proportion of elements during the depth normalization stage. When the element's projected size is smaller than a preset screen ratio, a preset precision mode is activated, and the preset precision is only activated for elements whose proportion exceeds a threshold. During vertex color encoding, a channel allocation scheme is dynamically selected, and empty channels are filled with checksums. When the shader reads data, the decoding algorithm is automatically switched based on the checksum flag of the first channel.

[0147] Step F12: If the comparison result is that the reconstructed depth value is less than the buffer depth value, then the reconstructed depth value is written into the depth buffer to replace the original buffer depth value.

[0148] In this embodiment, writing refers to the update operation that overwrites the reconstructed depth value into the depth buffer. Substitution refers to the overwriting behavior where the new value replaces the original buffer value.

[0149] As an optional implementation, when the GPU determines during the fragment shading stage that the reconstructed depth value is less than the buffer depth value, it immediately activates a depth buffer write operation. Through hardware instructions, the reconstructed depth value is written to the pixel's storage location in the depth buffer, completely overwriting the original buffer depth value. Simultaneously, the pixel color is output to the frame buffer to achieve dual updates of depth and color.

[0150] For example, when the GPU determines during the fragment shading stage that the reconstructed depth value is greater than or equal to the buffer depth value (e.g., 0.6 ≥ 0.4), it immediately triggers a pixel discarding mechanism, terminating the current fragment shading calculation, maintaining the original value of the depth buffer, and simultaneously skipping the frame buffer write operation to make the pixel invisible. Conversely, when the reconstructed depth value is less than the buffer depth value (e.g., 0.2 < 0.4), hardware instructions are invoked to overwrite the reconstructed depth value into the depth buffer, replacing the original data, and the new color generated by the fragment shader is simultaneously output to the frame buffer, completing the dual update of pixel depth and color.

[0151] By comparing the reconstruction depth value and the buffer depth value, and then updating or retaining the buffer, the rendering efficiency of elements is improved.

[0152] Based on any of the above embodiments, in Embodiment Eight of this application, referring to Figure 6 , Figure 6This is a flowchart illustrating the eighth embodiment of the method for handling screen occlusion relationships in this application. Step F12 includes G11 to G13:

[0153] Step G11: When the comparison result is that the reconstruction depth value is less than the buffer depth value, the corresponding rendering strategy is triggered.

[0154] In this embodiment, triggering refers to the control command that activates a preset logical flow. Rendering strategy refers to the set of operation rules that determine the writing of pixel color / depth.

[0155] As an optional implementation, when the GPU detects that the reconstructed depth value is less than the buffer depth value during the fragment shading stage, it immediately activates the depth test to pass the corresponding rendering strategy.

[0156] Step G12: According to the rendering strategy, the reconstructed depth value overwrites the original buffer depth value of the pixel.

[0157] In this embodiment, "overwrite" refers to the operation of replacing the original data at the target memory location. A pixel refers to an image unit at a specific coordinate position in the frame buffer. The original buffer depth value refers to the depth record of that pixel currently stored in the depth buffer.

[0158] As an optional implementation, when the rendering strategy requires updating the depth value, the system calls the depth write instruction of the graphics API to directly write the reconstructed depth value into the storage bit corresponding to the target pixel in the depth buffer through the GPU rendering output unit.

[0159] As an optional implementation of depth value updates, a depth test state machine locking mechanism is activated to ensure that other threads are prevented from accessing the data during the current pixel processing cycle, thus avoiding write conflicts. The lock is released immediately after the data is updated, and the depth buffer is marked.

[0160] Step G13: According to the rendering strategy, the pixel color corresponding to the reconstructed depth value is output to the frame buffer of the pixel to update the pixel color of the frame buffer.

[0161] In this embodiment, the frame buffer of a pixel refers to the video memory area that stores the final rendered image data. Pixel color update refers to the overwrite operation that replaces the original color value in the frame buffer.

[0162] As an optional implementation, after the GPU determines that the reconstructed depth value passes the depth test, the system activates the color output instruction in the rendering strategy. Through the semantic interface of the pixel shader, the pixel color value corresponding to the reconstructed depth value is written to the corresponding coordinate storage unit in the frame buffer. For semi-transparent elements, a preset blending calculation is performed; for opaque elements, the original value is directly overwritten. Finally, a memory barrier instruction is added at the pixel level to ensure the consistency of the video memory data and achieve the pixel color refresh specified by the frame buffer.

[0163] For example, when the GPU determines during the fragment shading stage that the reconstructed depth value is less than the buffer depth value (e.g., 0.18 < 0.42), it first activates the rendering strategy that passed the depth test: it calls hardware instructions to remove the write protection of the depth buffer and atomically overwrites the reconstructed depth value to the depth storage bit corresponding to the current pixel. Simultaneously, it obtains write permission to the frame buffer, directly outputs the new pixel color to the target coordinate storage unit for opaque elements, and performs alpha blending calculations (new color × Alpha + original color × (1-Alpha)) on semi-transparent elements before writing them. The operation process synchronously updates the depth buffer and frame buffer through the rendering output unit (ROP).

[0164] By updating the frame buffer corresponding to each pixel by comparing depth values, the number of times the last pixel value is written in the rendering pipeline is reduced, thus improving the rendering efficiency of elements.

[0165] Based on any of the above embodiments, in Embodiment Nine of this application, after step S50, steps H11 to H13 are further included:

[0166] Step H11: Extract information from the other type of elements collected to obtain the attribute information corresponding to the other type of elements.

[0167] In this embodiment, another type of element refers to transparent or semi-transparent elements. Attribute information refers to the core dataset describing the element's state, behavior, or visual characteristics.

[0168] As an optional implementation, the system traverses all elements carrying transparent markers during the scene initialization phase, extracts key parameters by accessing their material instance attribute tables, and summarizes the key parameters corresponding to another type of element into attribute information.

[0169] Step H12: Based on the attribute information corresponding to the other type of elements, sort the other type of elements to generate a rendering mesh corresponding to the other type of elements.

[0170] In this embodiment, sorting refers to the operation of rearranging elements according to specific rules to determine rendering priority.

[0171] As an optional implementation, the system performs composite sorting based on the extracted transparent element attribute information according to preset rules, placing high-rendering-level elements in lower-level elements. Elements of the same level are sorted from farthest to closest according to world space depth, and elements of the same material are merged after sorting to generate a processing mesh, finally outputting a rendered mesh with serial number markings.

[0172] Step H13: Render the other type of elements sequentially according to the arrangement order of the rendering mesh.

[0173] In this embodiment, sequential rendering refers to the execution flow of submitting GPU drawing requests one by one in a strictly ordered manner. Rendering refers to the process of generating pixels by executing mesh drawing commands through the graphics API.

[0174] As an optional implementation, the rendering mesh corresponding to another type of element is transmitted to the GPU, and the GPU renders the other type of element sequentially according to the arrangement order of the rendering mesh.

[0175] As an implementation method for optional transparent elements, a depth distribution heatmap is created simultaneously when generating vertex color depth for opaque elements. Before sorting transparent elements, the median depth value of the cell within which the transparent elements reside is first queried from the heatmap. For transparent elements within the same cell, the median depth from the heatmap is directly used instead of precise calculation. Precise sorting is only performed on elements that cross cells or whose median depth difference exceeds a threshold. On the GPU side, an additional cell tag ID is added to the transparent mesh for depth value verification and compensation during the blending stage.

[0176] For example, refer to Figure 7 , Figure 7 This is a rendering flowchart for the overall elements of this application. The system performs parallel dual-channel processing at the start of each frame's rendering: For opaque elements in the scene, the depth level value in their spatial coordinates is directly extracted, normalized to a floating-point value in the range [0, 1], then split into multiple 0-255 integer channel values ​​and written to the vertex color attribute (R / G / B channels store high / medium / low bit data respectively). After generating the rendering mesh, it is submitted to the GPU without sorting. Simultaneously, the material transparency and depth information of transparent elements are collected, sorted by depth from farthest to nearest, and then an independent rendering mesh is generated. During the GPU rendering stage, the fragment shader of the opaque element mesh reads the vertex color RGBA value, de-decodes and reconstructs it into a floating-point depth value, and compares it with the depth buffer value: if the reconstructed value is smaller, the depth buffer is updated and pixels are drawn; otherwise, it is discarded. The transparent element mesh undergoes standard blending rendering in the submission order, ultimately completing the correct optical composition of all elements in the scene and entering the next frame loop.

[0177] By processing transparent and opaque elements separately through different channels, the occlusion relationship is ensured to be continuous and correct, thus improving the rendering accuracy and efficiency of the elements.

[0178] This application provides a screen occlusion processing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the screen occlusion processing method in the above embodiment 1.

[0179] The following is for reference. Figure 8 This document illustrates a schematic diagram of a processing device suitable for implementing screen occlusion relationships in the embodiments of this application. The screen occlusion processing device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, desktop computers, personal digital assistants (PDAs), tablet computers (PADs), portable multimedia players (PMPs), portable computers, etc., as well as fixed terminals such as smart TVs, desktop computers, etc. Figure 8 The illustrated device for handling screen occlusion relationships is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0180] like Figure 8As shown, the screen occlusion processing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the screen occlusion processing device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the screen occlusion processing device to exchange data wirelessly or via wired communication with other devices. Although screen occlusion processing devices with various systems are shown in the figures, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0181] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0182] The image occlusion processing device provided in this application, employing the image occlusion processing method in the above embodiments, can solve the technical problem of updating the pixel color in the frame buffer of the pixel by outputting the pixel color corresponding to the reconstructed depth value according to the rendering strategy. Compared with the prior art, the beneficial effects of the image occlusion processing device provided in this application are the same as those of the image occlusion processing method provided in the above embodiments, and other technical features in this image occlusion processing device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0183] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0184] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0185] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the screen occlusion relationship processing method in the above embodiments.

[0186] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0187] The aforementioned computer-readable storage medium may be included in a screen occlusion processing device; or it may exist independently and not be assembled into a screen occlusion processing device.

[0188] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a screen occlusion processing device, the screen occlusion processing device: determines the vertical distance of a target element in the frame to be rendered relative to a preset base point; normalizes the vertical distance to generate a floating-point value corresponding to each target element; encodes the floating-point value to generate at least one integer channel value corresponding to the element; saves the integer channel value corresponding to the target element to the vertex color information of the mesh data corresponding to the target element to generate a rendering mesh; and renders the target element based on the rendering mesh.

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

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

[0191] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0192] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described method for processing screen occlusion relationships. This solves the technical problem that related technologies rely on sorting nodes to change the rendering order, but this process requires traversing the node tree and sorting a massive number of elements every frame, leading to low rendering performance. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the screen occlusion relationship processing method provided in the above embodiments, and will not be elaborated upon here.

[0193] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for handling image occlusion relationships, characterized in that, The method includes: Determine the vertical distance of the target element in the frame to be rendered relative to the preset base point; The vertical distance is normalized to generate floating-point values ​​corresponding to each target element; The floating-point value is encoded to generate at least one integer channel value corresponding to the element; The integer channel value corresponding to the target element is saved to the vertex color information of the mesh data corresponding to the target element to generate the rendering mesh; The target element is rendered based on the rendering mesh.

2. The method for handling image occlusion as described in claim 1, characterized in that, The step of determining the vertical distance of the target element in the frame to be rendered relative to the preset base point includes: By traversing the scene node tree, the original elements are collected in the frame to be rendered; The original elements are filtered to determine the target element; Based on the preset base point and the target element, projection processing is performed to calculate the vertical distance of the target element relative to the preset base point.

3. The method for handling image occlusion as described in claim 1, characterized in that, The step of normalizing the vertical distance to generate floating-point values ​​corresponding to each target element includes: Distributed extremum processing is performed on the vertical distance to calculate the minimum and maximum boundary values ​​of the vertical distance. Based on the minimum boundary value and the maximum boundary value, the vertical distance is subjected to nonlinear mapping processing to generate depth data after the vertical distance is normalized. The depth data is formatted to generate floating-point values ​​that conform to the internal format.

4. The method for handling image occlusion as described in claim 1, characterized in that, The step of encoding the floating-point value to generate at least one integer channel value corresponding to the element includes: The floating-point value is multiplied by a preset integer base sequence and then scalar expanded to generate the expanded vector corresponding to the floating-point value. The extended vector is discretized to generate at least one integer channel value corresponding to the element.

5. The method for handling image occlusion as described in claim 1, characterized in that, The step of saving the integer channel value corresponding to the target element to the vertex color information of the mesh data corresponding to the target element to generate the rendering mesh includes: Based on the data structure of the mesh data corresponding to the target element, the vertex color attribute storage bits corresponding to the mesh data are obtained; The integer channel values ​​are bound to the vertex color attribute storage bits corresponding to the mesh data in a preset channel order; The vertex color information of the mesh data is updated based on the integer channel value bound to the vertex color attribute storage bit to generate the rendered mesh.

6. The method for processing image occlusion relationships as described in claim 1, characterized in that, The step of rendering the pixels corresponding to the target element based on the rendering mesh includes: Based on the pixel of the target element corresponding to the rendering instruction, obtain the vertex color value corresponding to the pixel; The vertex color value is de-encoded and decoded to generate the floating-point value corresponding to the pixel; The floating-point value is used as the reconstructed depth value of the pixel and compared with the buffered depth value in the depth buffer corresponding to the current pixel to generate a comparison result; Based on the comparison results and the pixel rendering strategy, the pixel color values ​​in the depth buffer are updated or retained.

7. The method for handling image occlusion as described in claim 6, characterized in that, The step of updating / retaining the pixel color values ​​in the depth buffer based on the comparison result and the pixel rendering strategy includes: If the comparison result is that the reconstructed depth value is greater than or equal to the buffer depth value, then the pixel color value corresponding to the reconstructed depth value is discarded, and the buffer depth value in the depth buffer remains unchanged. If the comparison result is that the reconstructed depth value is less than the buffer depth value, then the reconstructed depth value is written into the depth buffer to replace the original buffer depth value.

8. The method for handling screen occlusion relationships as described in claim 7, characterized in that, The step of writing the reconstructed depth value into the depth buffer to replace the original buffer depth value if the comparison result is that the reconstructed depth value is less than the buffer depth value includes: When the comparison result shows that the reconstruction depth value is less than the buffer depth value, the corresponding rendering strategy is triggered; According to the rendering strategy, the reconstructed depth value overwrites the original buffer depth value of the pixel; According to the rendering strategy, the pixel color corresponding to the reconstructed depth value is output to the frame buffer of the pixel to update the pixel color of the frame buffer.

9. A device for processing image occlusion relationships, characterized in that, The device for processing screen occlusion relationships includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the screen occlusion relationship processing method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the screen occlusion relationship processing method as described in any one of claims 1 to 8.

Images