Data rendering method and apparatus, storage medium, device, and program product
By organizing different types of scene primitive clusters into a unified spatial hierarchy in large-scale complex scenes, and performing unified visibility filtering and multi-path rendering, the problems of high resource consumption and low rendering efficiency in existing technologies are solved, achieving efficient rendering management and performance improvement.
Patent Information
- Application Number
- CN202610917068.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-23
- Publication Date
- 2026-11-03
AI Technical Summary
In large-scale complex scenes, existing technologies require separate view frustum clipping, detail level control, and occlusion culling for different types of scene primitives, resulting in excessive computational resource consumption, reduced rendering efficiency, and an inability to achieve efficient resource utilization and real-time rendering performance.
By mixing and organizing the first and second type scene primitive clusters in a unified spatial hierarchy, unified visibility filtering and multi-path rendering processing are performed, including view frustum clipping, LOD control and occlusion culling. The primitives are routed to their respective rendering paths for rendering, and the final results are fused by depth comparison.
It enables efficient management of scene data, reduces computational overhead and resource consumption during the rendering process, and improves resource utilization and real-time rendering performance.
Smart Images

Figure CN123032860A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, specifically to a data rendering method, apparatus, storage medium, device, and program product. Background Technology
[0002] With the development of real-time graphics rendering technology, in order to meet the high-fidelity rendering requirements of large-scale complex scenes, it is often necessary to integrate multiple different types of graphics representation primitives in the scene. For example, in addition to traditional mesh scene primitives, new scene primitives containing massive discrete or continuous spatial representations (such as volume primitives, probability field primitives, neural radiation field primitives, etc.) are also gradually being applied in fields such as game rendering, digital twins, and 3D reconstruction. In related technologies, these different types of scene primitives usually rely on their own independent loading, scheduling, and visibility determination pipelines, and perform processes such as projection, sorting, or blending in their respective rendering paths to generate the final rendered image.
[0003] However, in large-scale scenes, the number of scene primitives of different types is usually extremely large. When there are heterogeneous primitive clusters from multiple sources in the scene, related technologies often need to perform independent visibility judgments such as view frustum culling, Level of Detail (LOD) control, and occlusion culling for different primitives. This management approach not only leads to a large amount of duplication and redundancy in upstream visibility filtering calculations, but also significantly increases the scheduling overhead of the graphics processor-driven culling stage. Especially in large-scale scenes containing a large number of scene elements, since it is impossible to implement global joint culling across primitive types at the upstream level, the backend projection calculation, sorting calculation, and hybrid calculation processes have to withstand a large and redundant amount of data, resulting in high data read / write overhead and computational resource consumption overhead.
[0004] As the scale of the scene further expands, the above-mentioned processing methods can easily lead to a significant increase in data processing overhead during the rendering stage, resulting in problems such as excessive consumption of computing resources and decreased rendering efficiency. Therefore, large-scale scene rendering solutions in related technologies still need to be improved in terms of resource utilization and real-time rendering performance. Summary of the Invention
[0005] This application provides a data rendering method, apparatus, storage medium, device, and program product. By performing unified visibility filtering and path-based rendering processing on a first type of scene primitive cluster and a second type of scene primitive cluster, it provides an efficient rendering management mechanism for scene data, reduces computational overhead and resource consumption during the rendering process, and optimizes the real-time rendering performance of large-scale scenes.
[0006] On one hand, embodiments of this application provide a data rendering method, the method comprising: Obtain multiple first-type scene primitive clusters and multiple second-type scene primitive clusters corresponding to the scene to be rendered, wherein the multiple first-type scene primitive clusters and multiple second-type scene primitive clusters are mixed and organized in a unified spatial hierarchy structure. Based on the spatial hierarchy, visibility filtering is performed on the multiple first-type scene element clusters and the multiple second-type scene element clusters to obtain a set of surviving clusters. Based on the type label of each cluster in the surviving cluster set, the first type scene primitive cluster in the surviving cluster set is routed to the first type scene primitive rendering path for rendering processing to obtain the first rendering output result, and the second type scene primitive cluster in the surviving cluster set is routed to the second type scene primitive rendering path for rendering processing to obtain the second rendering output result. Based on depth comparison, the first rendering output result and the second rendering output result are fused to obtain the target rendering result.
[0007] On the other hand, embodiments of this application provide a data rendering apparatus, the apparatus comprising: The acquisition unit is used to acquire multiple first-type scene primitive clusters and multiple second-type scene primitive clusters corresponding to the scene to be rendered, wherein the multiple first-type scene primitive clusters and multiple second-type scene primitive clusters are mixed and organized in a unified spatial hierarchy structure. The filtering unit is used to perform visibility filtering processing on the multiple first-type scene element clusters and the multiple second-type scene element clusters based on the spatial hierarchy structure to obtain a set of surviving clusters. The processing unit is configured to, based on the type markers of each cluster in the surviving cluster set, route the first type scene primitive cluster in the surviving cluster set to the first type scene primitive rendering path for rendering processing to obtain a first rendering output result, and route the second type scene primitive cluster in the surviving cluster set to the second type scene primitive rendering path for rendering processing to obtain a second rendering output result. The fusion unit is used to fuse the first rendering output result and the second rendering output result based on depth comparison to obtain the target rendering result.
[0008] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program adapted for loading by a processor to execute the data rendering method as described in any of the above embodiments.
[0009] On the other hand, embodiments of this application provide a computer device, the computer device including a processor and a memory, the memory storing a computer program, the processor executing the data rendering method as described in any of the above embodiments by calling the computer program stored in the memory.
[0010] On the other hand, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the data rendering method as described in any of the above embodiments.
[0011] This application embodiment provides a method for obtaining multiple first-type scene primitive clusters and multiple second-type scene primitive clusters corresponding to a scene to be rendered. The multiple first-type scene primitive clusters and multiple second-type scene primitive clusters are organized in a unified spatial hierarchy. Based on the spatial hierarchy, visibility filtering is performed on the multiple first-type scene primitive clusters and multiple second-type scene primitive clusters to obtain a set of surviving clusters. According to the type label of each cluster in the surviving cluster set, the first-type scene primitive clusters in the surviving cluster set are routed to the first-type scene primitive rendering path for rendering to obtain a first rendering output result, and the second-type scene primitive clusters in the surviving cluster set are... The first type of scene primitive cluster is routed to the second type of scene primitive rendering path for rendering processing to obtain the second rendering output result. Based on depth comparison, the first rendering output result and the second rendering output result are fused to obtain the target rendering result. This data rendering method organizes the first type of scene primitive cluster and the second type of scene primitive cluster in a unified spatial hierarchy structure, and performs visibility filtering processing on different types of clusters based on the spatial hierarchy structure. After filtering, the clusters are routed to the corresponding rendering paths according to the type tags and fused for rendering. This achieves efficient management and on-demand rendering of scene data, reduces rendering resource consumption, and improves resource utilization and real-time rendering performance. Attached Figure Description
[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0013] Figure 1 This is a schematic diagram of the architecture of the data rendering system provided in the embodiments of this application.
[0014] Figure 2 This is a flowchart illustrating the data rendering method provided in an embodiment of this application.
[0015] Figure 3The flowchart shows the overall pipeline architecture of the data rendering method provided in the embodiments of this application.
[0016] Figure 4 This is a schematic diagram illustrating the principle of block-based shared memory sorting and transparency blending in the Gaussian volume rendering path provided in this application embodiment.
[0017] Figure 5 This is a schematic diagram of the structure of the data rendering apparatus provided in the embodiments of this application.
[0018] Figure 6 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation
[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0020] This application provides a data rendering method, apparatus, storage medium, device, and program product. Specifically, the data rendering method of this application can be executed by a computer device, which can be a terminal or a server. The terminal can be a smartphone, tablet, laptop, smart TV, wearable smart device, smart vehicle terminal, etc. The terminal can also include a client, which can be a game client, a 3D engine editor, a digital twin platform, a virtual reality application, a browser client, or a mini-program. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.
[0021] It should be noted that, in this embodiment, the execution entity of the data rendering method can be a terminal device or a server. The terminal device can be a local terminal device or a client device in the aforementioned cloud gaming. This embodiment does not limit the type of execution entity.
[0022] Please see Figure 1The data rendering system provided in this application embodiment includes a terminal 1000, a server 2000, and a network 3000. The terminal 1000 is used to acquire the user's interactive perspective and receive the target rendering results returned by the server 2000 for local display. The server 2000 integrates a CPU and a high-performance GPU, and deploys a virtual geometry data management module and a multi-path hybrid rendering engine. It serves as the core computing entity to execute this method, and the specific process is as follows: First, server 2000 performs data acquisition, grouping the massive amount of second-type scene primitives into a preset fixed number (e.g., 64 at a time) and generating cluster header information. This constructs multiple second-type scene primitive clusters, which are mixed with the first-type scene primitive clusters and organized in a unified spatial hierarchy. Server 2000 performs visibility filtering, using a tree-like spatial hierarchy to perform view frustum pruning, LOD error coarse screening using a unified formula, and hierarchical Z-Buffer (HZB) hardware occlusion culling on both types of clusters. Global joint culling is completed at the top, resulting in a set of surviving clusters. Server 2000 performs data routing, distributing data according to the type labels of the surviving clusters. Second-type scene primitive clusters are written to the second-type scene primitive visibility buffer through atomic counting operations, allowing the computation shader pipeline to stream and execute on-chip shared memory parallel sorting and pixel-by-pixel blending, outputting the second rendering output result. First-type scene primitive clusters are written to the first-type scene primitive visibility buffer for first-type scene primitive rendering, outputting the first rendering output result.
[0023] Server 2000 performs image fusion, comparing the depth of each pixel across the entire screen. If the depth value of the second rendering output is smaller, the color of the second rendering output is overlaid with a semi-transparent layer. If the depth value of the first rendering output is smaller or equal, the color of the first rendering output is overwritten and fused into the target rendering result, which is then transmitted back to terminal 1000 via network 3000 for refresh and display.
[0024] Please see Figure 2 , Figure 2 This is a flowchart illustrating a data rendering method provided in an embodiment of this application. The method may include the following steps: Step 110: Obtain multiple first-type scene primitive clusters and multiple second-type scene primitive clusters corresponding to the scene to be rendered, wherein the multiple first-type scene primitive clusters and multiple second-type scene primitive clusters are mixed and organized in a unified spatial hierarchy structure.
[0025] Step 110 is used to construct the data infrastructure suitable for subsequent unified visibility management and hybrid rendering. In traditional rendering schemes, different types of scene graph data (e.g., first-type scene graph data as a first-type scene graph primitive and second-type scene graph data as a second-type scene graph primitive) are usually managed using different data organization methods. This results in the two types of data relying on different loading, scheduling, and visibility processing flows, thereby increasing system management complexity and runtime overhead. To address this, this embodiment organizes the first-type scene graph primitive cluster and the second-type scene graph primitive cluster together in a unified spatial hierarchy structure, enabling the two different rendering primitives to be managed under the same data organization framework. This provides a foundation for subsequent unified execution of instance-level filtering, layer expansion, detail-level selection, and occlusion culling.
[0026] The spatial hierarchy can be a hierarchical organizational model with parent-child node relationships. Specifically, the spatial hierarchy can be a Bounding Volume Hierarchy (BVH), an octree, a KD-Tree, or other data structures capable of expressing spatial hierarchical relationships. In this embodiment, a BVH structure is used for illustration, but this does not constitute a limitation on the scope of protection of this application.
[0027] A first-type scene primitive cluster is a data organization unit used to describe a first primitive representation. In one exemplary embodiment, the first primitive representation includes geometric mesh data. More specifically, a first-type scene primitive cluster can represent the smallest rendering management unit composed of multiple first-type scene primitives (such as triangle primitives or other rigid geometric primitives). For example, a first-type scene primitive cluster can contain a preset fixed number of first-type scene primitives, such as 64 triangles.
[0028] A second-type scene primitive cluster is a data organization unit used to describe a second primitive representation. In one exemplary embodiment, the second primitive representation includes Gaussian splash data. More specifically, a second-type scene primitive cluster can represent the smallest management unit composed of multiple second-type scene primitives (such as a three-dimensional Gaussian ellipsoid, a two-dimensional Gaussian circular patch, or other continuous spatial probability distribution models). For example, a second-type scene primitive cluster can contain a preset fixed number of second-type scene primitives, such as 64 second-type scene primitives.
[0029] It should be noted that the "cluster" in this application embodiment is not limited to a fixed number of data objects, but rather refers to a data management unit capable of participating in spatial organization, visibility management, and rendering scheduling. In different implementations, the number of data objects contained in each cluster can be adjusted according to hardware performance, video memory capacity, rendering target precision, or real-time requirements.
[0030] In some embodiments, before obtaining the multiple second-type scene primitive clusters and multiple first-type scene primitive clusters corresponding to the scene to be rendered, the method further includes: Step 001: Group the second type of scene primitives in the scene to be rendered into a fixed number of groups to obtain multiple second type scene primitive clusters.
[0031] In some embodiments, the second type of scene primitive is a continuous spatial probability distribution model that can use the center position, scale parameter, and rotation parameter to describe the volume contribution range in space.
[0032] For example, for a certain area of leaves in a scene, multiple second-type scene primitives can be used to describe the color changes and spatial shape of the leaf surface; for complex and detailed objects such as grass, flowers, and shrubs, a large number of second-type scene primitives (such as Gaussian volumes) can also be used to express them.
[0033] In one embodiment, the system first obtains a complete set of second-type scene primitives in the scene to be rendered.
[0034] If the current scene contains 2 million second-type scene primitives, they can be divided according to a preset fixed number.
[0035] For example, if the scene to be rendered contains 2 million second-type scene primitives (such as Gaussian volume), and every 64 second-type scene primitives form a second-type scene primitive cluster, then approximately 31,250 second-type scene primitive clusters will be generated in the end.
[0036] Step 002: For each second type of scene primitive cluster, generate cluster header information containing spatial bounding boxes, error measurement information and type labels. The cluster header information of the second type of scene primitive cluster adopts the same data structure as the cluster header information of multiple first type scene primitive clusters.
[0037] A spatial bounding box is a geometric boundary used to approximate the extent of a space, and can be used to quickly perform spatial intersection tests, frustum detection, and occlusion determination.
[0038] Error metric information is used to support subsequent detail level selection processing. Specifically, for the second type of scene primitive cluster, this error metric information can represent the primitive aggregation visual deviation generated when multiple fine-grained second-type scene primitives are merged into a coarser-grained second-type scene primitive. In a specific embodiment provided in this application, it can be manifested as the visual displacement deviation generated when multiple fine-grained Gaussian volumes are merged into a coarser-grained Gaussian volume.
[0039] For example: the first layer of LOD contains 1024 Gaussian volumes; the second layer of LOD contains 256 Gaussian volumes; the system calculates the maximum visual deviation distance between the two layers of LOD and records it as an error metric in the cluster header.
[0040] In this embodiment, the header information of the second type of scene element cluster uses the same data structure as the header information of the first type of scene element cluster.
[0041] Because the header format remains consistent, subsequent spatial hierarchy structures do not need to distinguish whether the current node corresponds to the first type of scene primitive cluster or the second type of scene primitive cluster, and can uniformly perform hierarchical organization and visibility management.
[0042] Step 003: Store the second-type scene graph data of each second-type scene graph cluster in the same data organization format as the multiple first-type scene graph clusters, so that the two types of clusters can share the same set of streaming data loading and page replacement management mechanism.
[0043] Step 003 is used to achieve unified management of the second type of scene graph data and the first type of scene graph data in the underlying storage structure.
[0044] The data organization format specifies how cluster data is arranged and accessed in the storage medium. In some embodiments, a page-based storage structure may be used.
[0045] Streaming data loading is a resource management mechanism that loads data on demand, dynamically loading the required data based on the current viewpoint. More specifically, it can load only the data pages corresponding to the visible area of the current frame. Page eviction management is used to reclaim data pages that are no longer needed in the current frame; specifically, it can employ a least recently used strategy, a frequency-based access strategy, or other cache replacement strategies.
[0046] In one embodiment, both the second type of scene element cluster and the first type of scene element cluster are stored using a unified page format.
[0047] For example: each page is 128KB in size; a page can store data from multiple clusters; the page header records the page number, the length of valid data, and access status information; the page body stores the specific cluster content.
[0048] For pages containing second-type scene primitives, the page body records the position parameters, scale parameters, rotation parameters, color parameters, and transparency parameters of the second-type scene primitives (such as data parameters used to represent a three-dimensional Gaussian ellipsoid); for pages containing first-type scene primitives, the page body records the geometric topology and surface attribute data of the first-type scene primitives (such as triangle vertex data, normal data, and texture coordinate data).
[0049] In some embodiments, each Type II scene primitive is stored using a compact 32-byte encoding format: position parameters are stored in half-precision floating-point (FP16) format, occupying 6 bytes; scale parameters are stored in half-precision floating-point (FP16) format, occupying 6 bytes; rotation parameters are stored in quantized quaternion format, occupying 4 bytes; color and transparency parameters are stored in 8-bit integer format, occupying 4 bytes; the remaining 12 bytes are reserved for alignment padding and future expansion to ensure efficient memory alignment access of page data. After deducting the overhead of page header metadata, a 128KB streaming page can accommodate approximately 60 Type II scene primitive clusters (equivalent to approximately 3840 Gaussian volumes in one example). This compact encoding format significantly reduces the memory footprint of a single Type II scene primitive (such as a Gaussian volume) while maintaining rendering accuracy, thereby improving the data density and loading efficiency of the streaming page.
[0050] Although the internal data content of the two types of pages is different, their page structure, page indexing method and loading method are consistent. Therefore, the streaming loading system does not need to design a new resource management module for the second type of scene graph data.
[0051] For example, when the camera moves to an urban scene, the system can simultaneously load the first type of scene primitive page corresponding to the first scene object (such as a building) and the second type of scene primitive page corresponding to the second scene object (such as trees and vegetation) within the current field of view; when the camera leaves the area, the corresponding pages are marked as ready for elimination and the video memory resources are released according to the page elimination policy.
[0052] Through steps 001 to 003, the second type of scene primitive cluster can be made consistent with the first type of scene primitive cluster in terms of data organization, header structure, and storage management method. This provides the foundation for building a unified spatial hierarchy structure and performing unified visibility filtering processing, and ultimately achieves unified management and collaborative rendering of different rendering primitives.
[0053] Step 120: Based on the spatial hierarchy, perform visibility filtering on multiple first-type scene primitive clusters and multiple second-type scene primitive clusters to obtain a set of surviving clusters.
[0054] Step 120 is used to perform unified visibility judgment and filtering on the first type of scene primitive cluster and the second type of scene primitive cluster in a unified spatial hierarchy structure, so as to filter out the cluster set that actually needs to participate in the subsequent rendering calculation of the current rendering frame from the full scene data, that is, the live cluster set.
[0055] Visibility filtering is a filtering mechanism used to determine whether a spatial object participates in the rendering of the current frame.
[0056] In some embodiments, visibility filtering may include initial culling based on the frustum extent, fine-grained culling based on spatial hierarchy, and occlusion culling based on depth information.
[0057] In some embodiments, the spatial hierarchy is distributed in a tree-like hierarchical manner. Based on the spatial hierarchy, visibility filtering is performed on multiple first-type scene primitive clusters and multiple second-type scene primitive clusters to obtain a set of surviving clusters, including: Step 121: Perform field-of-view detection on the instances to be rendered in the scene to be rendered, exclude rendering instances that are outside the field of view of the current frame, and obtain a set of surviving instances within the field of view.
[0058] An instance to be rendered represents an object unit in the scene that can independently participate in rendering management; it is a higher-level organizational unit containing multiple clusters. Specifically, an instance to be rendered can correspond to a character model, a building, or a group of vegetation areas.
[0059] Field of view detection is used to determine whether a spatial object is within the camera's visible area. Specifically, field of view detection is based on the intersection relationship between the camera's view frustum and the object's bounding box. The view frustum can be formed by the near plane, the far plane, and the left, right, top, and bottom clipping planes.
[0060] In one embodiment, the system obtains the camera parameters of the current frame, constructs a view frustum model, and then performs intersection detection on the spatial bounding boxes of all instances to be rendered in the scene.
[0061] For example, instances located behind the camera are directly discarded; instances located outside the view frustum are directly discarded; instances located inside the view frustum or intersecting with the view frustum proceed to the next stage of processing.
[0062] Through the above processing, the original full set of instances is compressed into a set of surviving instances within the field of view.
[0063] For example, in an open-world city scenario, if the original number of instances is 1000, of which about 950 are outside the current field of view, then only about 50 instances will be available for subsequent processing.
[0064] Step 122: For each surviving instance in the set of surviving instances within the field of view, traverse each node belonging to the surviving instance in the spatial hierarchy from top to bottom. If the screen projection error value of the target node under the current rendering view is lower than the preset pixel threshold, stop expanding downwards and take the cluster under the jurisdiction of the target node as a candidate cluster to obtain a set of candidate clusters.
[0065] This step is used to perform the second stage of hierarchical refinement control, namely, LOD-based adaptive refinement selection.
[0066] Top-down traversal is a method of accessing a spatial hierarchy by recursively expanding from the root node to its child nodes, used to determine at each level whether the current node needs to be further subdivided.
[0067] Screen projection error is a metric used to characterize the approximate error of a spatial object in the current screen space. It can reflect the maximum deviation of the current node's geometry or volume data from the final screen pixels after simplification.
[0068] In some embodiments, the screen projection error value is expressed in pixels.
[0069] Specifically, for each surviving instance, the traversal begins from the root node of its corresponding spatial hierarchy: If the area corresponding to the current node is large, then continue to subdivide it into child nodes; If the screen projection error corresponding to the current node is already less than the preset pixel threshold, then stop expanding. The cluster corresponding to the current node will be output as a candidate cluster.
[0070] For example, when distant buildings are far away, their high-level nodes only occupy 1 to 2 pixels on the screen. Therefore, there is no need to continue expanding to the finest-grained triangle or Gaussian volume level. Instead, the current cluster is directly used as the candidate cluster.
[0071] This process avoids excessive subdivision of distant or low-impact areas, thereby reducing the overall computational load.
[0072] In some embodiments, the calculation step of the screen projection error value of the target node under the current rendering view includes: Step 1221: Obtain the error measurement information corresponding to the target node. For the first type of scene primitive cluster node, the error measurement information is geometric simplification deviation. For the second type of scene primitive cluster node, the error measurement information is primitive aggregation visual deviation.
[0073] Among them, geometric simplification deviation is used to characterize the deformation error generated after simplification of the first type of scene primitives (for example, it can be specifically represented as the geometric deformation error generated after the simplification of triangles); primitive aggregation visual deviation is used to characterize the visual deviation generated after the aggregation of multiple second type of scene primitives (for example, it can be specifically represented as the visual center shift error generated after the merging of multiple Gaussian volumes).
[0074] Step 1222: Convert the error measurement information into a projection size in units of screen pixels according to the projection parameters of the current rendering view, and obtain the screen projection error value of the target node in the current rendering view. The same conversion formula is used for the first type of scene primitive cluster node and the second type of scene primitive cluster node.
[0075] Step 1222 is used to map the three-dimensional spatial error to the two-dimensional screen space.
[0076] Among them, projection parameters are a set of transformation parameters used to convert three-dimensional spatial coordinates into two-dimensional screen coordinates, which may include parameters such as field of view, projection matrix, and screen resolution.
[0077] Step 123: For each candidate cluster in the candidate cluster set, project the spatial bounding box of the current candidate cluster onto the hierarchical depth buffer generated by the previous frame rendering. If the spatial bounding box is completely occluded by the depth information recorded in the hierarchical depth buffer generated by the previous frame rendering in the current rendering view, then remove the current candidate cluster to filter and obtain the set of surviving clusters.
[0078] Step 123 is used to perform the third stage of occlusion culling, which is to perform visibility cropping based on historical depth information.
[0079] Among them, the hierarchical depth buffer is a data structure used to record the spatial depth information of the previous frame or the current frame, such as HZB.
[0080] For example, if a cluster of second-type scene primitives corresponding to a second scene object (such as vegetation) is located behind a first scene object (such as a building), and its bounding box is covered by the depth buffer after being projected into screen space, then this cluster does not need to participate in subsequent rendering calculations.
[0081] The above processing can effectively remove invisible clusters, thereby reducing the amount of data processing in subsequent rendering stages.
[0082] Through the step-by-step filtering process from step 121 to step 123, this embodiment realizes a three-level visibility filtering process from "instance-level frustum culling to hierarchical LOD control and then to depth occlusion culling". Under the unified spatial hierarchy structure, the first type of scene primitive cluster and the second type of scene primitive cluster are processed in a consistent manner, thereby obtaining a set of surviving clusters for subsequent rendering, providing an input basis for subsequent type routing and multi-path rendering.
[0083] In one embodiment, taking a scene with 2 million second-type scene primitives (such as Gaussian bodies) as an example, after completing the above three-level visibility filtering, the number of second-type scene primitives surviving to participate in subsequent rendering processing is approximately 179,000, and the cumulative compression ratio of the three-level filtering is approximately 11 times. This compression effect makes the on-chip shared memory sorting scheme in the subsequent second-type scene primitive rendering path feasible: compared to the approximately 720MB global sorting memory bandwidth consumption generated by the conventional pipeline without filtering, this bandwidth consumption is reduced to zero bytes after filtering; the dedicated GPU global video memory required for sorting is reduced from approximately 160MB to zero bytes; and the number of GPU scheduling times is reduced from 7 to 9 times to 1 time. It can be seen that the three-level visibility filtering processing provided in this application embodiment not only reduces the computational overhead of the rendering stage, but also fundamentally creates the preconditions for adopting an on-chip sorting scheme in the backend second-type scene primitive rendering path.
[0084] Step 130: Based on the type label of each cluster in the surviving cluster set, route the first type scene primitive cluster in the surviving cluster set to the first type scene primitive rendering path for rendering processing to obtain the first rendering output result, and route the second type scene primitive cluster in the surviving cluster set to the second type scene primitive rendering path for rendering processing to obtain the second rendering output result.
[0085] Step 130 is used to perform differentiated path distribution processing on different types of clusters in the surviving cluster set after the unified visibility filtering is completed, so that the second type of scene primitive clusters and the first type of scene primitive clusters enter their respective rendering execution channels, thereby achieving type separation and parallel execution of downstream rendering processing while maintaining unified upstream filtering logic.
[0086] In some embodiments, based on the type markers of each cluster in the surviving cluster set, routing a first-type scene primitive cluster in the surviving cluster set to a first-type scene primitive rendering path, and routing a second-type scene primitive cluster in the surviving cluster set to a second-type scene primitive rendering path, includes: Step 01: For any surviving cluster in the surviving cluster set, read the type flag of the surviving cluster.
[0087] For example: if the type is marked as "0", it means that the current cluster is a first-type scene primitive cluster; If the type is marked as "1", it means that the current cluster is a second type of scene element cluster.
[0088] Step 02: When the type flag indicates that the surviving cluster is a second type scene primitive cluster, the incremental write position is obtained through lock-free parallel write operation, and the index information of the surviving cluster is written into the write position of the second type scene primitive visible buffer, so that the second type scene primitive rendering path can read the index information in the second type scene primitive visible buffer and perform subsequent second type scene primitive rendering.
[0089] The second type of scene primitive visible buffer is used to store the index information of the second type of scene primitive cluster visible in the current frame, and is used as the source of input data for the second type of scene primitive rendering path.
[0090] Lock-free parallel write operation is a concurrent write mechanism based on atomic counters, used to avoid data write conflicts during multi-threaded parallel execution. Specifically, it obtains a unique write position through atomic increment.
[0091] Type II scene primitive rendering is an attribute accumulation rendering mechanism designed for primitives with spatially continuous probability distributions, volumetric density representations, or semi-transparent features. Unlike Type I scene primitive rendering (such as solid mesh rasterization) which relies on depth testing for direct occlusion coverage, the core of Type II scene primitive rendering lies in achieving pixel-by-pixel adaptive accumulation of scene radiation field, color, and opacity attributes through the ordered arrangement and transparency blending of primitives in screen space.
[0092] In one exemplary implementation, the rendering of the second type of scene primitives can be achieved by projecting the second type of scene primitives (such as a three-dimensional Gaussian ellipsoid) onto the screen space and performing on-chip local high-speed bitonetic sorting and layer-by-layer transparency decay synthesis (i.e., Gaussian splash real-time rendering pipeline) based on the screen tile regions, thereby efficiently outputting a second rendering result containing semi-transparent scene representation.
[0093] In one embodiment, when the current cluster is detected to be a second type of scene primitive cluster, the following operations are performed: an increment operation is performed by an atomic counter; the current write index position is obtained; and the index information corresponding to the second type of scene primitive cluster is written into the second type of scene primitive visible buffer.
[0094] For example, if 1200 second-type scene primitive clusters have already been written to the buffer, and a thread obtains index 1201 after performing atomic increment, then the write position of this second-type scene primitive cluster is slot 1201.
[0095] The above method enables conflict-free parallel distribution of the second type of scene primitive cluster to the second type of scene primitive rendering path.
[0096] Step 03: When the type flag indicates that the surviving cluster is a first type scene primitive cluster, the index information of the surviving cluster is written into the first type scene primitive visible buffer so that the first type scene primitive rendering path can read the index information in the first type scene primitive visible buffer and perform subsequent first type scene primitive rendering.
[0097] The first type of scene primitive visibility buffer is used to store the index information of the first type of scene primitive clusters visible in the current frame, which is used as input to the first type of scene primitive rendering path. In one exemplary embodiment, the first type of scene primitive rendering path can specifically correspond to a traditional rasterization rendering pipeline. More specifically, the first type of scene primitive visibility buffer records the index position of the first type of scene primitive cluster (in one example, it can specifically be represented as a triangle cluster or other rigid geometric primitive cluster) in the spatial hierarchy.
[0098] In some embodiments, routing the second type of scene primitive cluster in the surviving cluster set to the second type of scene primitive rendering path for rendering processing to obtain a second rendering output result includes: Route the second type of scene primitive cluster in the surviving cluster set to the second type of scene primitive rendering path; In the second type of scene primitive rendering path, local sorting and image composition are performed based on the screen block regions to obtain the second rendering output result.
[0099] In some embodiments, local sorting and image composition are performed based on screen block regions in the second type of scene primitive rendering path to obtain a second rendering output result, including: Step 04: Project each second-type scene primitive routed to the second-type scene primitive rendering path onto the screen space to construct a set of second-type scene primitive entries corresponding to each screen block area. The set of second-type scene primitive entries contains the depth information of the second-type scene primitives. Step 04 is used to expand the index information in the visible buffer of the second type of scene primitives at the cluster level into screen space projection parameters at the individual second type of scene primitives. According to the coverage position of each second type of scene primitive (in one example, it can be represented as each three-dimensional Gaussian ellipsoid) on the screen, its depth information and index information are assigned to the associated screen block regions, providing structured input data for the subsequent local sorting of screen block regions and image compositing steps.
[0100] Among them, the screen block area is a computing unit formed by dividing the screen space according to a preset pixel size. Each screen block area can correspond to a GPU thread group execution unit.
[0101] In one embodiment, the screen block area size is 16×16 pixels or 32×32 pixels.
[0102] In some embodiments, each second-type scene primitive routed to the second-type scene primitive rendering path is projected onto the screen space to construct a set of second-type scene primitive entries corresponding to each screen block region, including: Step 041: Traverse the index information of each second-type scene element cluster in the visible buffer of the second-type scene element to read the attribute parameters of each second-type scene element in the second-type scene element cluster.
[0103] In some embodiments, the attribute parameters may include spatial location parameters, scale parameters, and rotational morphology parameters.
[0104] Step 042: Project the attribute parameters of each second type of scene primitive to the screen space to determine the screen coordinates, screen coverage area and depth value of each second type of scene primitive.
[0105] In some embodiments, step 042 uses a perspective projection matrix to convert the ellipsoidal shape parameters in three-dimensional space into a geometric footprint in two-dimensional screen space, i.e., which screen tile regions it can cover.
[0106] Step 043: Based on the screen coordinates and screen coverage of each second-type scene element, assign the depth value and index information of each second-type scene element to one or more associated screen block regions to obtain a set of second-type scene element entries corresponding to each screen block region.
[0107] Step 05: For each screen block area, in the shared memory corresponding to the associated thread group, perform depth sorting and image composition on the set of second-type scene primitive entries based on the depth information of the second-type scene primitives to obtain the pixel color output of the screen block area, which is used as the second rendering output result.
[0108] Step 05 is the core execution step of local sorting and image composition of screen block areas in the technical solution of this application.
[0109] Specifically, step 05 uses GPU thread groups as the scheduling unit, replacing the multiple rounds of radix sorting that originally needed to be executed on global memory with parallel sorting of screen block regions executed in on-chip shared memory (for example, parallel sorting algorithms such as bitone sort), and combining sorting and transparency into a single GPU shader scheduling, so as to completely eliminate global memory access overhead and multiple scheduling startup delays.
[0110] In some embodiments, for each screen block region, within the shared memory corresponding to the associated thread group, the set of second-type scene primitive entries is depth-sorted and composited based on the second-type scene primitive depth information to obtain the pixel color output of the screen block region, including: Step 051: For each screen block area, read all second-type scene primitive entries covering the screen block area from global storage into the shared memory corresponding to the associated thread group.
[0111] Step 051 is used to implement localized loading of data at the screen block region level, so that subsequent sorting and synthesis calculations can be completed in the GPU's high-speed storage structure, thereby reducing the global video memory access overhead.
[0112] The second type of scene primitive entry is a data structure used to describe the projection result of the second type of scene primitive in screen space; further, it includes at least the second type of scene primitive index information, screen space depth value, and coverage pixel range information.
[0113] For example, if a certain screen block area contains 120 second-type scene primitive entries (e.g., Gaussian volume entries), then these 120 entries will be loaded into shared memory at once for subsequent processing.
[0114] In some embodiments, the shared memory is configured with a maximum budget of 512 second-type scene primitive entries per screen tile region. In most screen tile regions, the actual number of entries is lower than this budget limit, and all entries can be read into shared memory at once for subsequent processing, consuming zero bytes of global video memory bandwidth. In a few screen tile regions where second-type scene primitives are extremely densely distributed, the number of second-type scene primitive entries may exceed the shared memory capacity budget. In this case, the excess portion overflows into a temporary buffer in global video memory for independent sorting, and then is merged with the sorted entries in shared memory according to depth values to obtain a complete sequence of entries for subsequent transparency blending. This overflow merging path is triggered only in a very small number of screen tile regions and does not affect the zero global video memory sorting advantage of the vast majority of screen tile regions.
[0115] Step 052: In shared memory, perform parallel sorting on each second type scene primitive entry according to the second type scene primitive depth information to obtain an entry sequence.
[0116] The second type of scene primitive depth information is the projection depth of the second type of scene primitive from the observer's current camera viewpoint, which is used to characterize the front and back occlusion relationship of the second type of scene primitive in screen space.
[0117] In some embodiments, the execution process of step 052 includes: constructing a second type of scene primitive entry array structure in shared memory; sorting the entries in the array according to the second type of scene primitive depth information field using a parallel sorting algorithm; and outputting the entry sequence arranged from near to far according to the second type of scene primitive depth information.
[0118] For example: the depth set of entries before sorting is: 2.8, 1.2, 4.5; the sequence of entries after sorting is: 1.2 → 2.8 → 4.5.
[0119] The above method enables the ordered processing of second-type scene primitive entries within the local computational domain.
[0120] Step 053: Perform transparency blending on each pixel in the screen block area layer by layer according to the order of the item sequence from near to far to obtain the pixel color output of the screen block area; wherein, depth sorting and transparency blending are completed sequentially in a single rendering call.
[0121] In some embodiments, transparency blending is performed layer by layer on each pixel within a screen block area to obtain the pixel color output of the screen block area, including: Step 0531: Initialize the cumulative transmittance of each pixel in the screen block area to a preset initial value that represents the complete transmission of background light.
[0122] Cumulative transmittance is a physical quantity that characterizes how much background light is still allowed to pass through the current pixel, and its value ranges from 0 to 1. Specifically, a value of 1 indicates complete transparency, and a value of 0 indicates complete opacity.
[0123] In some embodiments, the transmittance T = 1.0 is initialized for each pixel in the screen block area, and the pixel color accumulation value is initialized to the background color or zero vector to provide an initial state for subsequent layer-by-layer blending calculations.
[0124] Step 0532: For the second type scene primitive entry currently traversed in the entry sequence, obtain the projection opacity of the second type scene primitive corresponding to each pixel in the screen block area.
[0125] Step 0533: For each pixel in the screen block area, calculate the remaining light transmittance using the projection opacity of the pixel, and use the remaining light transmittance to attenuate the current cumulative transmittance of the pixel based on the multiplication rule.
[0126] Residual light transmittance is the influence of the current Gaussian layer on the light transmission capacity, and it satisfies a complementary relationship with opacity.
[0127] Step 0534: When the cumulative transmittance of a pixel is lower than the preset opacity threshold, stop processing subsequent second-type scene primitive entries for the pixel and output the current cumulative color as the pixel color of the pixel in the screen block area.
[0128] The preset opacity threshold is used to control the threshold for determining the stopping condition of transparency composition, and is used to avoid continuing to perform subsequent second-type scene primitive calculations on pixels that are completely occluded. In some embodiments, the preset opacity threshold can be set to a small value such as 0.05 or 0.01.
[0129] Step 140: Based on depth comparison, the first rendering output result and the second rendering output result are fused to obtain the target rendering result.
[0130] The second rendering output is a set of screen-space pixel color and depth information output from the rendering path of the second type of scene primitives. In some embodiments, it represents the semi-transparent contribution of the second type of scene primitives (such as a three-dimensional Gaussian ellipsoid) in screen space.
[0131] Specifically, the second rendering output includes the color value and depth value corresponding to each pixel.
[0132] The first rendering output result is the rendering result output by the rendering path of the first type of scene primitives. In some embodiments, it can specifically be represented as the rendering result of the visible surface mesh of the first type of scene primitives (such as traditional geometric primitives or triangles) in screen space (such as rasterization result).
[0133] The second rendering output also includes the color value and depth value corresponding to each pixel.
[0134] In some embodiments, based on depth comparison, the first rendering output result and the second rendering output result are fused to obtain the target rendering result, including: Step 141: Obtain the first depth value and first color information of the first rendering output result at each pixel, and obtain the second depth value and second color information of the second rendering output result at each pixel.
[0135] Step 142: For any pixel, when the corresponding second depth value is less than the corresponding first depth value, the corresponding second color information is superimposed onto the pixel of the target rendering result.
[0136] Step 142 is used to determine at the pixel level whether the rendering result of the second type of scene primitives is located before the rendering result of the first type of scene primitives, and to fuse the color contribution of the second type of scene primitives into the final image when the preconditions are met.
[0137] In some embodiments, when the second type of scene primitive is a Gaussian volume and the first type of scene primitive is a geometric primitive, superimposing the corresponding second color information onto the pixels of the target rendering result is equivalent to superimposing the color information of the Gaussian volume onto the pixels of the target rendering result.
[0138] Overlay is a process of semi-transparently blending a second color information with the current canvas target output buffer, indicating that the second type of scene primitive (such as a Gaussian volume) has a higher visibility at that pixel compared to the observer. In some embodiments, overlay can employ alpha blending or pre-multiplied alpha synthesis.
[0139] Step 143: When the corresponding first depth value is less than or equal to the corresponding second depth value, write the corresponding first color information into the pixels of the target rendering result.
[0140] Step 143 is used to write the rendering result of the first type of scene primitive as the final visible result when the first type of scene primitive is located before or at the same depth level as the second type of scene primitive.
[0141] Writing refers to directly assigning or overwriting the corresponding color value to the target rendering buffer, indicating that the pixel is ultimately displayed by the first type of scene primitive rendering path.
[0142] All of the above technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.
[0143] This application embodiment provides a method for obtaining multiple first-type scene primitive clusters and multiple second-type scene primitive clusters corresponding to a scene to be rendered. The multiple first-type scene primitive clusters and multiple second-type scene primitive clusters are organized in a unified spatial hierarchy. Based on the spatial hierarchy, visibility filtering is performed on the multiple first-type scene primitive clusters and multiple second-type scene primitive clusters to obtain a set of surviving clusters. According to the type label of each cluster in the surviving cluster set, the first-type scene primitive clusters in the surviving cluster set are routed to the first-type scene primitive rendering path for rendering to obtain a first rendering output result, and the second-type scene primitive clusters in the surviving cluster set are... The first type of scene primitive cluster is routed to the second type of scene primitive rendering path for rendering processing to obtain the second rendering output result. Based on depth comparison, the first rendering output result and the second rendering output result are fused to obtain the target rendering result. This data rendering method organizes the first type of scene primitive cluster and the second type of scene primitive cluster in a unified spatial hierarchy structure, and performs visibility filtering processing on different types of clusters based on the spatial hierarchy structure. After filtering, the clusters are routed to the corresponding rendering paths according to the type tags and fused for rendering. This achieves efficient management and on-demand rendering of scene data, reduces rendering resource consumption, and improves resource utilization and real-time rendering performance.
[0144] The following section will continue to introduce the solution, taking the first type of scene primitives as geometric primitives (such as mesh triangles) and the second type of scene primitives as Gaussian bodies (such as three-dimensional Gaussian ellipsoids) as examples.
[0145] Please see Figure 3 , Figure 3 This is a flowchart illustrating the overall pipeline architecture of the data rendering method provided in this application embodiment. The entire rendering pipeline adopts a unified hybrid nested organizational architecture in its underlying topology management. Massive clusters of geometric primitives (such as triangle clusters) and Gaussian volume clusters are hybridized within a unified spatial hierarchy, thereby enabling the upstream GPU driver culling mechanism. The execution logic of the entire pipeline can be specifically divided into the following three stages: The first phase is the GPU-driven culling phase of the shared Virtual Geometry (VG). In this phase, the graphics processing unit (GPU) of the server or terminal uses a unified spatial hierarchy to jointly perform a three-level cascaded visibility filtering process on the two types of clusters in the hybrid organization.
[0146] The first level is instance-level field of view detection: all instances to be rendered in the scene to be rendered are subjected to view frustum boundary intersection detection, which directly excludes about 95% of invalid rendering instances that are outside the field of view of the current frame, and filters out the set of surviving instances within the field of view.
[0147] The second level is node-level spatial hierarchy filtering: For surviving instances, the nodes of each level belonging to the instance are traversed from top to bottom. Based on the screen space projection error conversion formula of the two types of cluster nodes, multi-detail level selection is performed, compressing the tree topology structure by about 7 times, and locking the candidate cluster set when the error is lower than the pixel threshold.
[0148] The third stage is cluster-level occlusion culling: the spatial bounding boxes of each candidate cluster are projected onto the hierarchical depth buffer generated by the previous frame's rendering, and hardware culling logic is used to filter out occluded clusters, achieving a cumulative data compression of approximately 11 times, ultimately refining a high-purity set of surviving clusters. Because this stage achieves global joint culling at the upstream level, it greatly frees up the pipeline computing power in the backend.
[0149] The aforementioned three-level visibility filtering process enables the implementation of the on-chip shared memory sorting scheme in the subsequent Gaussian volume rendering path. In a standard rendering pipeline without visibility filtering, each screen block region contains an average of approximately 2450 Gaussian volume entries; existing GPU on-chip shared memory is typically 32KB to 48KB, which, calculated at 8 bytes per entry, can only accommodate approximately 512 entries. When the scene scale expands to 75 million Gaussian volumes, the number of Gaussian volume entries in each screen block region can exceed 9000, far exceeding the capacity limit of GPU on-chip shared memory. It is the cumulative compression of approximately 11 times achieved by the three-level visibility filtering in this application (of which node-level LOD layer filtering contributes approximately 7 times compression, and instance-level frustum detection and cluster-level occlusion culling contribute a combined approximately 1.6 times compression) that reduces the average number of Gaussian volume entries in each screen block region to approximately 110, making the on-chip shared memory sorting scheme a technically feasible solution. The cascading enabling relationship between upstream data compression and downstream algorithm changes makes the solution in this application different from simple sorting algorithm optimization or simple elimination optimization, and achieves synergistic gains between the two technical features of visibility filtering and on-chip sorting.
[0150] The second phase is the routing and path-based rendering phase based on type tags. After the pipeline completes unified culling, it enters the branching point, where the rendering engine reads the type tags of each cluster in the set of surviving clusters.
[0151] When the type flag indicates that the currently active cluster is a geometry primitive cluster, the system writes the index information of the cluster into the geometry primitive visible buffer, routes it to the geometry primitive rendering path, and through traditional virtual geometry pipelines such as rasterization silos and hardware / software rasterization, finally outputs the first rendering output result containing the depth and color of the opaque surface.
[0152] When the type flag indicates that the currently surviving cluster is a Gaussian volume cluster, the system obtains a unique safe write location through atomic counting operations, writes the cluster's index information to the Gaussian volume visible buffer, and routes it to the Gaussian volume rendering path added in this application. In the Gaussian volume rendering path, the visible Gaussian volume data is first streamed through the computation shader and screen-space perspective projection is performed. Then, the dedicated Gaussian computation shader is called to complete on-chip parallel bitonetic sorting and pixel-by-pixel transparency blending in the shared memory corresponding to the associated thread group, and then renders the second rendering output result of the Gaussian path.
[0153] The third stage is the deep fusion stage of multi-path rendering output. The fusion pipeline ultimately calls the depth-aware compositing computation shader to obtain the first depth value and first color information of the first rendering output at each pixel, as well as the second depth value and second color information of the second rendering output at each pixel, in parallel at the pixel level. By performing a pixel-by-pixel precise depth comparison, the nearest element is selected for display: when the second depth value of the second rendering output at the current pixel is smaller, it means that the semi-transparent Gaussian volume is closer to the camera than the solid geometric mesh, and the system superimposes the corresponding second color information (i.e., Gaussian volume color information) onto the corresponding pixel; conversely, when the first depth value of the first rendering output at the current pixel is smaller or equal, it means that the traditional geometric mesh is located before or at the same depth level as the Gaussian volume, and the solid part completely occludes it, and the system directly writes the corresponding first color information (i.e., geometric mesh color information) and overwrites the corresponding current pixel, thereby seamlessly fusing the semi-transparent Gaussian representation and the solid rigid mesh into a high-fidelity target rendering result, and ultimately achieving a unified image output.
[0154] The following section continues to use the second type of scene primitives as a Gaussian volume as an example to introduce the specific implementation process of the second type of scene primitive rendering path (i.e., Gaussian volume rendering path).
[0155] Please see Figure 4 , Figure 4 This is a schematic diagram illustrating the principle of block-based shared memory sorting and transparency blending in the Gaussian volume rendering path provided in this application embodiment.
[0156] To eliminate the extremely high global sorting bandwidth throughput, excessive memory usage, and frequent hardware global synchronization barrier delays caused by conventional 3D Gaussian global memory sorting pipelines when dealing with massive Gaussian volumes, this application adopts an on-chip high-speed adaptive parallel rendering mechanism based on compute shader drivers. The entire process uses a single associated thread group (in this embodiment, a 16×16 pixel array is used as the screen block area, corresponding to 256 hardware concurrent threads) as an independent computational unit with physical spatial isolation. The entire process is executed within on-chip shared memory, thus achieving single compute shader scheduling with zero external global memory bandwidth consumption and zero sorting buffer memory usage. Specifically, it includes the following four core execution steps: Step 1: Data Reading and Chunk Entry Collection. The associated thread group scans in parallel the visible Gaussian cluster data generated by the upstream projection module, covering the current screen chunk area. Each thread concurrently reads the corresponding index and attribute, and reads the second-type scene primitive depth information (specifically corresponding to Gaussian volume depth) and index information of all Gaussian volume entries covering the current screen chunk area from the high-latency global memory into the corresponding on-chip local shared memory in a single batch.
[0157] Step Two: On-chip Bi-tune Parallel Sorting Processing. In the on-chip local shared memory, 256 concurrent hardware threads collaboratively perform high-speed butterfly topology network comparison and data exchange on the read Gaussian body entry array. This process is completed at the on-chip register and LDS level through multiple parallel passes (the total number of execution steps strictly follows the log_2(N) topology network structure, advancing layer by layer), completely avoiding read / write instructions to external video memory. By strictly arranging each Gaussian body entry in ascending order according to its depth value, a neat sequence of entries with a defined physical front-to-back occlusion order is finally output, reducing the global video memory bandwidth consumption during the sorting stage to zero bytes.
[0158] Step 3: Pixel-by-Pixel Transparency Blending and Independent Pruning Judgment. 256 threads, following the generated entry sequence from nearest to farthest, begin traversing the sorted Gaussian bodies layer by layer, adaptively calculating the cumulative color and transmittance of the light radiation field for their respective specific pixels. At the start of blending, the cumulative transmittance T = 1.0 for each pixel within the screen block area (representing complete background light transmission). When traversing to a Gaussian body entry, the projection opacity of the corresponding 3D Gaussian ellipsoid at the current pixel is obtained based on the index information carried by that entry. Calculate the residual light transmittance of this layer (i.e., 1- ), and adaptively attenuate the cumulative transmittance of the current pixel based on the multiplication rule, that is: ; And while attenuating, the radiometric intensity of the pixel color is accumulated, that is: C ; in This contributes a color factor to the current Gaussian layer. In this process, this application introduces a pixel-by-pixel adaptive early exit mechanism: for each pixel within the screen block area, once the traditional cumulative transmittance T of a specific pixel falls below a preset opacity threshold (e.g., T < 0.05) after several layers of Gaussian bodies are stacked, it indicates that the pixel has been completely occluded by an object in front. At this time, the thread will independently trigger an interrupt, immediately stopping the processing of all subsequent Gaussian body entries for that pixel, directly discarding and skipping approximately 50% of the subsequent useless and redundant Gaussian calculations, ensuring that the pixel lifecycles handled by each thread do not interfere with each other, significantly reducing the computation time consumption of the blending and compositing stage.
[0159] Step 4: Output the current block pixel color as the second rendering output. After all concurrent threads in the current screen block area have completed full entry traversal or exited due to early pruning, the system merges the final color values of the 256 pixels finally accumulated in the on-chip local storage area and writes them into the Gaussian color rendering target buffer at once to obtain the pixel color output of the screen block area, which is used as the second rendering output.
[0160] Compared to conventional 3D Gaussian global memory sorting pipelines, which often generate up to 720MB of global sorting bandwidth, require an additional 160MB of global sorting buffer memory, and are extremely inefficient due to multiple GPU scheduling and global hardware synchronization barriers, the method provided in this application completely eliminates global sorting bandwidth and memory overhead, relies solely on a single compute shader scheduling and requires no global synchronization, and exhibits extremely high real-time rendering throughput, extremely low resource overhead, and extremely strong frame rate stability in large-scale or highly dynamic complex scenes.
[0161] Taking a scene with 2 million Gaussian volumes as an example: the total rendering time of a conventional 3D Gaussian global memory sorting pipeline is approximately 2.4 milliseconds, while the total rendering time of the proposed solution is approximately 0.3 milliseconds, resulting in an overall speedup of approximately 8 times. When the scene size expands to 75 million Gaussian volumes, the conventional 3D Gaussian global memory sorting pipeline requires approximately 6GB of global sorting memory, exceeding the memory capacity limit of mainstream GPUs. Actual deployment is constrained by hardware resources, resulting in a rendering time of approximately 90 milliseconds. In contrast, the proposed solution reduces the required global memory for sorting to zero bytes, resulting in a rendering time of only 3 to 5 milliseconds, with an overall speedup of 18 to 30 times (varying depending on the scene's visual complexity and the density of visible Gaussian volumes). The fundamental reason for this performance improvement is that the rendering computational overhead of the proposed solution mainly depends on the actual number of visible Gaussian volumes in the current frame, rather than the total number of Gaussian volumes in the scene. Therefore, as the scene size increases, the compression effect of the upstream three-level visibility filtering becomes increasingly significant.
[0162] To facilitate better implementation of the data rendering method of this application embodiment, this application embodiment also provides a data rendering apparatus. Please refer to... Figure 5 , Figure 5 A schematic diagram of the structure of a data rendering apparatus provided in an embodiment of this application. The data rendering apparatus 200 may include: The acquisition unit 210 is used to acquire multiple first-type scene primitive clusters and multiple second-type scene primitive clusters corresponding to the scene to be rendered, wherein the multiple first-type scene primitive clusters and multiple second-type scene primitive clusters are mixed and organized in a unified spatial hierarchy structure. The filtering unit 220 is used to perform visibility filtering processing on multiple first-type scene primitive clusters and multiple second-type scene primitive clusters based on the spatial hierarchy structure to obtain a set of surviving clusters. The processing unit 230 is used to route the first type scene primitive cluster in the surviving cluster set to the first type scene primitive rendering path for rendering processing to obtain the first rendering output result, and to route the second type scene primitive cluster in the surviving cluster set to the second type scene primitive rendering path for rendering processing to obtain the second rendering output result, based on the type label of each cluster in the surviving cluster set. The fusion unit 240 is used to fuse the first rendering output result and the second rendering output result based on depth comparison to obtain the target rendering result.
[0163] In some embodiments, the spatial hierarchy is distributed in a tree-like hierarchical manner. When the device performs visibility filtering processing on multiple first-type scene primitive clusters and multiple second-type scene primitive clusters based on the spatial hierarchy to obtain a set of surviving clusters, it is specifically used for: Perform field-of-view detection on the instances to be rendered in the scene to be rendered, exclude rendering instances that are outside the field of view of the current frame, and obtain a set of surviving instances within the field of view; For each surviving instance in the set of surviving instances within the field of view, traverse each node belonging to the surviving instance in the spatial hierarchy from top to bottom. If the screen projection error value of the target node under the current rendering view is lower than the preset pixel threshold, stop expanding downwards and take the cluster under the jurisdiction of the target node as a candidate cluster to obtain a set of candidate clusters. For each candidate cluster in the candidate cluster set, the spatial bounding box of the current candidate cluster is projected onto the hierarchical depth buffer generated by the previous frame rendering. If the spatial bounding box is completely occluded by the depth information recorded in the hierarchical depth buffer generated by the previous frame rendering from the current rendering perspective, the current candidate cluster is eliminated in order to obtain the set of surviving clusters.
[0164] In some embodiments, the apparatus is further configured to calculate the screen projection error value of the target node under the current rendering view, specifically for: Obtain the error measurement information corresponding to the target node. For the first type of scene primitive cluster node, the error measurement information is geometric simplification deviation. For the second type of scene primitive cluster node, the error measurement information is primitive aggregation visual deviation. The error measurement information is converted into a projection size in units of screen pixels according to the projection parameters of the current rendering view, so as to obtain the screen projection error value of the target node in the current rendering view. The same conversion formula is used for the first type of scene primitive cluster node and the second type of scene primitive cluster node.
[0165] In some embodiments, when the apparatus routes a second-type scene primitive cluster in the surviving cluster set to a second-type scene primitive rendering path based on the type marker of each cluster in the surviving cluster set, and routes a first-type scene primitive cluster in the surviving cluster set to a first-type scene primitive rendering path, it is specifically used for: For any surviving cluster in the set of surviving clusters, read the type flag of the surviving cluster; When the type flag indicates that the surviving cluster is a second type scene primitive cluster, the incremental write position is obtained through lock-free parallel write operation, and the index information of the surviving cluster is written into the write position of the second type scene primitive visible buffer, so that the second type scene primitive rendering path can read the index information in the second type scene primitive visible buffer and execute the subsequent second type scene primitive rendering. When the type flag indicates that the surviving cluster is a first-type scene primitive cluster, the index information of the surviving cluster is written into the first-type scene primitive visible buffer, so that the first-type scene primitive rendering path can read the index information in the first-type scene primitive visible buffer and perform subsequent first-type scene primitive rendering.
[0166] In some embodiments, when the apparatus routes a second type of scene primitive cluster in the surviving cluster set to a second type of scene primitive rendering path for rendering processing to obtain a second rendering output result, it is specifically used for: Route the second type of scene primitive cluster in the surviving cluster set to the second type of scene primitive rendering path; In the second type of scene primitive rendering path, local sorting and image composition are performed based on the screen block regions to obtain the second rendering output result.
[0167] In some embodiments, when the apparatus performs local sorting and image composition based on screen block regions in a second type of scene primitive rendering path to obtain a second rendering output result, it is specifically used for: Each second-type scene primitive routed to the second-type scene primitive rendering path is projected onto the screen space to construct a set of second-type scene primitive entries corresponding to each screen block region. The set of second-type scene primitive entries contains the depth information of the second-type scene primitives. For each screen block area, within the shared memory corresponding to the associated thread group, the set of second-type scene primitive entries is sorted by depth and composited based on the depth information of the second-type scene primitives to obtain the pixel color output of the screen block area, which serves as the second rendering output result.
[0168] In some embodiments, when the apparatus projects each second-type scene primitive routed to a second-type scene primitive rendering path onto the screen space to construct a set of second-type scene primitive entries corresponding to each screen block region, it is specifically used for: Traverse the index information of each second-type scene element cluster in the visible buffer of the second-type scene element cluster to read the attribute parameters of each second-type scene element in the second-type scene element cluster; Project the attribute parameters of each second-type scene primitive to the screen space to determine the screen coordinates, screen coverage area and depth value of each second-type scene primitive; Based on the screen coordinates and screen coverage of each second-type scene primitive, the depth value and index information of each second-type scene primitive are assigned to one or more associated screen block regions, resulting in a set of second-type scene primitive entries corresponding to each screen block region.
[0169] In some embodiments, when the device performs depth sorting and image composition on the set of second-type scene primitive entries based on the second-type scene primitive depth information within the shared memory corresponding to the associated thread group for each screen block area, and obtains the pixel color output of the screen block area, it is specifically used for: For each screen block area, all second-type scene primitive entries covering the screen block area are read from global storage into the shared memory corresponding to the associated thread group; In shared memory, each second-type scene primitive entry is sorted in parallel according to the second-type scene primitive depth information to obtain an entry sequence; Following the order of entries from near to far, the transparency of each pixel within the screen block area is blended layer by layer to obtain the pixel color output of the screen block area; Depth sorting and transparency blending are performed sequentially in a single render call.
[0170] In some embodiments, when the apparatus performs transparency blending and synthesis layer by layer on each pixel within a screen block area to obtain the pixel color output of the screen block area, it is specifically used for: The cumulative transmittance of each pixel within the screen block area is initialized to a preset initial value that characterizes the complete transmission of background light; For the second type scene primitive entry currently traversed in the entry sequence, obtain the projection opacity of the second type scene primitive corresponding to each pixel in the screen block area; For each pixel in the screen block area, the remaining light transmittance is calculated using the projection opacity of the pixel, and the current cumulative transmittance of the pixel is attenuated using the remaining light transmittance based on the multiplication rule. When the cumulative transmittance of a pixel is lower than the preset opacity threshold, the processing of subsequent second-type scene primitive entries for the pixel is stopped, and the current cumulative color is output as the pixel color of the pixel in the screen block area.
[0171] In some embodiments, when the apparatus is used to fuse the first rendering output result and the second rendering output result based on depth comparison to obtain the target rendering result, it is specifically used for: Obtain the first depth value and first color information of the first rendering output at each pixel, and obtain the second depth value and second color information of the second rendering output at each pixel; For any pixel, when the corresponding second depth value is less than the corresponding first depth value, the corresponding second color information is superimposed on the pixel of the target rendering result; When the corresponding first depth value is less than or equal to the corresponding second depth value, the corresponding first color information is written into the pixel of the target rendering result.
[0172] In some embodiments, before acquiring the plurality of second-type scene primitive clusters and the plurality of first-type scene primitive clusters corresponding to the scene to be rendered, the apparatus is further configured to: The second type of scene primitives in the scene to be rendered are grouped into multiple second type scene primitive clusters by a preset fixed number; For each second-type scene primitive cluster, generate cluster header information containing spatial bounding boxes, error measurement information and type labels. The cluster header information of the second-type scene primitive cluster adopts the same data structure as the cluster header information of multiple first-type scene primitive clusters. The second-type scene graph element data of each second-type scene graph element cluster is stored in the same data organization format as multiple first-type scene graph element clusters, so that the two types of clusters can share the same set of streaming data loading and page replacement management mechanism.
[0173] Each unit in the aforementioned data rendering device can be implemented entirely or partially through software, hardware, or a combination thereof. These units can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can invoke and execute the operations corresponding to each unit.
[0174] The data rendering device 200 can be integrated into a terminal or server that has storage and a processor and thus computing power, or the data rendering device 200 can be the terminal or server.
[0175] Optionally, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.
[0176] Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device may include: a communication interface 301, a memory 302, a processor 303, and a communication bus 304. The communication interface 301, memory 302, and processor 303 communicate with each other via the communication bus 304. The communication interface 301 is used for data communication between the device 300 and external devices. The memory 302 can be used to store software programs and modules, and the processor 303 runs the software programs and modules stored in the memory 302, such as the software programs for corresponding operations in the aforementioned method embodiments.
[0177] In some embodiments, the processor 303 may invoke software programs and modules stored in the memory 302 to perform the following operations: obtaining multiple first-type scene primitive clusters and multiple second-type scene primitive clusters corresponding to the scene to be rendered, wherein the multiple first-type scene primitive clusters and multiple second-type scene primitive clusters are mixed and organized in a unified spatial hierarchy; based on the spatial hierarchy, performing visibility filtering processing on the multiple first-type scene primitive clusters and multiple second-type scene primitive clusters to obtain a set of surviving clusters; according to the type label of each cluster in the set of surviving clusters, routing the first-type scene primitive clusters in the set of surviving clusters to the first-type scene primitive rendering path for rendering processing to obtain a first rendering output result, and routing the second-type scene primitive clusters in the set of surviving clusters to the second-type scene primitive rendering path for rendering processing to obtain a second rendering output result; based on depth comparison, fusing the first rendering output result and the second rendering output result to obtain a target rendering result.
[0178] In some embodiments, the computer device 300 may be integrated into a terminal or server that has storage and a processor, thus possessing computing capabilities; or the computer device 300 may be the terminal or server. The terminal may be a smartphone, tablet, laptop, smart TV, smart speaker, wearable smart device, personal computer, or other similar device. The server may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.
[0179] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to a computer device, and the computer program causes the computer device to execute the corresponding process in the data rendering method of the embodiments of this application; for the sake of brevity, further details are omitted here.
[0180] This application also provides a computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding process in the data rendering method of the embodiments of this application. For simplicity, further details are omitted here.
[0181] This application also provides a computer program comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the corresponding process in the data rendering method of this application. For brevity, further details are omitted here.
[0182] It should be understood that the processor in this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.
[0183] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.
[0184] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0185] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0186] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.
[0187] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0188] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0189] In addition, the functional units in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0190] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer or a server) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.
[0191] 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 shall be determined by the scope of the claims.
Claims
1. A data rendering method, characterized in that, The method includes: Obtain multiple first-type scene primitive clusters and multiple second-type scene primitive clusters corresponding to the scene to be rendered, wherein the multiple first-type scene primitive clusters and multiple second-type scene primitive clusters are mixed and organized in a unified spatial hierarchy structure. Based on the spatial hierarchy, visibility filtering is performed on the multiple first-type scene element clusters and the multiple second-type scene element clusters to obtain a set of surviving clusters. Based on the type label of each cluster in the surviving cluster set, the first type scene primitive cluster in the surviving cluster set is routed to the first type scene primitive rendering path for rendering processing to obtain the first rendering output result, and the second type scene primitive cluster in the surviving cluster set is routed to the second type scene primitive rendering path for rendering processing to obtain the second rendering output result. Based on depth comparison, the first rendering output result and the second rendering output result are fused to obtain the target rendering result.
2. The data rendering method as described in claim 1, characterized in that, The spatial hierarchy is distributed in a tree-like hierarchical manner. Based on the spatial hierarchy, visibility filtering processing is performed on the multiple first-type scene primitive clusters and the multiple second-type scene primitive clusters to obtain a set of surviving clusters, including: Perform field-of-view detection on the instances to be rendered in the scene to be rendered, exclude rendering instances that are outside the field of view of the current frame, and obtain a set of surviving instances within the field of view; For each surviving instance in the set of surviving instances within the field of view, each node belonging to the surviving instance in the spatial hierarchy is traversed from top to bottom. If the screen projection error value of the target node under the current rendering view is lower than a preset pixel threshold, the downward expansion is stopped, and the cluster under the jurisdiction of the target node is taken as a candidate cluster to obtain a set of candidate clusters. For each candidate cluster in the candidate cluster set, the spatial bounding box of the current candidate cluster is projected onto the hierarchical depth buffer generated by the previous frame rendering. If the spatial bounding box is completely occluded by the depth information recorded in the hierarchical depth buffer generated by the previous frame rendering from the current rendering perspective, the current candidate cluster is removed to filter and obtain the set of surviving clusters.
3. The data rendering method as described in claim 2, characterized in that, The steps for calculating the screen projection error value of the target node under the current rendering view include: Obtain the error measurement information corresponding to the target node, wherein, for the first type of scene primitive cluster node, the error measurement information is geometric simplification deviation, and for the second type of scene primitive cluster node, the error measurement information is primitive aggregation visual deviation; The error measurement information is converted into a projection size in units of screen pixels according to the projection parameters of the current rendering view, so as to obtain the screen projection error value of the target node under the current rendering view. The same conversion formula is used for the first type of scene primitive cluster node and the second type of scene primitive cluster node.
4. The data rendering method as described in claim 1, characterized in that, Based on the type markers of each cluster in the surviving cluster set, the first type scene primitive clusters in the surviving cluster set are routed to the first type scene primitive rendering path, and the second type scene primitive clusters in the surviving cluster set are routed to the second type scene primitive rendering path, including: For any surviving cluster in the set of surviving clusters, read the type flag of the surviving cluster; When the type marker indicates that the surviving cluster is a second type scene primitive cluster, the incremental write position is obtained through lock-free parallel write operation, and the index information of the surviving cluster is written into the write position of the second type scene primitive visible buffer, so that the second type scene primitive rendering path can read the index information in the second type scene primitive visible buffer and perform subsequent second type scene primitive rendering. When the type marker indicates that the surviving cluster is a first type scene primitive cluster, the index information of the surviving cluster is written into the first type scene primitive visible buffer, so that the first type scene primitive rendering path can read the index information in the first type scene primitive visible buffer and perform subsequent first type scene primitive rendering.
5. The data rendering method as described in claim 1, characterized in that, The second type of scene primitive cluster in the surviving cluster set is routed to the second type of scene primitive rendering path for rendering processing to obtain the second rendering output result, including: The second type of scene primitive cluster in the surviving cluster set is routed to the second type of scene primitive rendering path; In the second type of scene primitive rendering path, local sorting and image composition are performed based on the screen block area to obtain the second rendering output result.
6. The data rendering method as described in claim 5, characterized in that, In the second type of scene primitive rendering path, local sorting and image compositing are performed based on screen block regions to obtain the second rendering output result, including: Each second-type scene primitive routed to the second-type scene primitive rendering path is projected onto the screen space to construct a set of second-type scene primitive entries corresponding to each screen block region, wherein the set of second-type scene primitive entries contains the depth information of the second-type scene primitives; For each screen block region, within the shared memory corresponding to the associated thread group, the set of second-type scene primitive entries is depth-sorted and image composited based on the second-type scene primitive depth information to obtain the pixel color output of the screen block region, which serves as the second rendering output result.
7. The data rendering method as described in claim 6, characterized in that, Project each second-type scene primitive routed to the second-type scene primitive rendering path onto the screen space to construct a set of second-type scene primitive entries corresponding to each screen block region, including: Traverse the index information of each second-type scene element cluster in the visible buffer of the second-type scene element cluster to read the attribute parameters of each second-type scene element in the second-type scene element cluster; The attribute parameters of each second type of scene primitive are projected onto the screen space to determine the screen coordinates, screen coverage area, and depth value of each second type of scene primitive. Based on the screen coordinates and screen coverage of each second-type scene primitive, the depth value and index information of each second-type scene primitive are assigned to one or more associated screen block regions to obtain a set of second-type scene primitive entries corresponding to each screen block region.
8. The data rendering method as described in claim 6, characterized in that, For each of the aforementioned screen block regions, within the shared memory corresponding to the associated thread group, the set of second-type scene primitive entries is depth-sorted and composited based on the second-type scene primitive depth information to obtain the pixel color output of the screen block region, including: For each of the aforementioned screen block regions, all second-type scene primitive entries covering the screen block region are read from global storage into the shared memory corresponding to the associated thread group; In the shared memory, each second type of scene primitive entry is sorted in parallel according to the depth information of the second type of scene primitive to obtain an entry sequence; According to the order of the entries from near to far, the transparency of each pixel in the screen block area is blended layer by layer to obtain the pixel color output of the screen block area; The depth sorting and transparency blending are performed sequentially in a single rendering call.
9. The data rendering method as described in claim 8, characterized in that, The transparency of each pixel within the screen block area is blended layer by layer to obtain the pixel color output of the screen block area, including: The cumulative transmittance of each pixel within the screen block area is initialized to a preset initial value that characterizes the complete transmission of background light; For the second type scene primitive entry currently traversed in the entry sequence, obtain the projection opacity of the second type scene primitive corresponding to the second type scene primitive entry at each pixel in the screen block area; For each pixel in the screen block area, the remaining light transmittance is calculated using the projection opacity corresponding to the pixel, and the current cumulative transmittance of the pixel is attenuated using the remaining light transmittance based on the multiplication rule. When the cumulative transmittance of the pixel is lower than a preset opacity threshold, the processing of subsequent second-type scene primitive entries for the pixel is stopped, and the current cumulative color is output as the pixel color of the pixel in the screen block area.
10. The data rendering method as described in claim 1, characterized in that, The process of fusing the first rendering output result with the second rendering output result based on depth comparison to obtain the target rendering result includes: Obtain the first depth value and first color information of the first rendering output result at each pixel, and obtain the second depth value and second color information of the second rendering output result at each pixel; For any pixel, when the corresponding second depth value is less than the corresponding first depth value, the corresponding second color information is superimposed on the pixel of the target rendering result; When the corresponding first depth value is less than or equal to the corresponding second depth value, the corresponding first color information is written into the pixel of the target rendering result.
11. The data rendering method as described in claim 1, characterized in that, Before obtaining the multiple first-type scene primitive clusters and multiple second-type scene primitive clusters corresponding to the scene to be rendered, the method further includes: The set of second-type scene primitives in the scene to be rendered is grouped into a preset fixed number to obtain the multiple second-type scene primitive clusters; For each second type of scene primitive cluster, generate cluster header information containing spatial bounding boxes, error measurement information and type tags, wherein the cluster header information of the second type of scene primitive cluster adopts the same data structure as the cluster header information of the multiple first type of scene primitive clusters. The second-type scene graph data of each second-type scene graph cluster is stored in the same data organization format as the multiple first-type scene graph clusters, so that the two types of clusters share the same set of streaming data loading and page replacement management mechanism.
