Adaptive sampling improvements

Discussion related to the Engine functionality, implementations and API.
Post Reply
User avatar
alpistinho
Developer
Developer
Posts: 168
Joined: Thu Jul 05, 2018 11:38 pm
Location: Rio de Janeiro

Adaptive sampling improvements

Post by alpistinho » Wed Apr 03, 2019 2:10 am

Since Dade suggested that I could take a look at the adaptive sampling algorithm I have been working on a new solution that builds upon the current one without making any architectural changes.

There are some changes that I believe are improvements:
  • The pixel pass is kept individually now, instead of being shared with all other.
  • The adaptiveness is based on a different metric, that I hope is more adequate than the current.
  • The adaptiveness does not depend on the threshold value anymore, but it is statistics based.
There are still some limitations and differences:
  • It is only implemented for the sobol sampler
  • The code is still very untested and there are some hardcoded parameters
  • The calculations are a bit more involved than what is currently being used. I think it is still plenty fast, and it is not even multithreaded yet
  • The SobolSharedSampler may be slowing down the rendering a little bit. It may be possible to improve, but I would gladly accept the help from some more experienced eyes here
  • Changing the metric breaks backwards compatibility regarding the halt thereshold parameter
  • The sampling is proportional to the CONVERGENCE channel, while the previous sampled the pixels below the threshold. It is visually very different

I believe a GPU implementation is feasible, since the logic is basically the same, and will work on it once the CPU version is considered functional.
If anyone is willing to test it, I can provide my builds for Linux, but not much else, sorry :oops:

This is a comparison with an average of 100 samples/pixel.

Current:
RGB_IMAGEPIPELINE_0.png
New:
RGB_IMAGEPIPELINE_0.png

I will do an pull request so more people can opine on all the changes.
Support LuxCoreRender project with salts and bounties

User avatar
Sharlybg
Donor
Donor
Posts: 1531
Joined: Mon Dec 04, 2017 10:11 pm
Location: Ivory Coast

Re: Adaptive sampling improvements

Post by Sharlybg » Wed Apr 03, 2019 8:36 am

Seem to be in a good direction. And it isn't multithreaded.if only you can provide a windows build i can test it :)

Thanks you for this work !
Support LuxCoreRender project with salts and bounties

Portfolio : https://www.behance.net/DRAVIA

User avatar
alpistinho
Developer
Developer
Posts: 168
Joined: Thu Jul 05, 2018 11:38 pm
Location: Rio de Janeiro

Re: Adaptive sampling improvements

Post by alpistinho » Wed Apr 03, 2019 8:55 am

The only part that is not multi-threaded is the convergence channel calculation that is pretty quick.
Besides that the rest works as usual.
Support LuxCoreRender project with salts and bounties

User avatar
Dade
Developer
Developer
Posts: 3278
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Adaptive sampling improvements

Post by Dade » Wed Apr 03, 2019 10:13 am

Thanks, I merged the pull request on "new_conv_test" branch so we can work there without hurry. Let's start:

1) There seem to be a problem on borders. You are always dividing by 81 (9 * 9) however the pixels near borders have less neighbors so the convergence values are not correct.

2) Can we manipulate the metric to avoid sqrt() ? I mean, instead of comparing "sqrt(a) > sqrt(b)", I usually compare "sqrt(a * a) > sqrt(b * b) => a > b" so I can avoid the square root. sqrt() is something like 1000 times slower than a multiplication.

3) Do we still need to blur the convergence AOV ? You are already using a window of 9x9 around the pixel. I think the blur can be removed.

4) I have already changed some but, in general, use assert() instead for run time safety checks so they will not affect performance.
Support LuxCoreRender project with salts and bounties

User avatar
alpistinho
Developer
Developer
Posts: 168
Joined: Thu Jul 05, 2018 11:38 pm
Location: Rio de Janeiro

Re: Adaptive sampling improvements

Post by alpistinho » Wed Apr 03, 2019 10:34 am

Thanks for the review.

1) That was an oversight, I will fix it
2) I will see if it's possible. Could we use that fast sqrt trick? Numerical precision is definitely not critical in this calculation (https://en.m.wikipedia.org/wiki/Fast_in ... quare_root). Besides, I think this is not going to be a hot path, unless the step parameter is very small and the passes end super quickly.
3) The blur code is there but I was not using it. I guess I can remove it.
4) This is still some code for debugging. I will try to address all the problems and substitute for asserts. Some of those tests are possibly not avoidable since I cannot guarantee that there is going to be a difference for a given pixel between two passes, or that the reference image does not contain a black pixel.
Support LuxCoreRender project with salts and bounties

kintuX
Posts: 474
Joined: Wed Jan 10, 2018 2:37 am

Re: Adaptive sampling improvements

Post by kintuX » Wed Apr 03, 2019 12:24 pm

It really looks nice. Thanks for your contribution. :)

User avatar
FarbigeWelt
Donor
Donor
Posts: 876
Joined: Sun Jul 01, 2018 12:07 pm
Location: Switzerland
Contact:

Re: Adaptive sampling improvements

Post by FarbigeWelt » Wed Apr 03, 2019 2:45 pm

alpistinho wrote:
Wed Apr 03, 2019 10:34 am

2) I will see if it's possible. Could we use that fast sqrt trick? Numerical precision is definitely not critical in this calculation (https://en.m.wikipedia.org/wiki/Fast_in ... quare_root). Besides, I think this is not going to be a hot path, unless the step parameter is very small and the passes end super quickly.
Considering your wikipedia text and
a*a=a^2
log(_2(a)*2=log_2(a*a)
There is probably even a way to reduce time for a^2 which is definitely faster than sqrt(). And if there is a way it is already known and today compilers apply an optimized algorithm if they detect a*a or a^2. At least I expect a time optimized solution from the boost library.

I would follow Dade‘s suggestion.

EDIT: By the way, your solution shows nice results, especially if you compare the bright reflections of the area light.
Light and Word designing Creator - www.farbigewelt.ch - aka quantenkristall || #luxcorerender
160.8 | 42.8 (10.7) Gfp | Windows 10 Pro, intel i7 4770K@3.5, 32 GB
2 AMD Radeon RX 5700 XT, 8 GB || Gfp = SFFT Gflops

User avatar
epilectrolytics
Donor
Donor
Posts: 578
Joined: Thu Oct 04, 2018 6:06 am

Re: Adaptive sampling improvements

Post by epilectrolytics » Wed Apr 03, 2019 3:31 pm

The examples look very promising, how well does this work in combination with OIDN?
MBPro 15" 16GB i7-4850HQ GT750M, MacOS 10.13.6 & Win10Pro PC 16GB Ryzen 2700X, 2 x RTX 2070

User avatar
Dade
Developer
Developer
Posts: 3278
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Adaptive sampling improvements

Post by Dade » Wed Apr 03, 2019 3:45 pm

epilectrolytics wrote:
Wed Apr 03, 2019 3:31 pm
The examples look very promising, how well does this work in combination with OIDN?
In theory Oidn could have some problem with noise correlation due to adaptive rendering however, in practice, it works fine with the old adaptive Sobol and Metropolis so I'm pretty sure it is not going to be a problem.
Support LuxCoreRender project with salts and bounties

provisory
Posts: 224
Joined: Wed Aug 01, 2018 4:26 pm

Re: Adaptive sampling improvements

Post by provisory » Wed Apr 03, 2019 3:56 pm

I like the result! The noise looks much more balanced.

Post Reply