Ghadeer Abou-Saleh | Path Tracing with WebGPU - Attempt #2 [No Audio] @gee8sh | Uploaded June 2022 | Updated October 2024, 4 days ago.
For context, please read the description of my first modest attempt at implementing close-to-real-time path tracing (of very simple geometry) with WebGPU. It could be found here: youtu.be/ryyuQ10hblA
This second attempt adds two enhancements that improved a tiny bit the overall animation quality:
- Importance Sampling: this is the process in which the scattered rays are skewed towards light surfaces. This makes the Monte Carlo integration converge faster. However, since there are many light/emissive surfaces in the scene, and to maintain acceptable performance, each surface or tile in the scene would scatter rays towards a maximum of 4 lights per tile. At first these surfaces would scatter rays in all directions (i.e. basic diffuse scattering). But when these rays hit light/emissive surfaces, the originating surface or tile would "remember" that light source, so that following ray samples would be skewed towards that light source. The downside of this approach is that adjacent tiles would randomly favor different light sources, causing artifacts in the form of contrast between these tiles (as can be clearly seen towards the end of the video).
- Denoising: Importance sampling helps reducing noise. But to reduce it even further I applied an "improvised" filter as a post processing step for each frame. It is not exactly a low-pass filter (which would cause lots of blurring). Instead, each pixel is mixed with the "weighted average" of surrounding pixels in a way that is a function of the difference in brightness between the pixel in question and the surrounding ones. If the difference is small, the pixel remains largely intact. If the difference is significant, the surrounding pixels are mixed heavily into the current pixel, almost replacing it. The weighted average of the surrounding pixels is also a function of the geometry. Pixels that are not projected from the same plane as the current pixel are not included in the average. To do that, the filter needs to know the depth, and the normal corresponding to each pixel. This keeps the edges sharp.
Despite all the above, the image quality is still not that good, and noise in them is still significant. But I am happy with the overall result given the modest GPU this runs on (an Nvidia Quadro T1000) and how computationally expensive path tracing is.
The demo: ghadeeras.github.io/pages/path-tracing.html
The source code: github.com/ghadeeras/ghadeeras.github.io/tree/master/src/path-tracing
Cheers!
For context, please read the description of my first modest attempt at implementing close-to-real-time path tracing (of very simple geometry) with WebGPU. It could be found here: youtu.be/ryyuQ10hblA
This second attempt adds two enhancements that improved a tiny bit the overall animation quality:
- Importance Sampling: this is the process in which the scattered rays are skewed towards light surfaces. This makes the Monte Carlo integration converge faster. However, since there are many light/emissive surfaces in the scene, and to maintain acceptable performance, each surface or tile in the scene would scatter rays towards a maximum of 4 lights per tile. At first these surfaces would scatter rays in all directions (i.e. basic diffuse scattering). But when these rays hit light/emissive surfaces, the originating surface or tile would "remember" that light source, so that following ray samples would be skewed towards that light source. The downside of this approach is that adjacent tiles would randomly favor different light sources, causing artifacts in the form of contrast between these tiles (as can be clearly seen towards the end of the video).
- Denoising: Importance sampling helps reducing noise. But to reduce it even further I applied an "improvised" filter as a post processing step for each frame. It is not exactly a low-pass filter (which would cause lots of blurring). Instead, each pixel is mixed with the "weighted average" of surrounding pixels in a way that is a function of the difference in brightness between the pixel in question and the surrounding ones. If the difference is small, the pixel remains largely intact. If the difference is significant, the surrounding pixels are mixed heavily into the current pixel, almost replacing it. The weighted average of the surrounding pixels is also a function of the geometry. Pixels that are not projected from the same plane as the current pixel are not included in the average. To do that, the filter needs to know the depth, and the normal corresponding to each pixel. This keeps the edges sharp.
Despite all the above, the image quality is still not that good, and noise in them is still significant. But I am happy with the overall result given the modest GPU this runs on (an Nvidia Quadro T1000) and how computationally expensive path tracing is.
The demo: ghadeeras.github.io/pages/path-tracing.html
The source code: github.com/ghadeeras/ghadeeras.github.io/tree/master/src/path-tracing
Cheers!
![Path Tracing with WebGPU - Attempt #2 [No Audio]](https://i.ytimg.com/vi/h3hfA2K65Ew/hqdefault.jpg "Path Tracing with WebGPU - Attempt #2 [No Audio]
For context, please read the description of my first modest attempt at implementing close-to-real-time path tracing (of very simple geometry) with WebGPU. It could be found here: https://youtu.be/ryyuQ10hblA
This second attempt adds two enhancements that improved a tiny bit the overall animation quality:
- Importance Sampling: this is the process in which the scattered rays are skewed towards light surfaces. This makes the Monte Carlo integration converge faster. However, since there are many light/emissive surfaces in the scene, and to maintain acceptable performance, each surface or tile in the scene would scatter rays towards a maximum of 4 lights per tile. At first these surfaces would scatter rays in all directions (i.e. basic diffuse scattering). But when these rays hit light/emissive surfaces, the originating surface or tile would remember that light source, so that following ray samples would be skewed towards that light source. The downside of this approach is that adjacent tiles would randomly favor different light sources, causing artifacts in the form of contrast between these tiles (as can be clearly seen towards the end of the video).
- Denoising: Importance sampling helps reducing noise. But to reduce it even further I applied an improvised filter as a post processing step for each frame. It is not exactly a low-pass filter (which would cause lots of blurring). Instead, each pixel is mixed with the weighted average of surrounding pixels in a way that is a function of the difference in brightness between the pixel in question and the surrounding ones. If the difference is small, the pixel remains largely intact. If the difference is significant, the surrounding pixels are mixed heavily into the current pixel, almost replacing it. The weighted average of the surrounding pixels is also a function of the geometry. Pixels that are not projected from the same plane as the current pixel are not included in the average. To do that, the filter needs to know the depth, and the normal corresponding to each pixel. This keeps the edges sharp.
Despite all the above, the image quality is still not that good, and noise in them is still significant. But I am happy with the overall result given the modest GPU this runs on (an Nvidia Quadro T1000) and how computationally expensive path tracing is.
The demo: https://ghadeeras.github.io/pages/path-tracing.html
The source code: https://github.com/ghadeeras/ghadeeras.github.io/tree/master/src/path-tracing
Cheers!")
![Scalar Field Isosurface Ray Casting with WebGPU [No Audio][HD]](https://i.ytimg.com/vi/mOU3Fvg2FNw/hqdefault.jpg "Scalar Field Isosurface Ray Casting with WebGPU [No Audio][HD]
This toy explores rendering scalar field isosurfaces with WebGPU using a method that could be thought of as a hybrid of Ray Marching and Marching Cubes.
Unlike Ray Marching, which usually uses Signed Distance Fields (SDFs), this method uses the scalar field itself and its gradients to determine the sizes of the steps that the tracing rays should march by until they hit the selected isosurface. All the ray marching happens in the fragment shader.
And unlike Marching Cubes, this method does not polygonize/tesselate the isosureface, as it uses Ray Casting rather than the conventional rasterization-based rendering. However, it does sample the scalar field and its gradient in a separate compute shader at the points of a 3D grid, and stores the samples in a 3D texture that could be sampled using linear interpolation.
The scalar field of choice is actually a noise field generated by starting from a simple base scalar field, and then recursively superpose a few translated, scaled and rotated copies of that field onto itself.
Using keyboard shortcuts, you could control some viewing aspects, as well as some of the parameters used to generate the scalar field. This is what you see happening in the video as the mouse is dragged on the canvas. It is basically changing the scaling and rotation parameters used in generating the noise field, as well as rotating the model and selecting different isosurfaces.
The demo can be found here:
https://ghadeeras.github.io/pages/scalar-field-tracing
The source code can be found on GitHub:
https://github.com/ghadeeras/ghadeeras.github.io/tree/master/src/scalar-field-tracing
Cheers!")
![Path Tracing with WebGPU - Attempt #1 [No Audio]](https://i.ytimg.com/vi/ryyuQ10hblA/hqdefault.jpg "Path Tracing with WebGPU - Attempt #1 [No Audio]
This is my very first attempt at trying to perform close-to-real-time path tracing with WebGPU.
To simplify things, I did stick to axis-aligned boxes placed in an axis-aligned 3D grid, of which each cell could hold (or intersect with) up to 8 boxes of arbitrary sizes. The ray/box hit function is easy to implement in this case, and the axis-aligned grid is easy to traverse, though it is likely not the most optimal solution.
Three kinds of materials are currently supported: diffuse/matte, reflective, and emissive (for lights). Each face of each box could be assigned its own material.
There is almost no rasterization in this demo except for one inevitable big square to cover the canvas. Ray tracing here starts from each pixel. The Monte-Carlo integration is done to estimate the color arriving at each pixel by averaging multiple samples per pixel. This averaging is done in two ways, once in the fragment shader of the tracer, and once by stacking up to 256 frames.
The number of samples/frames averaged decreases significantly as you move around in the procedurally constructed maze, and increases when you stop moving. This is why the rendering becomes too noisy while navigating the maze.
Clearly, this attempt did not meet the sought and hoped-for objective (i.e. real-time rendering), but it is a step in the right direction. I will need to try a few other tricks, like: hybrid of rasterization/path-tracing, breaking down each render pass to smaller more efficient render passes, denoising techniques, and smarter averaging of frames that accounts to movements.
The demo: https://ghadeeras.github.io/pages/path-tracing.html
The source code: https://github.com/ghadeeras/ghadeeras.github.io/tree/master/src/path-tracing
Cheers!")
![Path Tracing with WebGPU - Attempt #3 [No Audio]](https://i.ytimg.com/vi/wl55OijuaGo/hqdefault.jpg "Path Tracing with WebGPU - Attempt #3 [No Audio]
For context, please checkout my earlier videos:
https://youtu.be/xlMvArfR2do
https://youtu.be/ryyuQ10hblA
https://youtu.be/h3hfA2K65Ew
The main change in this iteration is the way stacking is done. Previously, to generate a new frame, the few previous and new raw frames are stacked together, by averaging the colors of corresponding pixels from each frame to produce the pixel colors of the final frame. This caused a bit of blurring when the Eye is moving through the scene.
Now, the Eyes position, orientation, and perspective in each frame is taken into account when stacking. So, a pixel with coordinates x and y is not necessarily averaged with pixels of the same coordinates in previous frames. This almost eliminates blurring and renders edges sharper. It reduces overall noise, except for mirror reflections, where I think noise unfortunately increased.
The demo: https://ghadeeras.github.io/pages/path-tracing.html
The source code: https://github.com/ghadeeras/ghadeeras.github.io/tree/master/src/path-tracing
Cheers!")
![Path Tracing with WebGPU - The Floating Eyeball! :-) [No Audio]](https://i.ytimg.com/vi/xlMvArfR2do/hqdefault.jpg "Path Tracing with WebGPU - The Floating Eyeball! :-) [No Audio]
For context, please checkout my earlier two videos:
https://youtu.be/ryyuQ10hblA
https://youtu.be/h3hfA2K65Ew
There is nothing remarkably new in this new round of toying with path tracing except that the viewer, the navigator or the first person is no longer invisible/transparent. Instead the viewer is represented by a small floating eyeball that could cast shadows and could view itself in mirrors.
I should probably experiment with small spot lights instead of the big flat ones to see how this toy would render sharper shadows.
The demo: https://ghadeeras.github.io/pages/path-tracing.html
The source code: https://github.com/ghadeeras/ghadeeras.github.io/tree/master/src/path-tracing
Cheers!")
