Page 11 of 15

Re: Adaptive sampling improvements

Posted: Fri Apr 19, 2019 4:13 pm
by Dade
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.

Re: Adaptive sampling improvements

Posted: Fri Apr 19, 2019 4:22 pm
by alpistinho
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!

Re: Adaptive sampling improvements

Posted: Fri Apr 19, 2019 5:33 pm
by alpistinho
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

Re: Adaptive sampling improvements

Posted: Fri Apr 19, 2019 5:51 pm
by B.Y.O.B.
Awesome work!

Re: Adaptive sampling improvements

Posted: Fri Apr 19, 2019 6:51 pm
by alpistinho
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

Re: Adaptive sampling improvements

Posted: Fri Apr 19, 2019 8:04 pm
by provisory
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.

Re: Adaptive sampling improvements

Posted: Sat Apr 20, 2019 10:02 am
by provisory
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

Re: Adaptive sampling improvements

Posted: Sat Apr 20, 2019 1:06 pm
by Dade
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.

Re: Adaptive sampling improvements

Posted: Sat Apr 20, 2019 7:14 pm
by provisory
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? :)

Re: Adaptive sampling improvements

Posted: Sat Apr 20, 2019 8:40 pm
by Dade
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 :?: