Smart sampling methods that improves performance. back

Board: Home Board index Raytracing General Development

(L) [2014/10/13] [tby shiqiu1105] [Smart sampling methods that improves performance.] Wayback!

Hey guys,
I have been trying to optimize my own renderer, and I have been comparing my performance against embree 1.1.
When we use the same bvh traversal methods, embree is still 30-50% faster than mine implementation.
So I was trying to find out why.
And I did notice that one thing causing the perf difference is the way embree generates samples.
Unlike me, who generates samples for each pixel, embree generate only 64 for samples for the entire frame in one iteration.
And during rendering, each pixel selects randomly from the 64-sized sample pool to use.
I tried this after realizing what embree does, and my perf was instantly boosted to almost the same with embree, but the resulting image was full of ringing-like artifact, which is really not surprising considering I am using only 64 random sample sets for the entire image.
Embree didn't generate 64 samples randomly. instead it seems to stratified them, so the 64 samples' quality are high.
It seems like a really smart thing, considering it almost saved all the cost from sample generation.
Is this approach published or documented somewhere, any prove that it doesn't hurt the convergence rate much?
Thanks,
(L) [2014/10/13] [tby ingenious] [Smart sampling methods that improves performance.] Wayback!

Yeah, I also noticed it some time ago when I was exploring their source code. And apparently this trick is still there [SMILEY :)] It doesn't reduce the numerical convergence in any way. It only adds correlation between pixels which can potentially be visually disturbing. This reminds me of [LINK http://graphics.ucsd.edu/~iman/coherent_path_tracing.php coherent path tracing]. I'm not aware of any papers that investigate inter-pixel sampling correlation, which is strange, because a lot of the artifacts in rendering come precisely from there. Photon mapping and (ir)radiance caching are prominent examples, where most of the splotches are not due to bias as much as due to the effective correlation that the sample reuse brings.
(L) [2014/10/13] [tby shiqiu1105] [Smart sampling methods that improves performance.] Wayback!

>> ingenious wrote:Yeah, I also noticed it some time ago when I was exploring their source code. And apparently this trick is still there  It doesn't reduce the numerical convergence in any way. It only adds correlation between pixels which can potentially be visually disturbing. This reminds me of [LINK http://graphics.ucsd.edu/~iman/coherent_path_tracing.php coherent path tracing]. I'm not aware of any papers that investigate inter-pixel sampling correlation, which is strange, because a lot of the artifacts in rendering come precisely from there. Photon mapping and (ir)radiance caching are prominent examples, where most of the splotches are not due to bias as much as due to the effective correlation that the sample reuse brings.
I just did two experiments with my own renderer.
Both with path tracing and random sampler. The sponza scene is with 256 spp, while the cornell box is with 64spp.
Perceptually I could tell little difference between using one sample per pixel vs. reusing 64 samples. (Maybe the reusing approach is a tiny little bit noisier, am I crazy?)
In the cornellbox, reusing sample achieves maybe ~150% performance against per pixel samples.
In sponza however, the difference is much smaller, likely due to longer traversal time, and texture fetch...
I doubt that the sample reusing will work with some algorithms like MLT.
I guess I will stick with my original approach..
Screenshots attached.

[IMG #1 normal.jpg]
Per pixel sample, 256spp


[IMG #2 pool.jpg]
Reusing 64 samples, 256spp


[IMG #3 normal2.jpg]
Per pixel sample, 64spp
[IMG #1]:Not scraped: /web/20161005161220im_/http://ompf2.com/download/file.php?id=169&sid=7668b0b985d83825d92cbc59dc8386bf
[IMG #2]:Not scraped: /web/20161005161220im_/http://ompf2.com/download/file.php?id=170&sid=7668b0b985d83825d92cbc59dc8386bf
[IMG #3]:Not scraped: /web/20161005161220im_/http://ompf2.com/download/file.php?id=171&sid=7668b0b985d83825d92cbc59dc8386bf
(L) [2014/10/13] [ost by shiqiu1105] [Smart sampling methods that improves performance.] Wayback!

>> ingenious wrote:Yeah, I also noticed it some time ago when I was exploring their source code. And apparently this trick is still there  It doesn't reduce the numerical convergence in any way. It only adds correlation between pixels which can potentially be visually disturbing. This reminds me of [LINK http://graphics.ucsd.edu/~iman/coherent_path_tracing.php coherent path tracing]. I'm not aware of any papers that investigate inter-pixel sampling correlation, which is strange, because a lot of the artifacts in rendering come precisely from there. Photon mapping and (ir)radiance caching are prominent examples, where most of the splotches are not due to bias as much as due to the effective correlation that the sample reuse brings.
I just did two experiments with my own renderer.
Both with path tracing and random sampler. The sponza scene is with 256 spp, while the cornell box is with 64spp.

Perceptually I could tell little difference between using one sample per pixel vs. reusing 64 samples. (Maybe the reusing approach is a tiny little bit noisier, am I crazy?)

In the cornellbox, reusing sample achieves maybe ~150% performance against per pixel samples.
In sponza however, the difference is much smaller, likely due to longer traversal time, and texture fetch...

I doubt that the sample reusing will work with some algorithms like MLT.
I guess I will stick with my original approach..

Screenshots attached.
normal.jpg
pool.jpg
normal2.jpg
(L) [2014/10/13] [tby shiqiu1105] [Smart sampling methods that improves performance.] Wayback!

[IMG #1 pool2.jpg]
Reusing 64 samples. 64spp
[IMG #1]:Not scraped: /web/20161005161220im_/http://ompf2.com/download/file.php?id=172&sid=7668b0b985d83825d92cbc59dc8386bf
(L) [2014/10/13] [ost by shiqiu1105] [Smart sampling methods that improves performance.] Wayback!

pool2.jpg
(L) [2014/10/14] [tby macnihilist] [Smart sampling methods that improves performance.] Wayback!

I have not tried it exactly the way it is implemented in Embree, but I used similar methods to speed up GPU rendering, and I feel I should add a quick comment:
From my experience you have to be careful as soon as caustics or similar 'sharp' effects come into play, because they really can reveal that you are working with a small set of samples behind the scenes. This can reach the point where preview renders with few samples are downright misleading.

back