So, i've been getting myself familiar with monte carlo sampling for an unrelated machine learning project, and a thought struck me.
One of the biggest issues with the metropolis light transport algorithm in unidirectional path tracing is the fact that it's not noise aware; it's good at finding light paths, however it tends to focus too much on hotspots in the image. If an area of the image is noisy but comparatively dark, it takes an incredibly long time to converge, and the only method of increasing the quality of these dark and noisy areas is to push up the large mutation probability... but at that point, the sampler starts to behave more like a random sampler.
What if the metropolis sampler was combined with the noise aware sampling method? instead of large mutations being purely random, it could be guided by the noise aware sampling algorithm - It would still be an unbiased method, as the noise aware sampling method itself is unbiased, however it would mean that the metropolis sampler will spend more time making large mutations in areas that need more samples.
Assuming no one points out any serious flaws in this idea, i'll have a crack at implementing it - i'm not too familiar with the luxcore codebase, however it's a relatively simple change so i feel it'll be a good starting point for me to begin contributing to the project.
Idea for an improved sampler
Re: Idea for an improved sampler
You can find some paper about noise driven metropolis sampler. I have, in the past, done an implementation of "Arbitrary Importance Functions for Metropolis Light Transport" (http://graphics.cs.illinois.edu/sites/d ... ce-cgf.pdf) for old Lux, using noise awareness and user driven sampling. The results haven't been particularly good.
I consider the current major Metropolis limitation is intrinsic serial nature: a new sample is based on the previous one and this is quite horrible in the modern world of GPUs with thousands of threads and CPU with more and more cores. The exploration of the samples space is very slow.
I consider the current major Metropolis limitation is intrinsic serial nature: a new sample is based on the previous one and this is quite horrible in the modern world of GPUs with thousands of threads and CPU with more and more cores. The exploration of the samples space is very slow.
-
oldladyfear
- Posts: 10
- Joined: Mon Apr 16, 2018 12:57 am
Re: Idea for an improved sampler
fair enough, if it's been tried and no improvement was found, no point reinventing the wheel on that one.
In regards to the problems with the serial nature of MLT, it's definitely a limiting factor - while not quite the same, i've run into similar issues trying to implement hamiltonian MCMC in my own work.
I did end up finding a related method, however the RAM requirements would be impractical for 3d rendering. it would require storing 3 maps for the image plane as well as each surface; two for directional information, and one for variance to build a Gaussian posterior, and you end up trading bias for memory usage depending on the resolution of each surface map. It's great if your search space is just a chain of 10 possible discrete actions, but when you're talking thousands of pixels which are technically a continuous space, the GI cache does a similar job and far more efficiently.
In regards to the problems with the serial nature of MLT, it's definitely a limiting factor - while not quite the same, i've run into similar issues trying to implement hamiltonian MCMC in my own work.
I did end up finding a related method, however the RAM requirements would be impractical for 3d rendering. it would require storing 3 maps for the image plane as well as each surface; two for directional information, and one for variance to build a Gaussian posterior, and you end up trading bias for memory usage depending on the resolution of each surface map. It's great if your search space is just a chain of 10 possible discrete actions, but when you're talking thousands of pixels which are technically a continuous space, the GI cache does a similar job and far more efficiently.