Random ray tracing for rendering digital assets

Abstract

Embodiments of the present disclosure relate to random ray tracing for rendering digital assets. Techniques are described for random ray tracing for rendering digital assets, and the techniques can be implemented to efficiently render digital assets within a scene. In an example, a digital asset is received, the digital asset including a transparent three-dimensional primitive to be included in a scene. Candidate intersections between rays traced from a viewpoint within the scene and one or more primitives are identified. An intersection is selected from the candidate intersections based on a binary opacity value determined for each of the candidate intersections and a distance value to the viewpoint. The digital asset within the scene is then rendered by applying a color value associated with the selected intersection to one or more pixels.

Description

Background Technology

[0001] Various techniques can be used to render digital assets, such as 3D models, scenes, and environments, to create realistic images. For example, ray tracing is used to simulate the path of light as it interacts with objects and surfaces in a scene, enabling the creation of realistic, high-fidelity images with accurate reflections, shadows, and global illumination. However, this process involves simulating a large number (e.g., millions) of ray-object intersections and light interactions, and therefore rendering digital assets using these techniques is often computationally expensive, especially rendering complex scenes with numerous objects and complex lighting conditions. Consequently, conventional ray tracing techniques are generally unsuitable for real-time applications (such as interactive games or virtual reality) and cannot be efficiently implemented by computing devices without sufficient processing power. Summary of the Invention

[0002] This paper describes a technique for random ray tracing used to render digital assets, which supports computationally efficient rendering and relighting of digital assets including various rendering primitives within a scene, such as transparent 3D primitives. In the example, a processing device receives a digital asset comprising 3D primitives (such as transparent primitives with Gaussian sputtering) to be included in the scene. The processing device identifies candidate intersections between rays traced from a viewpoint within the scene and one or more 3D primitives. The processing device selects an intersection from the candidate intersections based on a binarized opacity value determined for each candidate intersection and a distance value from each candidate intersection to the viewpoint. For example, the selected intersection is a candidate intersection that has been randomly determined by the processing device to be opaque and is the "closest" to the viewpoint.

[0003] The processing device then renders the digital assets within the scene by applying color values ​​associated with the selected intersection points to the pixels. This process can be repeated to determine the pixel color for each pixel in the image to depict the digital assets within the scene. Accordingly, the techniques described herein efficiently approximate the color values ​​for pixels through an educated random selection of representative intersection points. In this way, these techniques reduce memory usage and computational complexity compared to conventional techniques used for rendering 3D digital assets, while further maintaining high visual quality and supporting a variety of lighting effects and operations.

[0004] This summary presents a simplified description of the selection of concepts that will be further described in the detailed description below. Thus, this summary is not intended to identify the essential features of the claimed subject matter, nor is it intended to be used to help determine the scope of the claimed subject matter. Attached Figure Description

[0005] This patent or application document contains at least one color drawing. The Patent Office will provide a copy of this patent or patent application publication with (multiple) color drawings upon request and payment of the necessary fees.

[0006] The accompanying drawings provide a detailed description. The entities shown in the drawings refer to one or more entities, and therefore the singular or plural forms of the entities may be referred to interchangeably in the discussion.

[0007] Figure 1 This is an illustration of a digital media environment in an example implementation that is operable to employ the random ray tracing techniques described herein for rendering digital assets.

[0008] Figure 2 A more detailed description is shown. Figure 1 The system provides an example implementation of the rendering module's operations.

[0009] Figure 3 An example of random ray tracing used to render digital assets is depicted, where colors are determined for each pixel.

[0010] Figure 4 An additional example of random ray tracing used to render digital assets is depicted, where colors are determined for each pixel.

[0011] Figure 5 An additional example of random ray tracing for rendering digital assets is depicted, where multiple samples per pixel are used to determine the color for each pixel.

[0012] Figure 6 An example of random ray tracing for rendering digital assets is depicted, showing images generated using different per-pixel sampling values.

[0013] Figure 7 Examples of algorithms that can be used to perform various aspects of random ray tracing for rendering digital assets are described.

[0014] Figure 8 An example of random ray tracing used for rendering digital assets while changing the viewpoint of the scene is depicted.

[0015] Figure 9 This is a flowchart depicting the algorithm as a step-by-step procedure in an example implementation that can be executed by a processing device to render digital assets using the random ray tracing technique described herein.

[0016] Figure 10 It is a flowchart depicting the algorithm as a step-by-step procedure in an example implementation, which can be executed by a processing device to generate binarized opacity values.

[0017] Figure 11 The illustration shows an example system including various components of an example device, which can be implemented as shown in the reference. Figures 1-10 Any type of computing device described and / or utilized to implement embodiments of the techniques described herein. Detailed Implementation Overview

[0018] Conventional techniques used to render digital assets—such as visually depicting 3D objects, scenes, and environments—typically rely on ray tracing to simulate the path of light as it interacts with objects and surfaces in the scene. For example, using conventional ray tracing methods, the final pixel color is determined by tracing light rays that travel through the scene and accumulating color contributions from various intersections and light interactions as the light is reflected, refracted, scattered, absorbed, etc., within the scene. While this approach enables the creation of high-fidelity images with accurate lighting properties, these techniques depend on simulating a large number (e.g., millions) of ray-object intersections and light interactions.

[0019] Therefore, traditional ray tracing methods require a significant amount of processing to sort through each intersection along every ray to determine the color value for a single pixel. This is computationally expensive and memory-intensive, especially when rendering complex scenes or digital assets defined by millions of primitives. Consequently, the implementation of this technique is limited to dedicated processing devices with sufficient processing power. Furthermore, due to the high rendering time, conventional path tracing methods are generally unsuitable for real-time applications (such as interactive games or virtual reality / augmented reality), especially scenes involving digital objects with complex geometry.

[0020] Therefore, random ray tracing techniques for rendering digital assets are described to overcome conventional limitations. For example, the techniques described herein enable computationally efficient rendering of digital assets that include a variety of rendering primitives (e.g., transparent 3D primitives) within complex scenes. For instance, the techniques described herein randomly select a single representative intersection point based on opacity probability, thus avoiding the conventional requirement of sorting and processing multiple intersection points for rendering digital assets, while maintaining high visual quality of the output image.

[0021] Consider an example where a user with a processing device is designing an environment that includes complex scenes with objects of variable transparency (such as a futuristic cityscape with various vehicles, buildings, structures, light sources, etc.). The user wants to render this environment to support an interactive user experience (e.g., scene traversability) while maintaining high visual quality and accurate lighting effects. Rendering such a scene using traditional ray tracing techniques in a typical scenario would require significant computational resources and time, making it impractical for real-time dynamic applications, especially on devices with limited or standard processing power.

[0022] To overcome these limitations, the processing device receives digital assets that include 3D transparent rendered primitives to be included in the scene. For example, the digital asset represents a 3D model of a future car that the user expects to incorporate into a future scene. The car model is defined by multiple (e.g., hundreds of thousands, millions, etc.) rendered primitives, such as Gaussian sputtering defined by various properties that contribute to the final appearance of the car (e.g., depth values, opacity values, color values, etc.).

[0023] To integrate vehicles within the scene with accurate lighting conditions, the processing device identifies candidate intersections between rays traced from a viewpoint within the scene and one or more rendered primitives. In various embodiments, the processing device traverses an acceleration structure associated with the digital asset (such as a bounding volume hierarchy) to identify candidate intersections. For example, candidate intersections represent each intersection of a ray with a rendered primitive within the scene as light is scattered, reflected, refracted, absorbed, etc.

[0024] The processing device then selects an intersection from the candidate intersections based on the binarized opacity and depth values ​​(e.g., distance to the viewpoint) determined for each candidate intersection. For example, each candidate intersection corresponds to a rendered primitive associated with a depth value, an opacity value, and a color value. The processing device randomly determines whether to treat each candidate intersection as opaque or transparent by comparing randomly generated values ​​with the known opacity values ​​associated with each candidate intersection.

[0025] For example, if the random value for a particular candidate intersection is less than the opacity value, that particular candidate intersection is considered completely opaque. If the random value is greater than or equal to the opacity value, that particular candidate intersection is considered completely transparent. Therefore, each candidate intersection is assigned a binarized opacity value that classifies the candidate intersection as opaque or transparent, and is further associated with a depth value indicating the distance to the viewpoint.

[0026] The processing device then identifies the candidate intersection points "closest" to the viewpoint (e.g., the candidate intersection point with the smallest distance value among the candidate intersection points), which the processing device has randomly determined to be opaque. The processing device then applies the color value associated with the selected intersection point to the pixel. Because the selected intersection point is classified as completely opaque, the processing device ignores color contributions from subsequent intersection points (e.g., intersection points with larger distance values), as the selected opaque intersection point "blocks" light from reaching subsequent intersection points. Furthermore, the processing device ignores color contributions from intersection points preceding the selected intersection point, as these previous intersection points have already been classified as completely transparent and therefore do not affect the pixel's shadow.

[0027] This process can be repeated to determine the pixel color for each pixel in the image to depict digital assets within the scene. Furthermore, in some examples, the processing device iterates this process for each ray to select multiple intersections with multiple color values ​​and determines the final pixel color as the average of these multiple color values. In this way, the technique described herein also reduces noise and increases visual acuity.

[0028] In the context of the example above, the processing device implements the techniques described herein to efficiently render futuristic cars within a futuristic cityscape scene based on the scene's lighting characteristics. For example, the cars are depicted with realistic shading, reflections, shadows, etc., based on scene characteristics. Furthermore, the processing device is capable of implementing the process described above to render cars within the scene under various changing conditions, such as updating the car's appearance in real time as the user navigates the scene, maintaining consistent lighting and reflection characteristics from various angles and distances.

[0029] In this manner, the technique described in this paper overcomes the limitations of conventional techniques by efficiently approximating the color value for a pixel through an educated random selection of representative intersections, rather than calculating the color contribution for each intersection for a specific ray. Therefore, compared to traditional techniques for rendering 3D digital assets, this method reduces memory usage and computational complexity while maintaining high visual quality and supporting advanced lighting effects and manipulations. Consequently, the technique described in this paper enables real-time rendering of complex scenes with transparent primitives on a wide range of devices, including those with standard or limited processing power, thus expanding the possibilities for interactive applications and immersive experiences.

[0030] In the following discussion, an example environment employing the techniques described herein is described. Example programs executable in the example environment and other environments are also described. Therefore, the execution of the example programs is not limited to the example environment, and the example environment is not limited to the execution of the example programs. Example Environment

[0031] Figure 1This is an illustration of a digital media environment 100 in an example implementation, operable to employ the random ray tracing technique described herein for rendering digital assets. The illustrated environment 100 includes a computing device 102, which can be configured in various ways.

[0032] For example, computing device 102 may be configured as a processing device (such as a desktop computer, laptop computer), a mobile device (e.g., a assumed handheld configuration, such as the illustrated tablet or mobile phone), etc. Therefore, the range of computing device 102 extends from full-resource devices with basic memory and processor resources (e.g., personal computers, game consoles) to low-resource devices with limited memory and / or processing resources (e.g., mobile devices). Additionally, while a single computing device 102 is shown, computing device 102 also represents multiple different devices (such as those used by an enterprise to perform tasks such as…) Figure 11 The "cloud-based" operations described in the text refer to multiple servers.

[0033] Computing device 102 is illustrated to include a content processing system 104. The content processing system 104 is implemented at least partially in the hardware of computing device 102 to process and transform digital content 106, which is illustrated to be maintained in storage device 108 of computing device 102. Such processing includes creating, modifying, and rendering the digital content 106 in a user interface 110, for example, output by display device 112. Although illustrated to be implemented locally at computing device 102, the functionality of the content processing system 104 can also be configured, in whole or in part, via features available through network 114, such as portions of web services or “in the cloud.”

[0034] An example of the functionality of the content processing system 104 in processing digital content 106 is illustrated as a rendering module 116. The rendering module 116 is configured to generate a rendered asset 118 for display on the display device 112, such as based on an input 120 including digital asset 122. For example, the rendering module 116 receives an input 120 including digital asset 122, which is to be included (e.g., visually depicted) within a scene.

[0035] In some examples, digital asset 122 includes one or more three-dimensional models (e.g., objects, scenes, environments, etc.) to be rendered within a virtual space. For example, digital asset 122 includes various data, instructions, and / or mathematical representations that define three-dimensional objects, scenes, or environments in the virtual space. Thus, in various implementations, digital asset 122 includes information about the geometry, topology, material properties, spatial relationships, etc., of various elements within the virtual representation.

[0036] Digital asset 122 includes rendering primitives 124 that define various characteristics of digital asset 122. For example, rendering primitives 124 have varying opacities and thus include transparent, semi-transparent, and / or opaque rendering primitives 124. In various examples, rendering primitives 124 are three-dimensional and thus define aspects of the three-dimensional structure of digital asset 122. Rendering primitives 124 are also capable of describing various other properties of digital asset 122 (such as color, texture, reflectivity, material properties, etc.).

[0037] In various embodiments, the rendered primitives 124 include one or more Gaussian sputterings. For example, the Gaussian sputtering primitives are defined by one or more of the following: average position, covariance matrix determining shape and orientation, and / or attributes such as color and opacity values. These rendered primitives 124 can be used to represent complex geometries and visual effects. In various examples, a single digital asset 122 includes hundreds of thousands to millions of transparent, anisotropic 3D Gaussian rendered primitives 124 with view-dependent color and / or shading attributes.

[0038] This is done by way of example and not as a limitation, and in some examples, rendering primitive 124 includes one or more polygons, voxels, point clouds, implicit surfaces, parametric curves and surfaces, and / or other geometric elements that define the visual characteristics and / or structure of digital asset 122. In at least one example, rendering primitive 124 includes two-dimensional primitives associated with depth values ​​(e.g., a two-dimensional disk with a depth definition). Therefore, the techniques described herein can be integrated into various rendering pipelines.

[0039] As described in more detail below, rendering module 116 is operable to generate rendered asset 118 in a computationally efficient manner, such as by implementing the random ray tracing technique described herein. For example, rendering module 116 may randomly select representative intersections between traced rays and rendered primitives 124 based on opacity probabilities, and color / relight the rendered asset 118 based on these representative intersections. In this way, rendering module 116 efficiently approximates color values ​​for pixels without the conventional computational burden of calculating color contributions for each intersection along each ray. Therefore, compared to conventional ray tracing techniques, rendering module 116 supports the generation of high-quality rendered asset 118 with reduced computational complexity.

[0040] For example, as depicted in the illustrated example, computing device 102 receives input 120 including digital asset 122. In this example, digital asset 122 is a representation of a model car and includes various rendering primitives 124 (e.g., transparent 3D Gaussian primitives) defining various characteristics of the model car. Using the random ray tracing technique described herein, rendering module 116 generates rendered asset 118 within the scene, which is output for display in user interface 110 of display device 112 as illustrated.

[0041] In this example, rendering module 116 also receives additional input to modify the conditions of the scene, including the rendered asset 118. For example, the user provides input to edit the camera view of digital asset 122 (such as repositioning the virtual camera to view the model car "face-on"). Rendering module 116 implements random ray tracing techniques to render the edited asset 126 in real time, utilizing updated visual characteristics based on the changing conditions of the scene. Therefore, the techniques described herein support interactive experiences for creating and modifying complex 3D scenes that are impossible to perform in real time using conventional techniques on devices with standard and / or limited GPU resources. Further discussion of these and other advantages is included in the following sections and is illustrated in the corresponding figures.

[0042] Generally, the functions, features, and concepts described in the examples described in this section are used in the context of the examples above and below. Furthermore, the functions, features, and concepts described with respect to the different figures and examples in this document are interchangeable and are not limited to their implementation in the context of a particular figure or program. Moreover, the boxes associated herein with different representative programs and corresponding figures can be applied and / or combined in different ways. Therefore, the individual functions, features, and concepts described herein with respect to different example environments, devices, components, figures, and programs can be used in any suitable combination and are not limited to the specific combinations represented by the examples listed in this description.

[0043] The following discussion describes techniques that can be implemented using the systems and devices described above. Each aspect of the program is implemented in hardware, firmware, software, or a combination thereof. The program is shown as a set of boxes specifying operations to be performed by one or more devices, and is not required to be limited to the order in which the operations are performed by the respective boxes. For example, blocks of the program specify operations programmable by hardware (e.g., processor, microprocessor, controller, firmware) as instructions, thereby creating a dedicated machine for executing the algorithm as illustrated in the flowchart. Thus, the instructions can be stored on a computer-readable storage medium that causes the hardware to execute the algorithm. Reference will be made to the following sections of the discussion. Figures 1-10 .

[0044] Figure 2 A more detailed description is shown. Figure 1 The system 200 is an example implementation of the operation of the rendering module 116. Generally, the rendering module 116 is configured to generate rendered assets 118 within the scene using a random ray tracing method. The rendering module 116 can also be operated to generate edited assets 126, such as based on various inputs used to change conditions of the scene. In this example, the rendering module 116 includes a structure module 202, an intersection module 204, a sampling module 206, a shading module 208, an editing module 210, and a noise reduction module 212, which interact with each other to perform the operations described herein. Digital asset processing and intersection determination

[0045] For example, rendering module 116 receives input 120 including digital asset 122 to be included in the scene. As described above, digital asset 122 is defined by one or more rendering primitives 124. For example, digital asset 122 is a Gaussian asset, and rendering primitives 124 include various transparent 3D Gaussian sputterings defining one or more objects, elements, structures, etc., to be rendered within the scene. Rendering primitives 124 are also associated with values ​​that define the visual properties of digital asset 122 under variable conditions, and thus support relighting and visualization within various scenes.

[0046] To this end, the structure module 202 first generates an acceleration structure 214 that organizes the rendering primitives 124. In various implementations, the acceleration structure 214 is a hierarchical bounding volume (“BVH”) that allows traversal to identify the intersections between traced rays (e.g., ray 216) and the rendering primitives 124. In this example, the intersection module 204 constructs the BVH by generating an axis-aligned bounding box (“AABB”) that encapsulates a single rendering primitive 124.

[0047] For each rendered primitive 124 (e.g., Gaussian sputtering), an AABB is calculated to approximate the spatial extent of the rendered primitive 124. For example, the spatial extent extends to a predetermined standard deviation; beyond this standard deviation, the rendered primitive 124 is considered negligible. Structure module 202 also hierarchically groups individual AABBs into larger bounding volumes to form a tree structure with a single root node encompassing the digital asset 122. This hierarchical organization of the acceleration structure 214 allows for testing of rays 216 against progressively smaller volumes and supports efficient pruning of portions of the scene and / or rendered primitive 124 that are outside the spatial extent and do not intersect with rays 216, thereby reducing the computational complexity of intersection testing.

[0048] For example, the intersection module 204 processes the ray 216 traced from the viewpoint within the scene and determines candidate intersection points 218 between the ray 216 and the rendered primitives 124. For instance, as a particular ray 216 propagates through the scene, it interacts with various rendered primitives 124 through reflection, refraction, scattering, or absorption, and thus intersects with multiple rendered primitives 124. Accordingly, in various examples, the ray 216 is associated with multiple candidate intersection points 218, such as dozens, hundreds, thousands, etc.

[0049] In the example where acceleration structure 214 includes BVH, intersection module 204 traverses acceleration structure 214 and returns candidate intersections 218 in an unsorted and / or semi-sorted “BVH order”. For example, candidate intersections 218 do not need to be sorted by viewpoint depth. Conventional ray tracing methods rely on sorting these intersections by depth to correctly calculate color contributions, which is computationally expensive and memory-intensive, especially for scenes with thousands of intersections per ray. However, the method described herein avoids the conventional need to sort candidate intersections 218 and instead shades pixels based on the nearest opaque intersection, as further described below. This significantly reduces computational complexity and memory usage, allowing system 200 to efficiently render digital assets 122 on-device within a scene without advanced processing power.

[0050] The intersection module 204 also determines characteristics (such as depth value 220, opacity value 222, and color value 224) associated with each of the candidate intersections 218. For example, these characteristics are obtained by the intersection module 204 based on the phase rendering primitive 124 associated with each candidate intersection 218. For instance, the depth value 220 represents the distance from the viewpoint along ray 216 to the candidate intersection 218. In various implementations, the depth value 220 is the mean of a 1D Gaussian along ray 216 and / or based on the projection center of the rendering primitive 124. As further described below, when multiple opaque intersections are identified, the depth value 220 is used to determine which candidate intersection 218 is closest to the viewpoint.

[0051] For example, the opacity value 222 is a debinarized value that represents the transparency of the rendered primitive 124 at candidate intersection 218. For example, the opacity value has a range from 0 (e.g., completely transparent) to 1 (e.g., completely opaque). Therefore, a debinarized opacity value 222 falling between 0 and 1 indicates that the rendered primitive 124 is semi-transparent / semi-opaque, and thus transmits some light and blocks some light. As described in more detail below, the opacity value 222 can be used to determine whether candidate intersection 218 is considered opaque or transparent during the opacity binarization process. For example, a rendered primitive 124 with an opacity value 222 of 0.8 has an 80% probability of being considered completely opaque and a 20% probability of being considered completely transparent.

[0052] For example, color value 224 represents visual appearance information (such as RGB values, HSV values, or other color space representations) associated with candidate intersection 218. In some examples, color value 224 includes view-dependent color, material properties, lighting effects, and / or other visual characteristics that determine how portions of rendered primitive 124 appear when rendered under varying conditions. In one example, for a red appearance, color value 224 is represented as (R: 255, G: 0, B: 0), or for a green appearance, color value 224 is represented as (R: 0, G: 255, B: 0). In one or more implementations, color value 224 represents the result of an evaluation of rendered primitive 124 (e.g., Gaussian primitive) at a shading location defined by a corresponding depth value 220, such as an evaluation of light transport associated with the Gaussian primitive at the shading location.

[0053] Therefore, the rendering module 116 efficiently organizes and processes the rendering primitives 124, and is also operable to determine various characteristics of the candidate intersections 218 that can be used in the random sampling and shading process described in the following discussion. Random coloring value determination

[0054] Conventional ray tracing techniques require each ray intersection to be sorted by depth and evaluated individually for its color contribution, demanding significant GPU processing resources. However, the technique described in this paper bypasses this step by probabilistically determining a reduced number of candidate intersections 218 to colorize pixels, thus saving processing resources compared to conventional methods.

[0055] For example, rendering module 116 includes sampling module 206 operable to generate a random value 226 for each candidate intersection 218, and also to generate a binarized opacity value 228 for each candidate intersection 218 based on the random value 226 and an opacity value 222. Rendering module 116 also includes shading module 208 operable to select one or more candidate intersections 218 based on the binarized opacity value 228 and a depth value 220. The selected candidate intersections 218 (e.g., one or more shading intersections 230) are then used by shading module 208 to determine pixel color 232 to generate rendered asset 118.

[0056] For example, each ray 216 traced from the viewpoint corresponds to a pixel. The shading module 208 identifies at least one shading intersection 230 for each ray 216, which can be used to determine the pixel color 232 of the corresponding pixel based on a binarized opacity value 226 and a random value 226.

[0057] In an example of doing so, consider a specific ray 216 that traces from the viewpoint through a specific pixel and into the scene. The intersection module 204 identifies a set of candidate intersections 218 between the specific ray 216 and the rendered primitive 124. The sampling module 206 is operable to determine an opacity value 222 (e.g., a debinarized value between 0 and 1) associated with each candidate intersection 218 in the set. In some examples, this includes an evaluation of the rendered primitive 124 corresponding to the specific candidate intersection 218.

[0058] The sampling module 206 can also be operated to generate a random value 226 for each candidate intersection 218 in the set. The random value 226 is, for example, a random number having a value within the range of the potential opacity value 222. For example, if the opacity value 222 has a range of 0 to 1, the random value 226 will also be between 0 and 1. In various implementations, the sampling module 206 utilizes one or more suitable random number generators and / or random number generation techniques / processes to generate the random value 226.

[0059] Based on the determined opacity value 222 and random value 226, sampling module 206 can also operate to generate a binarized opacity value 228 for each candidate intersection 218 in the set. For example, sampling module 206 compares the random value 226 for a particular candidate intersection 218 with the opacity value 222 for that particular candidate intersection 218. In an example where the random value 226 is less than a threshold, such as less than the opacity value 222, the binarized opacity value 228 is set to 1, indicating that the particular candidate intersection 218 is completely opaque. In an example where the random value 226 is greater than or equal to a threshold (e.g., greater than or equal to the opacity value 222), the binarized opacity value 228 is set to zero, indicating that the particular candidate intersection 218 is completely transparent.

[0060] Therefore, the opacity value 222 is used as a weighted average to influence the random determination based on the known visual characteristics of the digital asset 122 within the scene. For example, candidate intersections 218 with relatively high opacity values ​​222 have a greater probability of being considered completely opaque. Similarly, candidate intersections 218 with relatively low opacity values ​​222 have a greater probability of being considered completely transparent, which aligns with the nascent visual characteristics of the digital asset 122.

[0061] In this manner, the sampling module 206 is operable to probabilistically determine, for each candidate intersection 218 in the set, whether it is completely opaque or completely transparent, based on the opacity value 222 associated with the candidate intersection 218 and a random value 226. This opacity-informed random determination allows the system 200 to effectively approximate the overall visual effect of the digital asset 122 within the scene without processing each candidate intersection 218 in depth order. Therefore, these techniques reduce computational complexity by processing a subset of candidate intersections 218 that are most likely to contribute to the final pixel color 232, while maintaining the visual integrity of the rendered asset 118.

[0062] For example, the coloring module 208 determines a coloring intersection 230 from candidate intersections 218 based on a binary opacity value 226 and a depth value 220. Continuing the example above, coloring intersection 230 represents the "closest to opaque" candidate intersection 218 from the set of candidate intersections 218. For example, coloring intersection 230 has the lowest depth value 220 among candidate intersections 218, and its binary opacity value is 1.

[0063] In one or more examples, the coloring module 208 processes candidate intersections 218 in the order of the output set by the intersection module 204 (such as a semi-sorted "BVH" order). For example, the candidate intersections 218 are "loosely" sorted by depth within the set, but not completely sorted. The coloring module 208 evaluates each candidate intersection 218 with its corresponding binary opacity value 228. If the binary opacity value 228 for a particular candidate intersection 218 is zero (which indicates transparency), the coloring module 208 ignores that particular candidate intersection 218 and proceeds to the next candidate intersection 218 in the set.

[0064] The shading module 208 continues until it encounters a specific candidate intersection 218 with a binarized opacity value 228 of 1 (indicating opacity). The shading module 208 then selects this specific candidate intersection 218 as the shading intersection 230. The shading module 208 continues processing the remaining candidate intersections 218 in the set to determine whether an additional candidate intersection 218 is opaque and whether it is closer to the viewpoint than the shading intersection 230, for example, whether it has a relatively small depth value 220. If so, the shading module 208 is operable to replace the shading intersection 230 with the additional candidate intersection 218.

[0065] In some examples, the shading module 208 is operable to abort processing of remaining candidate intersections 218 whose depth value 220 is greater than the depth value 220 associated with the current shading intersection 230. In this way, the shading module 208 further saves computational resources and reduces memory usage by preventing the system 200 from processing and / or storing information about subsequent candidate intersections 218 that will be occluded by the shading intersection 230. This is by way of example and not limitation, and various orders and patterns for processing candidate intersections 218 are considered.

[0066] The shading module 208 then determines the pixel color 232 to be applied to the pixel based on the shading intersection 230. For example, the shading module 208 determines the pixel color 232 as the color value 224 associated with the shading intersection 230. In at least one example, the shading module 208 determines the pixel color 232 by evaluating the rendering primitive 124 associated with the shading intersection 230 at the shading intersection 230.

[0067] In one or more examples, the shading module 208 accesses color information (such as RGB values ​​and / or additional or alternative color space representations) stored by the associated rendering primitive 124. The shading module 208 is also operable to adjust the pixel color 232 (e.g., based on the characteristics of the digital asset 122, lighting conditions in the scene, and / or additional environmental factors). For example, the shading module 208 may be operable to calculate how a light source interacts with the surface characteristics of the rendering primitive 124 at the shading intersection 230 and adjust the pixel color 232 accordingly.

[0068] In an example where rendering primitive 124 includes Gaussian primitives, shading module 208 is operable to evaluate the light transmission of the Gaussian primitive at shading intersection 230 to determine pixel color 232. For example, shading module 208 calculates color value 224 and / or pixel color 232 based on: surface properties of the Gaussian primitive, opacity and / or color attributes of the Gaussian primitive at shading intersection 230, direction of incident light, viewpoint from a virtual camera, material properties associated with the Gaussian primitive (e.g., reflectivity, specularity, roughness, etc.), shadows cast by other objects in the scene, light scattering within the Gaussian primitive, or subsurface effects, etc. In some implementations, shading module 208 tracks additional light rays from shading intersection 230 to calculate secondary lighting effects (such as shadows, reflections, or global illumination contributions) that affect the final pixel color 232. As described in more detail below, in some examples, rendering module 116 tracks multiple rays 216 per pixel and averages the resulting pixel color 232 to reduce noise and improve the visual quality of the final output.

[0069] Through iterative processing, shading module 208 generates rendered asset 118. For example, rendering module 116 utilizes structure module 202, intersection module 204, sampling module 206, and shading module 208 to process multiple rays 216 traced through the scene, where each ray 216 corresponds to a pixel in the final rendered image, such as a pixel in rendered asset 118. For each ray 216, rendering module 116 implements the techniques described herein to identify candidate intersections 218, determine binarized opacity values ​​228, select shading intersections 230, and calculate pixel colors 232. Rendering module 116 is configured to perform this process for each pixel in the image, where the set of determined pixel colors 232 forms rendered asset 118. Thus, rendered asset 118 depicts a digital asset 122 integrated within the scene, featuring realistic lighting, color, reflections, and shadows based on the scene's lighting conditions.

[0070] The techniques described herein also support editing and / or relighting operations, such as applying various changes to the scene and / or rendered assets 118 and generating edited assets 126 that retain a realistic visual appearance based on the scene's lighting conditions. For example, rendering module 116 includes editing module 210 that receives edits 234 to change the conditions of the scene. Edits 234 include adjustments such as: modifying the viewpoint, changing lighting conditions, adding / removing elements or assets from the scene, applying changes to rendered assets 118, etc.

[0071] Editing module 210 is operable to render edited asset 126 within a scene with altered conditions by implementing the random ray tracing technique described above. Consider an example where the virtual camera angle is adjusted to view the rendered asset 118 from different perspectives. Editing module 210 processes the updated viewpoint, traces rays from the updated viewpoint, identifies additional candidate intersections 218, and determines updated pixel colors 232 based on updated shading intersections 230 (e.g., the nearest opaque candidate intersection 218 from the updated viewpoint). In this way, the technique described herein enables real-time visualization of digital asset 122 from multiple perspectives while maintaining consistent lighting and material properties.

[0072] In additional or alternative examples, editing 234 includes changes to the lighting conditions of the scene (such as adjusting the intensity, color, or position of light sources within the scene). Editing module 210 is operable to generate edited asset 126 by determining updated pixel colors 232 based on the changed lighting conditions. For example, shading module 208 considers the updated lighting parameters to evaluate the light transport associated with the rendered primitive 124 at each shading intersection 230. For example, editing module 210 adjusts the color values ​​224 associated with shading intersections 230 to reflect changes in direct lighting, shadows, indirect lighting effects, etc. Therefore, the techniques described herein support computationally efficient relighting and editing operations while maintaining visual fidelity and realism.

[0073] In various examples, rendering module 116 also includes a denoising module 212 operable to implement various techniques to enhance the quality of rendered asset 118. For example, denoising module 212 is configured to control the number of samples per pixel (SPP) to reduce noise artifacts. For example, denoising module 212 causes sampling module 206 and shading module 208 to perform multiple traversals of ray 216, such as identifying different shading intersections 230 in each iteration. Shading module 208 is then able to average the pixel colors 232 obtained from the multiple traversals. Thus, denoising module 212 is operable to perform multiple sampling within a single ray traversal to effectively improve visual quality while maintaining computational performance. This will be discussed below regarding... Figure 5 The examples shown are discussed in more detail.

[0074] Consider various other noise reduction strategies that can be implemented by the noise reduction module 212. In one or more examples, two or more intersections are selected from candidate intersections 218 for each ray 216 (e.g., in a single traversal) and the average color value between the color values ​​associated with the two or more selected intersections. In additional or alternative examples, the noise reduction module 212 utilizes spatial and / or temporal filtering techniques to further optimize the rendered output and reduce visual artifacts.

[0075] In various examples, system 200 and / or rendering module 116 are integrated into one or more rendering frameworks. For example, the techniques described herein support the processing of 3D primitives such as Gaussian sputtering within a Monte Carlo path tracing framework. This integration enables the rendering of Gaussian sputtering alongside traditional mesh-based assets with consistent global illumination effects.

[0076] Figure 3 Example 300 of random ray tracing for rendering digital assets is depicted, where colors are determined for pixels. For example, example 300 depicts a traced ray 302 that originates from viewpoint 304 and intersects six rendering primitives 124, which in this example are three-dimensional transparent Gaussian sputtered primitives.

[0077] According to the techniques described herein, rendering module 116 generates candidate intersection points 218 for each rendered primitive 124 encountered by the tracked ray 302 as it propagates through the scene, such as a first intersection point 306, a second intersection point 308, a third intersection point 310, a fourth intersection point 312, a fifth intersection point 314, and a sixth intersection point 316. Based on a three-dimensional Gaussian sputtering that defines the rendered primitives 124 in the scene, each intersection point is associated with a depth value 220, an opacity value 222, and a color value 224. The depth axis 318 indicates the relative depth of each intersection point. For example, the depth axis 318 indicates that the sixth intersection point 316 is farther from the viewpoint 304 along the path or ray 302 than the first intersection point 306.

[0078] For each candidate intersection point 218, the rendering module 116 generates a binarized opacity value 228, which is represented in this example as Such as based on an opacity value 222 and a random value 226 associated with each corresponding intersection point. In this example, the binarized opacity value 228 can be defined as:

[0079] As illustrated, the first intersection point 306, the second intersection point 308, the fourth intersection point 312, and the sixth intersection point 316 are assigned a binarized opacity value 228 of 0. For rendering purposes, this binarized opacity value 228 indicates that these intersection points are considered completely transparent. The third intersection point 310 and the fifth intersection point 314 are assigned a binarized opacity value 228 of 1. For rendering purposes, this indicates that these intersection points are considered completely opaque.

[0080] Rendering module 116 selects a third intersection point 310 as the shading intersection point 230 based on a depth value 220 and a binarized opacity value 228. For example, among the intersection points with a binarized opacity value of 1, the third intersection point 310 has the lowest depth value 220. That is, the third intersection point 310 is the opaque intersection point closest to the viewpoint 304.

[0081] Accordingly, rendering module 116 determines a color value 224 associated with the shading intersection 230 under the conditions applied to digital asset 122. Rendering module 116 then assigns the color value 224 as pixel color 232 and applies pixel color 232 to pixel 320. As illustrated, pixel 320 is rendered using the green of the third Gaussian primitive. Rendering module 116 is also capable of repeating this process to render each pixel of an image depicting digital asset 122 within a scene. In one or more examples, the shading (e.g., color value 224) may be represented as:

[0082] When excluding candidate intersections with a greater depth value of 220, the coloring can be further simplified to:

[0083] Figure 4 Additional example 400 depicts random ray tracing for rendering digital assets, where colors are determined for each pixel. For example, example 400 depicts the above-mentioned... Figure 3 The second iteration of the described random ray tracing technique.

[0084] Similar to Example 300 above, in this Example 400, rendering module 116 generates a binarized opacity value 228 for each intersection point. However, because the binarized opacity value 228 is determined probabilistically based on the opacity value 222 associated with the corresponding intersection point and a random value 226, in this example, the first intersection point 306 and the fifth intersection point 314 are considered completely opaque. Because the first intersection point 306 is relatively closer to the viewpoint 304 than the fifth intersection point 314, rendering module 116 selects the first intersection point 306 as the shading intersection point 230.

[0085] Rendering module 116 determines the color value 224 associated with the shading intersection 230 and assigns this value as pixel color 232. Rendering module 116 then applies pixel color 232 to pixel 320, which in this example 400 is red based on the first Gaussian primitive. In this way, rendering module 116 renders pixels of transparent primitives without having to sort and process each intersection along the light rays in a conventional manner.

[0086] Figure 5Additional example 500 for rendering random ray tracing of digital assets is depicted, in which multiple samples per pixel are used to determine the color for the pixel. In this example 500, rendering module 116 generates multiple samples for each ray (e.g., multiple shading intersections 230 for ray 302) and determines an average color value for pixel shading.

[0087] For example, in the first iteration 502, the rendering module 116 selects the second intersection 308 as the first tinted intersection 506 based on the binarized opacity value 228 and depth value 220 associated with the candidate intersection 218. For example, the second intersection 308 is the closest opaque intersection in the first iteration 502. The rendering module 116 also determines a first color value 508 associated with the first tinted intersection 506.

[0088] In the second iteration 504, the rendering module 116 selects a first intersection 306 as the second shading intersection 510 according to the techniques described herein. For example, the first intersection 306 is the closest opaque intersection in the second iteration 504. The rendering module 116 also determines a second color value 512 associated with the second shading intersection 510. The rendering module 116 then determines an average color value 514 based on the first color value 508 and the second color value 512. The rendering module 116 uses the average color value 514 to determine the pixel color 232 for rendering pixel 320. As illustrated, the pixel color 232 is orange, for example, a combination of the first color value 508 (e.g., yellow) and the second color value 512 (e.g., red).

[0089] Therefore, the rendering module 116 is operable to generate multiple samples and average them to reduce noise artifacts and improve the overall image quality within a single traversal of the acceleration structure 214. For example, as the number of samples per pixel increases, the averaged color value 514 converges to an accurate representation of the true color. Furthermore, the computational cost of generating additional samples is relatively small compared to conventional ray tracing methods. This balance between quality enhancement and computational efficiency supports the production of high-quality rendering while maintaining interactivity and accessibility across various processing devices.

[0090] In at least one example, coloring based on multiple samples per pixel (e.g., an average color value of 514) is represented as: Where N is the number of evaluations, for example, how many times a particular ray 216 is independently tracked.

[0091] Figure 6Example 600 depicts random ray tracing for rendering digital assets, illustrating images generated using different per-pixel sampling values. For example, Example 600 describes image noise levels at different per-pixel sampling (“spp”) settings. In this example, each row of the image represents the rendering at increasing spp values, such as from 1 spp to 4 spp to 16 spp to 64 spp.

[0092] By way of example, a first image 602 is generated using 1 spp, while a second image 604 is generated using a higher spp value (e.g., 64 spp). The first image 602 and the second image 604 depict essentially the same scene of a living room; however, they have different noise levels due to the different number of samples used. For example, as the spp value increases from the first image 602 to the second image 604, the rendering quality improves and the noise level decreases. As illustrated, the first image 602 exhibits visible noise artifacts, such as graininess or speckling, especially in areas with complex lighting or fine details. Conversely, the second image 604 shows reduced noise and improved sharpness.

[0093] Accordingly, the rendering module 116 can be configured to generate images with varying spp settings. In some examples, lower spp settings are preferred, such as for real-time rendering or interactive applications where rapid frame updates take precedence over image quality. In additional or alternative examples, relatively higher spp settings are used for applications where image fidelity is prioritized. This flexibility allows the system 200 to adapt to various use cases and hardware capabilities, and supports a balance between performance and visual quality based on specific requirements or user preferences.

[0094] Figure 7 Example 700 of algorithm 702 is described, which can be used to perform various aspects of random ray tracing for rendering digital assets.

[0095] In various implementations, rendering module 116 implements algorithm 702 to perform one or more aspects of random ray tracing techniques. For example, rendering module 116 utilizes algorithm 702 to identify shading intersections 230 and to shade pixels based on shading intersections 230. In this example, algorithm 702 includes receiving a representation of... p The "IntersectCallback" function of rendering primitive 124, which in this example is its bounding box and represented as r The light rays 216 interact with each other at specific candidate intersection points 218 via Gaussian sputtering.

[0096] Rendering module 116 implements algorithm 702, which first calculates along the ray... r The 1D Gaussian, and further retrieved along the rayr The 1D Gaussian average. In various implementations, Algorithm 702, for example, uses... t and r.t min and r.t max A comparison is made to determine whether a specific candidate intersection point 218 is outside the effective ray range. If the specific candidate intersection point 218 is outside the range, the rendering module 116 ignores the intersection point. The rendering module 116 further utilizes algorithm 702 to use the "isNegligible" function to determine whether the specific candidate intersection point 218 is negligible. If the specific candidate intersection point 218 is negligible, the program ignores the intersection point. In the case where the specific candidate intersection point 218 is not negligible, algorithm 702 is implemented to calculate the intersection point position based on the ray origin, direction, and t value. q ".

[0097] Rendering module 116 then implements algorithm 702 to generate a binarized opacity value 228 for a specific candidate intersection point 218. This includes generating a random value 226 (denoted as "𝜉") and comparing the random value 226 with the opacity value 222 associated with the specific candidate intersection point 218. In various implementations, algorithm 702 utilizes a stateless pseudo-random number generator to generate the random value 226. The stateless pseudo-random number generator is used via the RNG function. q This method uses a seed to generate random numbers. It allows for efficient generation of random numbers without the need for state maintenance between calls, which is beneficial for parallel processing on graphics hardware such as GPUs.

[0098] Algorithm 702 combines the random value 𝜉 with p Compare .α (e.g., the opacity value 222 associated with a specific candidate intersection 218). If α is greater than p If .α, then the intersection is rejected using a "Russian Roulette" selection. For example, an intersection is marked as "transparent" and therefore excluded from the selection. If the intersection is not rejected, Algorithm 702 then... t The report intersection will be r. tmax Shrink to t The intersection point is then colored in the ray-hitting procedure using the "reportIntersection" function. This step ensures that the closest accepted intersection point is processed for coloring.

[0099] In some implementations, rendering module 116 adjusts the depth calculation in algorithm 702 to match one or more rasterization techniques. For example, rendering module 116 calculates the depth value 220 based on the projection center of a 3D Gaussian instead of using the distance from the origin of the ray to the shading location. By aligning the depth calculation with the rasterization method, algorithm 702 ensures consistency between ray tracing and rasterized rendering of the same scene.

[0100] Figure 8 Example 800 depicts random ray tracing for rendering digital assets, where the viewpoint of the scene is changed. Example 800 includes a first view 802, a second view 804, a third view 806, and a fourth view 808 of the scene, which includes various rendered assets 118.

[0101] In some implementations, rendering module 116 receives editing 234 to change the conditions of a scene that includes digital assets defined by rendering primitives. In the illustrated example 800, editing 234 includes actions that change the viewpoint of a virtual camera within the scene. For example, various digital assets 122 (e.g., a cup, a French press, coffee beans, etc.) are initially rendered in a first view 802. Rendering module 116 receives input to change the viewpoint to a second view 804, then to a third view 806, and finally to a fourth view 808.

[0102] Following the techniques described herein, rendering module 116 is operable to render various digital assets 122 within a scene in a computationally efficient manner based on changing conditions (e.g., a changed viewpoint) while maintaining visual fidelity and realistic lighting effects. In this example, rendering module 116 generates edited assets 126 by processing the updated viewpoint, tracing rays from the updated viewpoint, identifying additional candidate intersections 218, and determining updated pixel colors 232 based on updated shading intersections 230 (e.g., the closest opaque candidate intersection 218 along the ray to the updated viewpoint).

[0103] Therefore, the technique described in this paper is applicable to changes in viewpoint, object behavior, and scene composition. This method allows for interactive editing and visualization of complex scenes with multiple transparent primitives, offering advantages over conventional rendering techniques that do not support real-time updates of scenes containing multiple semi-transparent objects.

[0104] Figure 9 This is a flowchart depicting the algorithm as a step-by-step procedure 900 in an example implementation, which can be executed by a processing device to render digital assets using the random ray tracing technique described herein.

[0105] In this example, we begin by receiving digital assets that include rendering primitives contained within the scene (box 902). For example, digital asset 122 includes 3D primitives with varying transparency (such as Gaussian sputtering that defines the characteristics of objects to be rendered within the scene). In various implementations, rendering primitive 124 includes information about the geometry, color, opacity, and other visual properties of the objects.

[0106] Next, candidate intersections (box 904) between the rays traced from the viewpoint within the scene and one or more rendered primitives are identified. For example, rendering module 116 traverses acceleration structure 214 associated with digital asset 122 to determine candidate intersections 218 between rays 216 and rendered primitives 124. In some examples, acceleration structure 214 organizes rendered primitives 124 in a hierarchical manner, such as improving the efficiency of intersection identification.

[0107] Next, based on the binarized opacity value determined for each candidate intersection point and the distance value from each candidate intersection point to the viewpoint, an intersection point is selected from the candidate intersection points (box 906). For example, rendering module 116 generates a binarized opacity value 228 for each candidate intersection point 218 based on the opacity value 222 associated with each candidate intersection point 218 and a random value 226. The binarized opacity value 228 indicates whether the candidate intersection point 218 is considered completely opaque or completely transparent.

[0108] The rendering module 116 then selects candidate intersection points 218 (e.g., shading intersection points 230) based on the binarized opacity value 228 and the depth value 220. In various examples, the shading intersection point 230 is selected as the intersection point closest to the viewpoint determined to be opaque (e.g., having a binarized opacity value 228 equal to 1) (e.g., the candidate intersection point 218 with the minimum depth value 220).

[0109] The digital assets within the scene are then rendered (box 908) by applying color values ​​associated with the selected intersections to the pixels. For example, rendering module 116 determines color value 224 based on the characteristics of the rendered primitive 124 associated with the shading intersection 230. Rendering module 116 then applies color value 224 to the corresponding pixels in the rendered image, which includes the rendered asset 118. This process can be repeated to color each pixel within the image to depict the rendered asset 118 within the scene.

[0110] In some examples, edits are received to change the conditions of the scene (box 910). In various examples, edits 234 include adjusting the viewpoint, modifying lighting conditions, and / or adding or removing elements from the scene.

[0111] The digital asset is then rendered within the scene with the changed conditions (box 912). For example, rendering module 116 iterates the process described above (e.g., boxes 904-908) to identify additional candidate intersections 218, select additional shading intersections 230, and apply updated color values ​​224 to pixels to realistically depict the edited asset 126 with the updated scene conditions applied.

[0112] Figure 10 This is a flowchart of a step-by-step procedure 1000 in an example implementation of an algorithm that can be executed by a processing device to generate binarized opacity values. In some examples, one or more steps of procedure 1000 may be implemented as follows: Figure 9 The sub-step of box 906.

[0113] In this example, the opacity value associated with a specific candidate intersection is determined (box 1002). In various implementations, the rendering module 116 retrieves the opacity value 222 from the data associated with the rendered primitive 124 at the specific candidate intersection 218. For example, if the rendered primitive 124 is a 3D Gaussian sputtering, the opacity value 222 is obtained from the properties of the Gaussian function at the specific candidate intersection 218.

[0114] Random values ​​are generated for specific candidate intersections (box 1004). In some examples, the rendering module 116 utilizes a random number generation process to generate random values ​​226. In at least one example, the random number generation process includes a pseudo-random number generator seeded with parameters associated with a specific candidate intersection 218.

[0115] The random value is then compared to the opacity value to assign a binarized opacity value to a specific candidate intersection (box 1006). In various implementations, the rendering module 116 performs this comparison to determine whether the intersection is considered opaque or transparent in binary form. For example, determining whether the random value is less than the opacity value (box 1008).

[0116] If the random value is less than the opacity value (e.g., "Yes" at box 1008), a binarized opacity value is assigned to indicate that a particular candidate intersection 218 is opaque (box 1010). For example, rendering module 116 sets the binarized opacity value 228 to "1" and / or "True" to represent an opaque intersection. This assignment indicates that the intersection will be considered as a potential shading intersection 230.

[0117] Alternatively, if the random value is greater than or equal to the opacity value (e.g., "No" at box 1008), a binarized opacity value 228 is assigned to indicate that a particular candidate intersection 218 is transparent (box 1012). For example, rendering module 116 assigns the binarized opacity value 228 as "0" and / or "false" to represent a transparent intersection. This assignment allows rendering module 116 to filter out a particular candidate intersection 218 regardless of its use for shading.

[0118] In some implementations, the rendering module 116 repeats this procedure for each candidate intersection 218 along the ray 216. By randomly determining the opacity in this manner, the rendering module 116 is able to efficiently process partially transparent primitives without having to sort and process each intersection along each ray. Therefore, the technique described herein reduces computational complexity and memory usage compared to conventional ray tracing methods. Example systems and devices

[0119] Figure 11 An example system, generally including an example computing device 1102 at 1100, is illustrated. This example computing device 1102 represents one or more computing systems and / or devices implementing the various technologies described herein. This is illustrated by including a rendering module 116. The computing device 1102 may be configured as, for example, a server of a service provider, a device associated with a client (e.g., a client device), a system-on-a-chip, and / or any other suitable computing device or computing system.

[0120] The illustrated example computing device 1102 includes a processing system 1104 communicatively coupled to each other, one or more computer-readable media 1106, and one or more I / O interfaces 1108. Although not shown, the computing device 1102 also includes a system bus or other data and command transmission system that couples the various components to each other. The system bus may include any of the different bus architectures or combinations thereof (such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus utilizing any of the various bus architectures). Various other examples (such as control and data lines) are also contemplated.

[0121] Processing system 1104 represents the functionality of performing one or more operations using hardware. Accordingly, processing system 1104 is illustrated as including hardware elements 1110 configurable as processors, function blocks, etc. This includes implementations in hardware as application-specific integrated circuits or other logic devices formed using one or more semiconductors. Hardware elements 1110 are not limited by the materials forming them or the processing mechanisms employed therein. For example, a processor may be configured as one or more semiconductors and / or transistors (e.g., integrated circuits (ICs)). In this context, processor-executable instructions are electronically executable instructions.

[0122] Computer-readable storage medium 1106 is illustrated as including memory / storage device 1112. Memory / storage device 1112 represents the capacity of a memory / storage device associated with one or more computer-readable media. Memory / storage device 1112 includes volatile media (such as random access memory (RAM)) and / or non-volatile media (such as read-only memory (ROM), flash memory, optical disk, magnetic disk, etc.). Memory / storage device 1112 includes fixed media (e.g., RAM, ROM, fixed hard disk drive, etc.) and removable media (e.g., flash memory, removable hard disk drive, optical disk, etc.). As further described below, computer-readable media 1106 can be configured in a variety of other ways.

[0123] Multiple input / output interfaces 1108 represent the ability to allow a user to input commands and information into the computing device 1102, and also allow the use of various input / output devices to present information to the user and / or other components or devices. Examples of input devices include keyboards, cursor control devices (e.g., mice), microphones, scanners, touch functionality (e.g., capacitive or other sensors configured to detect physical touch), cameras (e.g., using visible or invisible wavelengths such as infrared frequencies to recognize movement as gestures not involving touch), etc. Examples of output devices include display devices (e.g., monitors or projectors), speakers, printers, network interface cards, haptic-responsive devices, etc. Therefore, the computing device 1102 can be configured to support user interaction in various ways as further described below.

[0124] This document describes various technologies in the general context of software, hardware components, or program modules. Generally, such modules include routines, programs, objects, components, parts, data structures, etc., that perform specific tasks or implement specific abstract data types. The terms “module,” “function,” and “part” as used herein typically refer to software, firmware, hardware, or a combination thereof. The technologies described herein are characterized by platform independence, meaning that they can be configured on a wide range of commercial computing platforms with various processors.

[0125] The described modules and technologies are implemented on or across some form of computer-readable medium. Computer-readable medium includes various media accessed by computing device 1102. By way of example and not limitation, computer-readable medium includes both "computer-readable storage media" and "computer-readable signal media".

[0126] "Computer-readable storage medium" refers to a medium and / or device capable of persistently and / or non-transitory storing information, as opposed to mere signal transmission, carrier waves, or signals themselves. Therefore, computer-readable storage medium refers to non-signal-bearing media. Computer-readable storage media include hardware (such as volatile and non-volatile, removable and non-removable media) and / or storage devices implemented with methods or techniques suitable for storing information (such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data). Examples of computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage, hard disk, magnetic tape cassette, magnetic tape, disk storage or other magnetic storage devices, or other storage devices, tangible media, or articles of art suitable for storing desired information and accessible by a computer.

[0127] "Computer-readable signal medium" refers to a signal-bearing medium configured to transmit instructions to the hardware of computing device 1102, such as via a network. Signal media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals (such as carrier waves, data signals, or other transmission mechanisms). Signal media also includes any information delivery medium. The term "modulated data signal" means a signal whose characteristics are set or altered in a manner that encodes information in the signal. By way of example and not limitation, communication media include wired media (such as wired networks or direct wired connections) and wireless media (such as acoustic, RF, infrared, and other wireless media).

[0128] As previously described, hardware element 1110 and computer-readable medium 1106 represent modules, programmable device logic, and / or fixed device logic implemented in hardware, which are employed in some embodiments to implement at least some aspects of the techniques described herein (such as executing one or more instructions). Hardware includes components of integrated circuits or systems-on-a-chip, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and other implementations in silicon-based or other hardware. In this context, hardware operates as a processing device that executes program tasks defined by instructions and / or logic embodied in the hardware, and hardware for storing instructions for execution (e.g., the previously described computer-readable storage medium).

[0129] The foregoing combinations are also employed to implement the various techniques described herein. Accordingly, software, hardware, or executable modules are implemented as one or more instructions and / or logic contained on some form of computer-readable storage medium and / or implemented by one or more hardware elements 1110. Computing device 1102 is configured to implement specific instructions and / or functions corresponding to the software and / or hardware modules. Accordingly, the implementation of modules executable by computing device 1102 as software is at least partially implemented in hardware (e.g., by using the computer-readable storage medium and / or hardware element 1110 of processing system 1104). Instructions and / or functions may be executed / operated by one or more articles of manufacture (e.g., one or more computing devices 1102 and / or processing system 1104) to implement the techniques, modules, and examples described herein.

[0130] The techniques described herein are supported by various configurations of computing device 1102 and are not limited to specific examples of the techniques described herein. This functionality can also be implemented, in whole or in part, using distributed systems (such as on “cloud” 1114 via platform 1116 as described below).

[0131] Cloud 1114 includes and / or represents platform 1116 for resource 1118. Platform 1116 abstracts the underlying functionality of the hardware (e.g., servers) and software resources of cloud 1114. Resource 1118 includes applications and / or data that can be utilized when computer processing is performed on a server located remotely from computing device 1102. Resource 1118 may also include services provided via the Internet and / or via subscriber networks such as cellular or Wi-Fi networks.

[0132] Platform 1116 abstracts resources and functions to connect computing device 1102 to other computing devices. Platform 1116 also abstracts resource scaling to provide a corresponding level of scaling to the demands encountered by resource 1118 implemented via platform 1116. Therefore, in interconnected device embodiments, the implementation of the functions described herein can be distributed throughout system 1100. For example, the function can be implemented partly on computing device 1102 and partly via platform 1116, which abstracts the functions of cloud 1114.

[0133] Although the invention has been described in language specific to structural features and / or methodological actions, it should be understood that the invention as defined in the appended claims is not necessarily limited to the specific features or actions described. Rather, the specific features and actions are disclosed as exemplary forms of implementing the claimed invention.

Claims

1. A method comprising: Digital assets, including three-dimensional primitives to be included in the scene, are received by a processing device. The processing device identifies candidate intersections between light rays tracked from a viewpoint within the scene and one or more 3D primitives in the 3D primitives. The processing device selects an intersection point from the candidate intersection points based on a binarized opacity value determined for each candidate intersection point and a distance value from each candidate intersection point to the viewpoint. as well as The processing device renders the digital assets within the scene by applying color values ​​associated with the selected intersection points to the pixels.

2. The method of claim 1, wherein the binarized opacity value is binarized probabilistically based on the opacity value associated with the candidate intersection to indicate whether the candidate intersection is opaque or transparent.

3. The method of claim 1, wherein the three-dimensional primitive comprises a transparent three-dimensional Gaussian sputtering, and each candidate intersection is associated with a depth value, a color value, and an opacity value based on the three-dimensional Gaussian sputtering.

4. The method of claim 1, further comprising generating a binarized opacity value for a specific candidate intersection point by means of: Determine the opacity value associated with the specific candidate intersection point; A random number generation process is used to generate random values ​​for the specific candidate intersection points; as well as The random value is compared with the opacity value to assign the binarized opacity value to the specific candidate intersection.

5. The method of claim 4, wherein the random value is less than the opacity value, and the binarized opacity value indicates that the particular candidate intersection is opaque.

6. The method of claim 4, wherein the random value is greater than or equal to the opacity value, and the binarized opacity value indicates that the particular candidate intersection is transparent.

7. The method of claim 1, wherein the selected intersection has an opacity value indicating that the selected intersection is opaque and a minimum distance value relative to the other distance values ​​of the candidate intersection.

8. The method of claim 1, wherein identifying the candidate intersection includes traversing the acceleration structure associated with the digital asset.

9. The method according to claim 1, further comprising: Additional intersections are selected from the candidate intersections, and the color value applied to the pixel is based on a first color value associated with the selected intersection and a second color value associated with the additional intersection.

10. A system comprising: Memory components; as well as A processing device, coupled to the memory component, is used to perform operations including: Receive input for depicting digital assets within a scene, the digital assets including rendered primitives; The color values ​​to be applied to pixels are determined by the following factors to visually represent the digital assets within the scene: Identify candidate intersections between ray rays traced from a viewpoint within the scene and one or more rendering primitives; and For each of the ray rays, an intersection point is selected from the candidate intersection points based on the binarized opacity value of each candidate intersection point and the distance value of each candidate intersection point to the viewpoint; and The digital assets within the scene are rendered by applying color values ​​associated with the selected intersection points to the pixels.

11. The system of claim 10, further comprising generating a binarized opacity value for a particular candidate intersection point by means of: Determine the non-binarized opacity value associated with the specific candidate intersection point; A random number generation process is used to generate random values ​​for the specific candidate intersection points; as well as The random value is compared with the non-binarized opacity value to assign the binarized opacity value to the specific candidate intersection.

12. The system of claim 11, wherein a random value less than the debinarized opacity value indicates that the particular candidate intersection is opaque, and a random value greater than or equal to the debinarized opacity value indicates that the particular candidate intersection is transparent.

13. The system of claim 10, wherein the selected intersection point for a particular ray has a binarized opacity value indicating that the selected intersection point is opaque, and the selected intersection point has the lowest distance value relative to other distance values ​​of the candidate intersection points for the particular ray.

14. The system of claim 10, wherein determining the color value comprises: For each ray of light, two or more intersections are selected from the candidate intersections, and an average color value is calculated between the color values ​​associated with the selected two or more intersections.

15. The system of claim 10, wherein the operation further comprises: Receive edits for changing the conditions of the scene, and render the digital asset with the changed conditions within the scene by selecting one or more additional intersections and applying color values ​​associated with the one or more additional intersections to the pixel.

16. The system of claim 10, wherein the rendered primitives comprise a three-dimensional Gaussian sputtering, and each candidate intersection is associated with a depth value, a color value, and an opacity value based on the three-dimensional Gaussian sputtering.

17. A non-transitory computer-readable storage medium storing executable instructions that, when executed by a processing device, cause the processing device to perform an operation, the operation comprising: Receive edits for conditions that change a scene, which includes digital assets defined by rendered primitives; Identify candidate intersections between a ray traced from a viewpoint within the scene with the modified conditions and one or more of the rendered primitives. An intersection point is selected from the candidate intersection points based on the binarized opacity value associated with each candidate intersection point and the distance value of each candidate intersection point to the viewpoint; as well as The digital assets within the scene with the modified conditions are rendered by applying color values ​​associated with the selected intersection points to the pixels.

18. The non-transitory computer-readable storage medium of claim 17, wherein the altered conditions include one or more of the following: an adjusted viewpoint, modified lighting conditions, or the addition or removal of additional digital assets from the scene.

19. The non-transitory computer-readable storage medium of claim 17, wherein the rendered primitives comprise a three-dimensional Gaussian sputtering, and each candidate intersection is associated with a depth value, a color value, and an opacity value based on the three-dimensional Gaussian sputtering.

20. The non-transitory computer-readable storage medium of claim 17, further comprising generating a binarized opacity value for a particular candidate intersection point by means of: Determine the opacity value associated with the candidate intersection point; A random value for the specific candidate intersection point is generated using a random number generation process. as well as The random value is compared with the opacity value to assign the opacity value to the specific candidate intersection.

Images