LuxCoreRender Forums

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

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

Current: New:
I will do an pull request so more people can opine on all the changes.

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 !

The only part that is not multi-threaded is the convergence channel calculation that is pretty quick.
Besides that the rest works as usual.

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.

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.

It really looks nice. Thanks for your contribution.

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.

The examples look very promising, how well does this work in combination with OIDN?

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.

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