First I was working on this JavaScript ray tracer with BVH acceleration and voxel grid acceleration. And managed to get a 870k dragon loaded into it and rendered in less than 30 seconds... In quite unoptimized single-threaded JavaScript.
Then I had an idea and spent two weeks doing noise-free single-sample bidirectional path tracing. But it turns the high-frequency noise into low-frequency noise and runs too slow for realtime. I'll have to experiment more with the idea. Shadertoy here. Start with the writeup and screenshots after that.
Single-sample bidirectional path tracing + hemisphere approximation
Smooth indirect illumination by creating the incoming light hemisphere on the fly
based on the hemisphere samples of the surrounding pixels.
See also: Virtual point lights, bidirectional instant radiosity
First pass: Create path suffixes = point with incoming ray of light.
1. Shoot out primary ray and bounce it off the hit surface.
2. Trace the first bounce and store its hit point, normal and material.
3. Trace the rest of the path from the first bounce point and store the direction of the path.
4. Store the amount of light at the first bounce point.
Now you have a path suffix at each pixel that has enough info to connect any other path to it.
Second pass: Connect the primary ray to path suffixes in surrounding pixels.
1. Shoot out primary ray and calculate direct light for it
2. Sample NxN samples around the pixel from the path suffix buffer
3. Accumulate the light from the hemisphere. For each sample:
3.1. Calculate the direction to it: hd = normalize(sample.p - primary.p)
3.2. Accumulate light according to the BRDFs of the primary point and the hemisphere point.
[3.3. Scale the light contribution with a pixel distance filter for smoother transitions]
Extra passes: Create new path suffixes by connecting points in path suffix buffer to other path suffixes
1. Primary ray hits can act as path suffixes for hemisphere points (and have nice geometric connection at same px coord).
2. Hemisphere points can act as path suffixes for hemisphere points (but may lie on the same plane near px coord).
3. Add light from new path suffixes to primary hits.
Why this might be nice?
- Get more mileage from paths: in scenes with difficult lighting conditions, the chances of
finding light are low for any given path. By summing up the contributions of 10000 paths,
you've got a much higher chance of finding light for a pixel.
- Less noise: noise is variance in hemisphere sampling. If neighbouring pixels have similar
hemispheres, there's smooth variance and little noise.
- If you have the budget, you can cast shadow rays to each hemisphere point and get correct lighting.
- If you don't have the budget, you can use the hemi points as soft light and get blurry lighting
- You can use the found hemisphere light to approximate a point's light distribution and guide your sampler.
- You can use light samples from previous frames.
What sucks?
- If you don't cast shadow rays, you get light bleeding and everything's blurry.
- Casting 1000 shadow rays per pixel is going to have an impact on performance
- Direct lighting remains noisy
(you can use direct light as a hemisphere sample but it causes even more light bleeding w/o shadow rays)
- This scene smooths out at 64x64 hemisphere samples per pixel, which is expensive to sample
- Increasing the size of your sampling kernel increases inaccuracies w/o shadow rays
- It seems like you trade high-frequency noise for low-frequency noise
- Glossy stuff is hard
The ugly:
- Using three buffers to trace because no MRTs, otherwise could store hemi hit, normal, dir, primary hit,
hemi color, primary color on a single trace, and recombine on the second pass.
- Slow SDF ray marcher as the rendering engine
- Not storing incoming light dir atm, all the lighting equations are hacks in this demo
No comments:
Post a Comment