Page 3 of 5

Re: Quasirandom sampler

Posted: Wed Mar 06, 2019 1:07 pm
by alpistinho
Hi,

I am using now a random value as seed for each thread and used the same Cranley-Patterson rotation implemented in SobolSequence that really helped with the visible artifacts. I have idea if that's theoretically sound, though.

The noise seems a litle bit higher to me than Sobol, but it is a bit faster (0.43 MS/s vs 0.5 MS/s). Of course all that is based on my pretty naive implementation.

R2 (6 samples/pixel)
r2.png
Sobol (6 samples/pixel)
sobol.png
R2 (16 samples/pixel)
r2_16.png
Sobol (16 samples/pixel)
sobol_16.png

Re: Quasirandom sampler

Posted: Wed Mar 06, 2019 1:23 pm
by alpistinho
I would say Sobol is still a bit better.

Both tests with 60s now
R2
r2_60s.png
Sobol
sobol_60s.png

Re: Quasirandom sampler

Posted: Wed Mar 06, 2019 1:32 pm
by CodeHD
By a margin it seems ;)

Variance in two test areas, red channel (others are similar):
Sobol: 196.23 and 34.36
R2: 200.27 and 35.56
sobol_R2.png
How many samples did each render achieve in 60s?
And do you think it is the efficiency of the sampler implementation that causes some of the S/s-difference?

Re: Quasirandom sampler

Posted: Wed Mar 06, 2019 1:34 pm
by lacilaci
sovbolVr2.gif

Re: Quasirandom sampler

Posted: Wed Mar 06, 2019 1:59 pm
by alpistinho
CodeHD wrote: Wed Mar 06, 2019 1:32 pm How many samples did each render achieve in 60s?
And do you think it is the efficiency of the sampler implementation that causes some of the S/s-difference?
I forgot to take notes, but it was something like 37 for Sobol and 45 for the R2.

The operations for creating a sample in R2 are simpler than Sobol's, so I guess that's where the extra speed comes from and maybe is more of a difference in a GPU implementation. About the sample quality, I don't know what exactly I could do to improve.

The new sampler currently crashes if I enable PGI

Re: Quasirandom sampler

Posted: Wed Mar 06, 2019 3:24 pm
by alpistinho
What is the easiest way to compile a debug version? I don't know how to do that using the build script.

The PGI crash is in some malloc, but the core file does not say anything besides that and I will take forever to track this down without some other clue.

Besides, if this goes nowhere, as I knew it could go, I thought about implementing this: https://graphics.pixar.com/library/Prog ... dSampling/ now that I know a bit better how the sampler works

Re: Quasirandom sampler

Posted: Wed Mar 06, 2019 3:34 pm
by B.Y.O.B.
alpistinho wrote: Wed Mar 06, 2019 3:24 pm What is the easiest way to compile a debug version? I don't know how to do that using the build script.
I would also be interested in this.

Re: Quasirandom sampler

Posted: Wed Mar 06, 2019 3:35 pm
by lacilaci
wow that pixar thing looks impressive :!:

Re: Quasirandom sampler

Posted: Wed Mar 06, 2019 3:44 pm
by CodeHD
Yeah the paper looks quite nice. I only wish they had made some plots comparing only pmj and sobol in some detail views (i.e. the best candidates that they then mention all the time), not 15 data sets in one plot :D

This sparks another question: Which variation (if at all a variation) of Sobol does LuxCore currently use, and could that be something to improve?

Re: Quasirandom sampler

Posted: Wed Mar 06, 2019 4:03 pm
by acasta69
alpistinho wrote: Wed Mar 06, 2019 3:24 pm What is the easiest way to compile a debug version? I don't know how to do that using the build script.
You are working on windows, right?
It should be

Code: Select all

cmake-build-x64.bat /debug
however, I have never checked the outcome of this...
Alternatively, you could do

Code: Select all

cmake-build-x64.bat /cmake-only
then open the generated solution file from Visual Studio and select debug build from the IDE.