Adaptive sampling improvements

Discussion related to the Engine functionality, implementations and API.
User avatar
Dade
Developer
Developer
Posts: 3249
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Adaptive sampling improvements

Post by Dade » Fri Apr 19, 2019 4:13 pm

alpistinho wrote:
Fri Apr 19, 2019 4:08 pm
The adaptive sampling is used, the stochastic nature breaks this and the values uses vary across passes and somehow this leads to a worse sampling distribution.
Ok, so you have just draw the random numbers even if you are skipping the pixel :idea: This should be fix the problem at a trivial cost of generating just 3 more random numbers.
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 » Fri Apr 19, 2019 4:22 pm

Dade wrote:
Fri Apr 19, 2019 4:13 pm
Ok, so you have just draw the random numbers even if you are skipping the pixel :idea: This should be fix the problem at a trivial cost of generating just 3 more random numbers.
Thanks for the suggestion!

I just implemented and I think it is working as expected now. I will send the PR.

This probably affected the old adaptive sampler too, but the adaptiveness possibly compensates it enough it was hard to notice in most scenes.

@provisory, thanks for the help!
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 » Fri Apr 19, 2019 5:33 pm

Comparing with the initial results, it seems this was an issue all along:

Fixed distribution:
RGB_IMAGEPIPELINE_0.png
Wrong distribution:
RGB_IMAGEPIPELINE_0_old_adaptive.png
Uniform sampling:
RGB_IMAGEPIPELINE_0_uniform.png
Support LuxCoreRender project with salts and bounties

User avatar
B.Y.O.B.
Developer
Developer
Posts: 2997
Joined: Mon Dec 04, 2017 10:08 pm
Location: Germany
Contact:

Re: Adaptive sampling improvements

Post by B.Y.O.B. » Fri Apr 19, 2019 5:51 pm

Awesome work!
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 » Fri Apr 19, 2019 6:51 pm

provisory wrote:
Thu Apr 11, 2019 5:37 pm
So, I've first seen the issue with this scene (100 samples in both case, warmup and test step is 5 with adaptivity):
Would you be able to redo this test?

Besides, keep in mind that the tonemap you choose is considered during the noise estimation, so rendering with some given tonemap settings and changing the image exposure or some other setting afterwards should lead to sub-optimal results
Last edited by alpistinho on Fri Apr 19, 2019 8:06 pm, edited 1 time in total.
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 » Fri Apr 19, 2019 8:04 pm

Great news, thank you for your efforts!
alpistinho wrote:
Fri Apr 19, 2019 6:51 pm
Would you be able to redo this test?
I'll test it tomorrow.
alpistinho wrote:
Fri Apr 19, 2019 6:51 pm
Besides, keep in mind that the tonemap you chose is considered during the noise estimation...
I think this is a good direction and it'll give the best results in most cases.

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

Re: Adaptive sampling improvements

Post by provisory » Sat Apr 20, 2019 10:02 am

If I'm right, BlendLuxCore still didn't catch up with the new adaptive sampling parameters, so I used LuxCore UI.
I've found the parameters in the code: film.noiseestimation.warmup and film.noiseestimation.step.
Blender's color management (Filmic) is really missing here, so these images don't look like the original ones.
I used Gimp's Stretch Contrast for samplecount passes.

adaptivity-test6.png
renderengine.type = "BIDIRCPU", batch.haltspp = 50, film.noiseestimation.warmup = 5, film.noiseestimation.step = 5

There are interesting dots in the non-adaptive samplecount image.

The two combined outputs are so similar, that I wasn't sure if there is any difference at all, so I made a diff of them (I used Stretch Contrast here too):
adaptive-nonadaptive-diff.png

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

Re: Adaptive sampling improvements

Post by Dade » Sat Apr 20, 2019 1:06 pm

provisory wrote:
Sat Apr 20, 2019 10:02 am
renderengine.type = "BIDIRCPU", batch.haltspp = 50, film.noiseestimation.warmup = 5, film.noiseestimation.step = 5
Don't do the tests with BIDIRCPU, use PATHCPU instead: the only real/effective adaptive sampler for BiDir is Metropolis because Adaptive Sobol can work only on eye paths while light paths are unaffected.

I always write that LuxCore is BIDIRCPU+Metropolis or PATHOCL+Sobol(+PhotonGI) all other combinations are more an "academic" exercise and/or corner cases that something really useful.
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 » Sat Apr 20, 2019 7:14 pm

Dade wrote:
Sat Apr 20, 2019 1:06 pm
...the only real/effective adaptive sampler for BiDir is Metropolis because Adaptive Sobol can work only on eye paths while light paths are unaffected.
...
Thank you for your advice!
However in my (not too extensive) experience, it's harder to get noise-free result with metropolis than with sobol (except in the case of caustics). Shadow areas remain noisy for a longer time.

Couldn't adaptivity be used for large mutation in MLT? :)

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

Re: Adaptive sampling improvements

Post by Dade » Sat Apr 20, 2019 8:40 pm

provisory wrote:
Sat Apr 20, 2019 7:14 pm
Couldn't adaptivity be used for large mutation in MLT? :)
The problem would still be the light paths: when you connect a light path to the camera, the affected pixel can be anywhere on the image plane. Metropolis is the only one that can drive light paths according a predefined behavior (i.e the luminance of the obtained sample).

If BIDIRCPU+Sobol is faster than BIDIRCPU+Metropolis, you are probably rendering a scene that will converge even faster with PATHCPU+Sobol :?:
Support LuxCoreRender project with salts and bounties

Post Reply