Ray tracing rendering method and system based on C + + and shader separation architecture

Abstract

The invention discloses a ray tracing rendering method and system based on a C + + and shader separation architecture, and relates to the technical field of ray tracing rendering, and the method comprises the steps: stripping ray tracing logic from a C + + host end and a shader; a bottom layer calculation task related to GPU hardware is reserved at a shader end, and a unified structured rendering parameter transmission and buffer area scheduling mechanism is designed; integrating a BVH acceleration intersection module to a C + + host end; and performing fine-grained statistics on the scheduling overhead of the C + + host and the execution load of the shader. According to the method, the code maintainability and the algorithm iteration efficiency are improved; a shader end is prevented from repeatedly analyzing a scene structure; high expansibility, cross-platform consistency and engineering landing feasibility are achieved, and efficient development and deployment of high-fidelity visualization and simulation application are effectively supported.

Description

Technical Field

[0001] This invention relates to the field of ray tracing rendering technology, and in particular to a ray tracing rendering method and system based on a C++ and shader separation architecture. Background Technology

[0002] Currently, with the rapid development of digital content creation, virtual reality, intelligent driving simulation, industrial digital twins, and immersive interactive applications, society's demand for highly realistic graphics rendering technology is becoming increasingly urgent. Users and industries are increasingly expecting to obtain near-physically realistic lighting and shadow effects in various visualization systems, including accurate reflections, refractions, soft shadows, and complex optical phenomena such as global illumination. At the same time, cross-platform compatibility, real-time interactivity, and efficient development processes have become key requirements for modern rendering systems. Under this trend, ray tracing technology, with its naturally physically-compliant imaging mechanism, is gradually becoming a core means of achieving high-fidelity visual experiences.

[0003] However, current mainstream ray tracing implementations generally suffer from drawbacks such as high architectural coupling, poor maintainability, and difficulty in platform adaptation. Many systems tightly embed the core logic of ray tracing into shader code or deeply intertwine it with C++ host logic, requiring simultaneous modifications to both CPU and GPU code during algorithm iteration, significantly increasing development complexity. At the same time, this tightly coupled design makes it difficult to flexibly support the unified management of both offline high-quality rendering and real-time interactive modes. When integrated into large commercial engines such as Unreal Engine 5, performance bottlenecks or functional redundancy are likely to occur. Furthermore, existing solutions often lack a clear definition of computational load characteristics, which is not conducive to subsequent targeted optimization and severely limits the efficient deployment and expansion of ray tracing technology in high-fidelity, multi-platform simulation and visualization scenarios. Summary of the Invention

[0004] In view of the problems existing in the existing ray tracing rendering methods and systems based on C++ and shader separation architecture, this invention is proposed.

[0005] Therefore, the problem that this invention aims to solve is that the deep coupling between C++ logic and shaders in existing ray tracing rendering methods leads to a rigid architecture, difficulty in maintenance, inability to uniformly support offline and real-time rendering, and poor cross-platform compatibility and opaque computational costs when integrated into engines such as UE5.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, embodiments of the present invention provide a ray tracing rendering method based on a C++ and shader separation architecture, which includes building a ray tracing logic control framework on the C++ host side and separating the ray tracing logic from the C++ host side and the shader. The shader side retains the low-level computational tasks related to the GPU hardware and exchanges data with the C++ host side through a standardized data interface defined and maintained by the C++ host side; Design a unified structured rendering parameter passing and buffer scheduling mechanism, dynamically configure it on the C++ host side, and pass it to the shader; The BVH accelerated intersection module is integrated into the C++ host and combined with the scene management system of the UE5 engine to perform cross-platform consistent geometry queries and pass the intersection results to the shader in a predefined format. A cost analysis module is introduced to perform fine-grained statistics on C++ host-side scheduling overhead and shader execution load.

[0007] As a preferred embodiment of the ray tracing rendering method based on the C++ and shader separation architecture described in this invention, wherein: the construction of the ray tracing logic control framework on the C++ host side includes establishing a path tracing scheduler independent of the rendering pipeline. The path tracing scheduler is responsible for managing the generation of the initial master ray starting from the camera viewpoint, determining whether to trigger reflection or refraction behavior based on the material type at each intersection point, and deciding whether to terminate the tracing path for secondary rays that need to be continued to be traced. The ray tracing logic control framework includes an integrated BRDF model calling interface. Each time a ray interacts with a surface, the C++ host selects the corresponding bidirectional reflection distribution function according to the material type, and generates the incident direction samples and probability density values ​​PDF required for Monte Carlo integration by combining the sampling strategy, and calculates the weight of the illumination contribution.

[0008] As a preferred embodiment of the ray tracing rendering method based on the C++ and shader separation architecture described in this invention, wherein: the separation of ray tracing logic from the C++ host and shader includes the C++ host submitting independent ray tasks to the rendering pipeline one by one by traversing the scene ray queue. The independent ray includes each ray undergoing only one shader call in its entire lifecycle, used to perform intersection and local lighting response calculations. The ray tracing logic is fully retained on the C++ host side, forming a high-level control flow that works with the shaders. At the architectural level, the ray tracing logic is separated from the C++ host side and the shaders.

[0009] As a preferred embodiment of the ray tracing rendering method based on a C++ and shader separation architecture described in this invention, the step of retaining the underlying computational tasks related to GPU hardware at the shader end includes the following: Perform ray-scene intersection operation based on BVH acceleration structure, determine whether the input ray intersects with the geometry in the scene and return the nearest intersection point; Based on the material index at the intersection, the corresponding attribute is read from the material parameter table passed from the C++ host, and the pre-compiled BRDF or PDF lighting model function is called to calculate the local lighting response. The color contributions from samples from multiple paths are summed. The synthesized color values ​​are written into the rendering target of the rendering pipeline to complete pixel output; The data exchange with the C++ host through a standardized data interface defined and maintained by the C++ host includes the C++ host being responsible for maintaining the standardized data interface throughout the rendering process. The standardized data interface includes a structured buffer and a constant buffer. The structured buffer is used to store the data structure of each independent ray, and the constant buffer is used to pass globally shared parameters; Before each frame of rendering begins, the C++ host serializes all the rays to be processed generated by the path tracing scheduler and writes them into the structured buffer, and synchronously updates the global configuration in the constant buffer. When the shader is executed, it accesses the structured buffer and constant buffer in read-only mode through the shader parameter binding mechanism provided by the UE5 engine. After completing a single intersection and lighting calculation based on the contents of the structured buffer, it directly outputs the result without sending intermediate state back to the C++ host or requesting new tasks.

[0010] As a preferred embodiment of the ray tracing rendering method based on the C++ and shader separation architecture described in this invention, the design of a unified structured rendering parameter passing and buffer scheduling mechanism includes defining a parameter classification system by the C++ host during the initialization phase, and dividing the parameter classification system into frame-level global parameters and ray-level local parameters. Frame-level global parameters and ray-level local parameters are mapped to constant buffers and structured buffers respectively, and the layout is performed using memory alignment rules compatible with UE5 engine RHI. The dynamic configuration on the C++ host side includes dynamically configuring frame-level global parameters and ray-level local parameters at runtime according to the rendering mode specified by the user. In offline mode and real-time mode, dynamic configuration is completed by updating the contents of constant buffers respectively. The passing to the shader includes, before the start of each rendering frame, the C++ host calls the path tracing scheduler to generate all the ray tasks that need to be processed in the current frame, and serializes and fills the local parameters of each ray into the structured buffer; the global parameters corresponding to the current rendering mode are written into the constant buffer, and the structured buffer and the constant buffer are submitted to the shader through the unified resource binding interface provided by UE5; During execution, the shader determines which computation branch to enable based on the global configuration in the constant buffer, and reads the light data line by line from the structured buffer to perform intersection and lighting response.

[0011] As a preferred embodiment of the ray tracing rendering method based on the C++ and shader separation architecture described in this invention, the cross-platform consistent geometry query includes serializing the constructed BVH tree into a platform-independent linear memory layout on the C++ host side, with node data stored continuously in depth-first order, and the linear memory layout is used to follow the 8-byte alignment rule. The C++ host writes the serialized BVH node array as read-only data into the area of ​​the structured buffer, and records the BVH root node index and the total number of nodes in the constant buffer. When performing ray-scene intersection, the shader reads BVH node data from the structured buffer according to a predefined format and performs an intersection test; The step of passing the intersection result to the shader in a predefined format includes the shader using the geometric intersection attribute set for BRDF lighting calculation and color accumulation after completing the traversal; The geometric intersection attributes are all derived from the original geometric data and BVH structure passed from the C++ host.

[0012] As a preferred embodiment of the ray tracing rendering method based on the C++ and shader separation architecture described in this invention, the fine-grained statistics of C++ host-side scheduling overhead and shader execution load include, within the ray tracing logic control framework on the C++ host side, using a cost analysis module, initiating GPU time query through the RHI interface of the UE5 engine to obtain the actual load data of shader execution, which is then uniformly managed by the C++ host side.

[0013] Secondly, embodiments of the present invention provide a ray tracing rendering system based on a C++ and shader separation architecture, which includes: a ray tracing logic control module, which builds a ray tracing logic control framework on the C++ host side and separates the ray tracing logic from the C++ host side and the shader; The underlying computing task execution module retains the underlying computing tasks related to the GPU hardware on the shader side and exchanges data with the C++ host side through a standardized data interface defined and maintained by the C++ host side; The structured parameter passing and buffer scheduling module is designed with a unified structured rendering parameter passing and buffer scheduling mechanism, which is dynamically configured on the C++ host side and passed to the shader. The BVH accelerated intersection module integrates the BVH accelerated intersection module on the C++ host side, and combines it with the scene management system of the UE5 engine to perform cross-platform consistent geometry queries, and pass the intersection results to the shader through a predefined format; The cost analysis module performs fine-grained statistics on C++ host-side scheduling overhead and shader execution load.

[0014] Thirdly, embodiments of the present invention provide 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 any step of the above-described ray tracing rendering method based on a C++ and shader separation architecture.

[0015] Fourthly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program is executed by a processor, it implements any step of the above-described ray tracing rendering method based on a C++ and shader separation architecture.

[0016] The beneficial effects of this invention are as follows: By constructing a ray tracing rendering architecture that separates C++ and shaders, this invention centralizes high-level logic such as path control, material interaction, and sampling scheduling entirely on the C++ host side, while the shaders only perform low-level tasks such as intersection, BRDF calculation, and color output. This significantly reduces system coupling and improves code maintainability and algorithm iteration efficiency. Through a unified structured rendering parameter passing and buffer scheduling mechanism, it supports dynamic switching and resource sharing between offline high-precision and real-time interactive rendering modes within the same system. The BVH accelerated intersection module, combined with the UE5 scene management system on the C++ side, achieves consistent geometric queries across platforms, avoiding repeated scene structure parsing on the shader side. Simultaneously, the introduced cost analysis module performs fine-grained statistics on C++ scheduling overhead and shader load, providing a quantitative basis for performance optimization. The overall solution, while ensuring physical realism, achieves high scalability, cross-platform consistency, and engineering feasibility, effectively supporting the efficient development and deployment of high-fidelity visualization and simulation applications. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein: Figure 1 A flowchart of a ray tracing rendering method based on a C++ and shader separation architecture provided for embodiments of the present invention.

[0018] Figure 2This is a system schematic diagram of a ray tracing rendering method based on a C++ and shader separation architecture, provided as an embodiment of the present invention. Detailed Implementation

[0019] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0020] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0021] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0022] This invention is described in detail with reference to the schematic diagrams. When detailing the embodiments of this invention, for ease of explanation, the cross-sectional views illustrating the device structure may be partially enlarged, not adhering to the usual scale. Furthermore, the schematic diagrams are merely examples and should not be construed as limiting the scope of protection of this invention. In actual fabrication, the three-dimensional spatial dimensions of length, width, and depth should be included.

[0023] Furthermore, in the description of this invention, it should be noted that the terms "upper," "lower," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are used solely for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. In addition, the terms "first," "second," or "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0024] Unless otherwise explicitly specified and limited, the terms "installation," "connection," and "joining" in this invention should be interpreted broadly. For example, they can refer to fixed connections, detachable connections, or integral connections; similarly, they can refer to mechanical connections, electrical connections, or direct connections, or indirect connections through an intermediate medium, or internal connections between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0025] Example Reference Figure 1 and Figure 2 This is the first embodiment of the present invention, which provides a ray tracing rendering method based on a C++ and shader separation architecture, including: S1: Build a ray tracing logic control framework on the C++ host side, and separate the ray tracing logic from the C++ host side and shaders.

[0026] Among them, building a ray tracing logic control framework on the C++ host side includes establishing a path tracing scheduler independent of the rendering pipeline. The path tracing scheduler is responsible for managing the generation of the initial master ray starting from the camera viewpoint, determining whether to trigger reflection or refraction behavior based on the material type at each intersection, and deciding whether to terminate the tracing path for secondary rays that need to be traced. The ray tracing logic control framework includes an integrated BRDF model calling interface. Each time a ray interacts with a surface, the C++ host selects the corresponding bidirectional reflection distribution function based on the material type, and generates the incident direction samples and probability density values ​​PDF required for Monte Carlo integration by combining the sampling strategy, and calculates the weight of the illumination contribution.

[0027] The ray tracing logic is separated from the C++ host and shader. The C++ host traverses the scene ray queue and submits independent ray tasks to the rendering pipeline one by one. Each independent ray undergoes only one shader call in its entire lifecycle to perform intersection and local lighting response calculations. Ray tracing logic is entirely preserved on the C++ host side, forming a high-level control flow that works with the shaders. At the architectural level, the ray tracing logic is separated from the C++ host side and the shaders.

[0028] Furthermore, a path tracing scheduler, independent of the rendering pipeline, is built on the C++ host side. This scheduler is responsible for generating the initial master ray from the camera viewpoint and determining whether to trigger reflection or refraction behavior based on the material type at each intersection. For secondary rays that need to be tracked further, the path tracing scheduler decides whether to stop tracking based on the set maximum recursion depth and the Russian roulette termination probability. In addition, a BRDF model calling interface is integrated, allowing the C++ host side to select an appropriate bidirectional reflection distribution function based on material properties each time a ray interacts with a surface. It then combines this with an importance sampling strategy to generate incident direction samples and their probability density values ​​(PDFs) required for Monte Carlo integration, in order to calculate the weight of the illumination contribution.

[0029] To further optimize the architecture, all ray tracing logic is centralized on the C++ host side, forming a high-level control flow, while the shaders only perform intersection operations and local lighting response calculations. Specifically, the C++ host side traverses the scene ray queue, submitting independent ray tasks to the rendering pipeline one by one. Each ray undergoes only one shader call throughout its entire lifecycle to complete the intersection calculation between the ray and the scene geometry and the lighting response calculation based on the intersection information. In this way, the C++ host side achieves complete control over the ray path, ensuring clear logic and ease of maintenance, while avoiding complex path branch judgments and material state management in the shaders, simplifying shader design and improving the overall system's scalability and cross-platform compatibility. Thus, this invention successfully transforms the ray tracing logic from a hybrid implementation mode of C++ host side and shaders to a C++ host side-dominated decoupled architecture, significantly improving development efficiency and system flexibility.

[0030] Furthermore, in this invention, a path tracing scheduler completely independent of the graphics rendering pipeline is constructed on the C++ host side. This scheduler, as the core control unit for ray tracing, is responsible for generating initial master rays for each pixel from the camera's perspective. After the ray intersects with the scene geometry, it determines whether to generate secondary rays of reflection or refraction based on the specific material type at the intersection point (e.g., metal, glass, or diffuse surface). For each newly generated secondary ray, the scheduler continuously tracks its trajectory depth and dynamically decides whether to continue tracing or terminate the path early based on a preset maximum recursion depth limit and the random termination probability in the Russian Roulette algorithm, thereby effectively controlling computational overhead. Simultaneously, the C++ host side integrates a BRDF model calling interface. Each time a ray interacts with a surface, it can automatically match the corresponding bidirectional reflection distribution function based on the material properties and, combined with an importance sampling strategy, generate incident direction samples and their corresponding probability density values ​​(PDFs) for Monte Carlo integration, thereby accurately calculating the path's illumination contribution weight to the final pixel color. To achieve logical decoupling, all high-level control logic, such as path decision-making, ray derivation, sampling scheduling, and integral accumulation, is strictly retained on the C++ host side, forming a clear high-level control flow. The shader is limited to performing only one-time low-level computational tasks: receiving single ray data submitted by C++, performing ray-scene intersection based on the BVH structure, and using the material index at the intersection point to call pre-compiled BRDF / PDF functions for local lighting response calculation, ultimately outputting the color result. The C++ host side traverses a ray queue dynamically maintained by a path tracing scheduler, submitting each independent ray as an atomic task to the rendering pipeline frame by frame, ensuring that each ray triggers only one shader call throughout its entire lifecycle, without returning to the C++ side for subsequent path expansion. This design completely avoids embedding path control, material branching, or recursive logic in shaders, keeping shaders simple, stable, and platform-independent. All complex logic is managed uniformly by the C++ side, thus realizing a fundamental shift in ray tracing logic from the traditional hybrid C++ and shader model to a separate architecture dominated by C++ and assisted by shaders, significantly improving the system's maintainability, development flexibility, and cross-platform consistency.

[0031] S2: The shader side retains the low-level computational tasks related to the GPU hardware and exchanges data with the C++ host side through a standardized data interface defined and maintained by the C++ host side.

[0032] The underlying computational tasks related to GPU hardware that are retained at the shader level include the following: Perform ray-scene intersection operation based on BVH acceleration structure, determine whether the input ray intersects with the geometry in the scene and return the nearest intersection point; Based on the material index at the intersection, the corresponding attribute is read from the material parameter table passed from the C++ host, and the pre-compiled BRDF or PDF lighting model function is called to calculate the local lighting response. The color contributions from samples from multiple paths are summed. The synthesized color values ​​are written into the rendering target of the rendering pipeline to complete pixel output; Data exchange with the C++ host is conducted through a standardized data interface defined and maintained by the C++ host. This standardized data interface is maintained by the C++ host throughout the rendering process and includes structured buffers and constant buffers. The structured buffer is used to store the data structure of each individual ray, while the constant buffer is used to pass globally shared parameters; Before each frame of rendering begins, the C++ host serializes all the rays to be processed generated by the path tracing scheduler and writes them into the structured buffer, and synchronously updates the global configuration in the constant buffer. When the shader is executed, it accesses the structured buffer and constant buffer in read-only mode through the shader parameter binding mechanism provided by the UE5 engine. After completing a single intersection and lighting calculation based on the contents of the structured buffer, it directly outputs the result without sending intermediate state back to the C++ host or requesting new tasks.

[0033] Furthermore, the shader is strictly limited to performing only low-level computational tasks closely related to the graphics hardware, without any path control or logical judgment. Specifically, the shader first performs a ray-scene intersection operation based on BVH (Bounding Volume Hierarchy) to determine whether a single ray passed from the C++ host intersects with geometry in the scene and returns the nearest valid intersection point. Then, based on the material index carried by the intersection point, it reads the corresponding reflectivity, roughness, metallicity, and other properties from the material parameter table pre-uploaded by the C++ host and calls the pre-compiled BRDF or PDF lighting model function to calculate the local lighting response at the intersection point. Next, if the current pixel corresponds to multiple sampling paths (such as multi-frame accumulation or multiple importance sampling), the shader accumulates the color contributions generated by each of these paths to complete the numerical approximation of the Monte Carlo integral. Finally, the synthesized color value is written to the rendering target of the rendering pipeline to complete the output of the pixel. All the above operations rely on a standardized data interface defined and maintained throughout the entire lifecycle by the C++ host. This interface consists of a structured buffer and a constant buffer: the structured buffer stores data for each individual ray (including origin, direction, launch depth, path weight, and material index), while the constant buffer transmits globally shared parameters (such as light source configuration, whether global illumination is enabled, and maximum number of samples). Before each frame of rendering begins, the C++ host serializes all the rays to be processed generated by the path tracing scheduler and writes them into the structured buffer, while simultaneously updating the global configuration in the constant buffer. When the shader executes, it accesses these two buffers in read-only mode through the standard shader parameter binding mechanism provided by the UE5 engine, performs a one-time intersection and lighting calculation based on the data, and directly outputs the results. The entire process does not send any intermediate states back to the C++ host, nor does it request new ray tasks, thus ensuring the unidirectionality of the data flow, the determinism of the calculation, and the clear decoupling of the architecture.

[0034] Furthermore, shaders are explicitly limited to performing only low-level, stateless computational tasks that closely match the graphics hardware execution model, and do not participate in any path control, material branching, or recursive logic. Its workflow begins by receiving a single ray data point submitted by the C++ host, which includes complete information such as the origin, direction, current launch depth, path weight, and material index. The shader first uses the BVH acceleration structure passed from the C++ host to perform an intersection test between the ray and the scene geometry, accurately finding the nearest valid intersection point (if one exists). Subsequently, based on the material index attached to the intersection point, it reads the corresponding physical properties (such as base reflectivity, roughness, metallicity, etc.) from the material parameter table pre-uploaded to the video memory by the C++ host, and calls the pre-compiled BRDF or PDF lighting function to calculate the local lighting response value of the intersection point under the current incident-out direction. If the current pixel needs to fuse the results of multiple sampling paths (e.g., through multi-frame cumulative noise reduction or multi-importance sampling strategies), the shader linearly accumulates the color contributions calculated by each of these independent paths, thereby completing the numerical approximation of the Monte Carlo integral. Finally, the synthesized color value is written to the rendering target to complete the rendering of the pixel. The entire process relies on standardized data interfaces defined and maintained throughout the C++ host. A structured buffer efficiently stores batches of independent ray tasks, while a constant buffer holds global configuration parameters (such as point light source positions, global illumination enabled, and maximum sampling count). At the start of each frame, the C++ host serializes all pending rays generated by the path tracing scheduler and fills them into the structured buffer, simultaneously refreshing the mode configuration in the constant buffer. During execution, the shader accesses these two buffers in read-only mode through the UE5 engine's standard parameter binding mechanism. Based on the data within, it performs one and only one intersection and lighting calculation, directly outputting the result without sending intermediate states back to the C++ side, initiating new task requests, or performing any conditional jumps or loop control. This design ensures strictly unidirectional data flow (C++ to shader), predictable computational behavior, and extremely simple and stable shader logic. This achieves a complete separation of high-level control and low-level execution at the architectural level, laying a solid foundation for cross-platform deployment, multi-mode switching, and efficient maintenance.

[0035] S3: Design a unified structured rendering parameter passing and buffer scheduling mechanism, dynamically configured on the C++ host side and passed to the shader.

[0036] Among them, the design of a unified structured rendering parameter passing and buffer scheduling mechanism includes defining a parameter classification system on the C++ host side during the initialization phase, and dividing the parameter classification system into frame-level global parameters and ray-level local parameters. Frame-level global parameters and ray-level local parameters are mapped to constant buffers and structured buffers respectively, and the layout is performed using memory alignment rules compatible with UE5 engine RHI. Dynamic configuration on the C++ host side includes dynamically configuring frame-level global parameters and ray-level local parameters at runtime according to the rendering mode specified by the user. In offline mode and real-time mode, dynamic configuration is accomplished by updating the contents of constant buffers respectively. The process of passing data to the shader includes, before the start of each rendering frame, the C++ host calling the path tracing scheduler to generate all the ray tasks that need to be processed in the current frame, and serializing and filling the local parameters of each ray into the structured buffer; writing the global parameters corresponding to the current rendering mode into the constant buffer, and submitting the structured buffer and the constant buffer to the shader through the unified resource binding interface provided by UE5; During execution, the shader determines which computation branch to enable based on the global configuration in the constant buffer, and reads the light data line by line from the structured buffer to perform intersection and lighting response.

[0037] Furthermore, to achieve efficient, flexible, and consistent parameter management across platforms, the C++ host machine designed and established a unified structured rendering parameter passing and buffer scheduling mechanism during system initialization. This mechanism first systematically categorizes all rendering parameters into two types: frame-level global parameters, such as whether global illumination is enabled, the position and intensity of point light sources, maximum path depth, BRDF model selection flags, and the current running mode (offline high-precision or real-time interactive), which remain constant throughout the rendering frame; and ray-level local parameters, including the origin, direction, launch depth, path weight, and associated material index of each ray, which vary depending on the ray's task. Subsequently, the C++ host machine maps these two types of parameters to semantically defined buffer types in the graphics API: frame-level global parameters are written to constant buffers, while ray-level local parameters are organized into arrays and stored in structured buffers, strictly adhering to the memory alignment rules required by the UE5 engine's RHI (Rendering Hardware Interface) to ensure consistency and efficiency of data access across different platforms. At runtime, the C++ host can dynamically adjust parameter configurations based on the user-specified rendering mode. For example, it can enable high sampling rates and a full physical model in offline mode, while reducing depth constraints and employing simplified calculations in real-time mode. All these switching can be accomplished simply by updating the contents of the constant buffer, without recompiling the shaders or modifying the code logic. Before each frame of rendering begins, the C++ host calls the path tracing scheduler to generate all the ray tasks that need to be processed in the current frame, serializes the local parameters of each ray, and batches them into the structured buffer. At the same time, it writes the global parameters corresponding to the current mode into the constant buffer. Subsequently, through the unified resource binding interface provided by UE5, these two buffers are submitted to the shader at once. During execution, the shader first reads the global configuration in the constant buffer to determine which calculation branches to enable (such as whether to calculate refraction, whether to accumulate indirect light, etc.), and then reads the independent ray data one by one from the structured buffer, performing intersection and lighting response calculations in sequence. The entire process achieves centralized management of parameter configurations, seamless transitions between modes, and efficient and reliable data transfer, effectively supporting the coexistence and reuse of offline and real-time rendering under a unified architecture.

[0038] S4: Integrates the BVH accelerated intersection module on the C++ host side, and combines it with the scene management system of the UE5 engine to perform cross-platform consistent geometry queries, and passes the intersection results to the shader through a predefined format.

[0039] Among them, performing cross-platform consistent geometric queries involves the C++ host serializing the constructed BVH tree into a platform-independent linear memory layout, with node data stored contiguously in depth-first order, and the linear memory layout used to follow the 8-byte alignment rule. The C++ host writes the serialized BVH node array as read-only data into the area of ​​the structured buffer, and records the BVH root node index and the total number of nodes in the constant buffer. When performing ray-scene intersection, the shader reads BVH node data from the structured buffer according to a predefined format and performs an intersection test; The intersection result is passed to the shader in a predefined format. After the shader completes the traversal, it uses the set of geometric intersection attributes for BRDF lighting calculation and color accumulation. The geometric intersection attributes are all derived from the original geometric data and BVH structure passed from the C++ host.

[0040] Furthermore, to achieve consistent geometric query capabilities across platforms, the C++ host machine, after constructing the BVH (Bounding Volume Hierarchy) acceleration tree, converts it into a platform-independent linear memory layout: all BVH nodes are arranged consecutively in depth-first traversal order, each node containing bounding box information (minimum / maximum coordinates), child node indices, and leaf node identifiers in a uniform format, strictly adhering to 8-byte memory alignment rules to avoid data misalignment or access anomalies due to platform differences. This serialized BVH node array is written as read-only data to a designated area of ​​the structured buffer. Simultaneously, the root node index and total number of nodes of the BVH are recorded in a constant buffer for the shader to quickly locate the starting position. When performing ray-scene intersection calculations, the shader reads the BVH node content one by one from the structured buffer according to this predefined data format, which is completely consistent with the C++ side. A stack-based traversal algorithm is used to complete the efficient intersection test. The entire process does not rely on any platform-specific hardware acceleration structures, thus ensuring consistent geometric query behavior and results across different operating systems and graphics driver environments such as Windows and Linux. After the intersection is found, the shader, based on the vertex data and barycenter coordinates of the hit triangle, and combined with the original geometric information (such as vertex positions, normals, and material indexes) passed from the C++ host, derives a complete set of geometric intersection attributes. This includes the world space intersection position, surface normals, material indexes, and barycenter coordinates. This attribute set is then directly used for subsequent BRDF lighting model calls and color accumulation calculations. Since all geometric and material data is pre-injected from the C++ host, the shader does not need to post back or make additional requests. The entire intersection and attribute generation process is completed locally, ensuring data consistency and strengthening the separation of responsibilities between the C++ and shader.

[0041] S5: Introduces a cost analysis module to perform fine-grained statistics on C++ host-side scheduling overhead and shader execution load.

[0042] Among them, fine-grained statistics on C++ host-side scheduling overhead and shader execution load include using a cost analysis module in the C++ host-side ray tracing logic control framework to initiate GPU time queries through the RHI interface of the UE5 engine to obtain the actual load data of shader execution, which is then uniformly managed by the C++ host side.

[0043] Furthermore, to achieve precise control over rendering performance, a cost analysis module is embedded in the C++ host side. This module is deeply integrated into the ray tracing logic control framework and is used to perform fine-grained statistics on the computational overhead of each key component of the system. Specifically, this module inserts high-precision timers at key execution nodes on the C++ side (such as primary ray generation, secondary ray derivation, BVH construction, and buffer commit) to accurately collect the scheduling and processing time on the CPU side. Simultaneously, for shader execution load, the cost analysis module uses the RHI (Rendering Hardware Interface) time query function provided by the UE5 engine to initiate GPU timestamp queries before and after submitting ray tracing tasks in each frame, thereby obtaining the actual hardware execution time data of the shaders. If the current operating platform does not support precise GPU time queries (such as some Linux driver environments), the module will make reasonable estimates based on the number of submitted rays, average launch depth, and BRDF call frequency, combined with a pre-calibrated unit operation time model, to ensure statistical continuity. All collected performance data, including C++ scheduling overhead and shader execution load, is organized into structured log entries, uniformly managed and stored by the C++ host, and can be exported through the debugging interface to form a clear computational cost profile. The entire statistical process is entirely C++-driven, independent of shader feedback, ensuring decoupling between the analysis mechanism and the core rendering logic, while providing reliable data support for subsequent performance optimization, mode switching, or platform adaptation.

[0044] In a preferred embodiment, a ray tracing rendering system based on a C++ and shader separation architecture includes: a ray tracing logic control module, which builds a ray tracing logic control framework on the C++ host side, separating the ray tracing logic from the C++ host side and the shader; a low-level computation task execution module, which retains the low-level computation tasks related to GPU hardware on the shader side and exchanges data with the C++ host side through a standardized data interface defined and maintained by the C++ host side; a structured parameter passing and buffer scheduling module, which designs a unified structured rendering parameter passing and buffer scheduling mechanism, dynamically configured on the C++ host side, and passed to the shader; a BVH accelerated intersection module, which integrates the BVH accelerated intersection module on the C++ host side, combines the scene management system of the UE5 engine to perform cross-platform consistent geometry queries, and passes the intersection results to the shader through a predefined format; and a cost analysis module, which performs fine-grained statistics on the scheduling overhead of the C++ host side and the execution load of the shader.

[0045] The above-mentioned unit modules can be embedded in the processor of the computer device in hardware form or independent of it, or they can be stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of the above modules.

[0046] In one embodiment, a computer device is provided, which may be a terminal. The computer device includes a processor, memory, a communication interface, a display screen, and an input device connected via a system bus. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The communication interface of the computer device is used for wired or wireless communication with external terminals. Wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen of the computer device may be an LCD screen or an e-ink display screen. The input device of the computer device may be a touch layer covering the display screen, or buttons, a trackball, or a touchpad located on the casing of the computer device, or an external keyboard, touchpad, or mouse, etc.

[0047] In summary, this invention constructs a ray tracing rendering architecture that separates C++ and shaders. High-level logic such as path control, material interaction, and sampling scheduling is entirely centralized on the C++ host side, while the shaders only perform low-level tasks such as intersection, BRDF calculation, and color output. This significantly reduces system coupling and improves code maintainability and algorithm iteration efficiency. Through a unified structured rendering parameter passing and buffer scheduling mechanism, it supports dynamic switching and resource sharing between offline high-precision and real-time interactive rendering modes within the same system. The BVH accelerated intersection module integrates with the UE5 scene management system on the C++ side to achieve consistent geometric queries across platforms, avoiding repeated scene structure parsing on the shader side. Simultaneously, the introduced cost analysis module performs fine-grained statistics on C++ scheduling overhead and shader load, providing quantitative basis for performance optimization. The overall solution ensures physical realism while achieving high scalability, cross-platform consistency, and engineering feasibility, effectively supporting the efficient development and deployment of high-fidelity visualization and simulation applications.

[0048] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A ray tracing rendering method based on a C++ and shader separation architecture, characterized in that: include, A ray tracing logic control framework is built on the C++ host side, separating the ray tracing logic from the C++ host side and the shaders; The shader side retains the low-level computational tasks related to the GPU hardware and exchanges data with the C++ host side through a standardized data interface defined and maintained by the C++ host side; Design a unified structured rendering parameter passing and buffer scheduling mechanism, dynamically configure it on the C++ host side, and pass it to the shader; The BVH accelerated intersection module is integrated into the C++ host and combined with the scene management system of the UE5 engine to perform cross-platform consistent geometry queries and pass the intersection results to the shader in a predefined format. A cost analysis module is introduced to perform fine-grained statistics on C++ host-side scheduling overhead and shader execution load.

2. The ray tracing rendering method based on a C++ and shader separation architecture as described in claim 1, characterized in that: The ray tracing logic control framework built on the C++ host side includes establishing a path tracing scheduler independent of the rendering pipeline. The path tracing scheduler is responsible for managing the generation of the initial master ray starting from the camera viewpoint, determining whether to trigger reflection or refraction behavior based on the material type at each intersection point, and deciding whether to terminate the tracing path for secondary rays that need to be continued to be traced. The ray tracing logic control framework includes an integrated BRDF model calling interface. Each time a ray interacts with a surface, the C++ host selects the corresponding bidirectional reflection distribution function according to the material type, and generates the incident direction samples and probability density values ​​PDF required for Monte Carlo integration by combining the sampling strategy, and calculates the weight of the illumination contribution.

3. The ray tracing rendering method based on a C++ and shader separation architecture as described in claim 2, characterized in that: The process of separating ray tracing logic from the C++ host and shaders includes the C++ host submitting independent ray tasks to the rendering pipeline one by one by traversing the scene ray queue. Each independent ray undergoes only one shader call in its entire lifecycle to perform intersection and local lighting response calculations. The ray tracing logic is entirely retained on the C++ host side, forming a high-level control flow that works with the shaders. At the architectural level, the ray tracing logic is separated from the C++ host side and the shaders.

4. The ray tracing rendering method based on a C++ and shader separation architecture as described in claim 3, characterized in that: The retention of low-level computational tasks related to GPU hardware at the shader level includes the following: Perform ray-scene intersection operation based on BVH acceleration structure, determine whether the input ray intersects with the geometry in the scene and return the nearest intersection point; Based on the material index at the intersection, the corresponding attribute is read from the material parameter table passed from the C++ host, and the pre-compiled BRDF or PDF lighting model function is called to calculate the local lighting response. The color contributions from samples from multiple paths are summed. The synthesized color values ​​are written into the rendering target of the rendering pipeline to complete pixel output; The data exchange with the C++ host through a standardized data interface defined and maintained by the C++ host includes the C++ host being responsible for maintaining the standardized data interface throughout the rendering process. The standardized data interface includes a structured buffer and a constant buffer. The structured buffer is used to store the data structure of each independent ray, and the constant buffer is used to pass globally shared parameters; Before each frame of rendering begins, the C++ host serializes all the rays to be processed generated by the path tracing scheduler and writes them into the structured buffer, and synchronously updates the global configuration in the constant buffer. When the shader is executed, it accesses the structured buffer and constant buffer in read-only mode through the shader parameter binding mechanism provided by the UE5 engine. After completing a single intersection and lighting calculation based on the contents of the structured buffer, it directly outputs the result without sending intermediate state back to the C++ host or requesting new tasks.

5. The ray tracing rendering method based on a C++ and shader separation architecture as described in claim 4, characterized in that: The design of the unified structured rendering parameter passing and buffer scheduling mechanism includes defining a parameter classification system on the C++ host side during the initialization phase, and dividing the parameter classification system into frame-level global parameters and ray-level local parameters. Frame-level global parameters and ray-level local parameters are mapped to constant buffers and structured buffers respectively, and the layout is performed using memory alignment rules compatible with UE5 engine RHI. The dynamic configuration on the C++ host side includes dynamically configuring frame-level global parameters and ray-level local parameters at runtime according to the rendering mode specified by the user. In offline mode and real-time mode, dynamic configuration is completed by updating the contents of constant buffers respectively. The passing to the shader includes, before the start of each rendering frame, the C++ host calls the path tracing scheduler to generate all the ray tasks that need to be processed in the current frame, and serializes and fills the local parameters of each ray into the structured buffer; the global parameters corresponding to the current rendering mode are written into the constant buffer, and the structured buffer and the constant buffer are submitted to the shader through the unified resource binding interface provided by UE5; During execution, the shader determines which computation branch to enable based on the global configuration in the constant buffer, and reads the light data line by line from the structured buffer to perform intersection and lighting response.

6. The ray tracing rendering method based on a C++ and shader separation architecture as described in claim 5, characterized in that: The cross-platform consistent geometric query includes serializing the constructed BVH tree into a platform-independent linear memory layout on the C++ host side, with node data stored contiguously in depth-first order, and the linear memory layout used to follow the 8-byte alignment rule; The C++ host writes the serialized BVH node array as read-only data into the area of ​​the structured buffer, and records the BVH root node index and the total number of nodes in the constant buffer. When performing ray-scene intersection, the shader reads BVH node data from the structured buffer according to a predefined format and performs an intersection test; The step of passing the intersection result to the shader in a predefined format includes the shader using the geometric intersection attribute set for BRDF lighting calculation and color accumulation after completing the traversal; The geometric intersection attributes are all derived from the original geometric data and BVH structure passed from the C++ host.

7. The ray tracing rendering method based on a C++ and shader separation architecture as described in claim 6, characterized in that: The fine-grained statistics on C++ host-side scheduling overhead and shader execution load include, within the C++ host-side ray tracing logic control framework, using a cost analysis module to initiate GPU time queries through the UE5 engine's RHI interface to obtain actual shader execution load data, which is then uniformly managed by the C++ host.

8. A ray tracing rendering system based on a C++ and shader separation architecture, based on the ray tracing rendering method based on a C++ and shader separation architecture as described in any one of claims 1 to 7, characterized in that: include, The ray tracing logic control module builds the ray tracing logic control framework on the C++ host side, separating the ray tracing logic from the C++ host side and the shaders; The underlying computing task execution module retains the underlying computing tasks related to the GPU hardware on the shader side and exchanges data with the C++ host side through a standardized data interface defined and maintained by the C++ host side; The structured parameter passing and buffer scheduling module is designed with a unified structured rendering parameter passing and buffer scheduling mechanism, which is dynamically configured on the C++ host side and passed to the shader. The BVH accelerated intersection module integrates the BVH accelerated intersection module on the C++ host side, and combines it with the scene management system of the UE5 engine to perform cross-platform consistent geometry queries, and pass the intersection results to the shader through a predefined format; The cost analysis module performs fine-grained statistics on C++ host-side scheduling overhead and shader execution load.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the ray tracing rendering method based on a C++ and shader separation architecture as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the ray tracing rendering method based on the C++ and shader separation architecture as described in any one of claims 1 to 7.

Images