Re: About volumetric caustics. back

(L) [2013/11/14] [ost by shiqiu1105] [Re: About volumetric caustics.] Wayback!

>> friedlinguini wrote:What mumbo-jumbo is that? Kelemen-style MLT doesn't require much. You need to to feed sample results back to the random number generator, and let the thing warm up a bit to generate an average intensity and eliminate start-up bias. Otherwise it's not really any more complicated than, say, replacing a naive RNG with a QRNG. Is there something else?
Is it really that simple?! I am using a QRNG already. I am using sobol sequence.
Is MLT just a matter of replacing the RNG?!

(L) [2013/11/14] [ost by zsolnai] [Re: About volumetric caustics.] Wayback!

The Primary Sample Space MLT by Kelemen et al. [1] is mostly about manipulating the random number generator. The original Veach Metropolis [2] is however a different story.

[1] [LINK http://www.iit.bme.hu/~szirmay/paper50_electronic.pdf%E2%80%8E]
[2] [LINK http://www-graphics.stanford.edu/papers/metro/]

(L) [2013/11/14] [tby zsolnai] [Re: About volumetric caustics.] Wayback!

The Primary Sample Space MLT by Kelemen et al. [1] is mostly about manipulating the random number generator. The original Veach Metropolis [2] is however a different story.
[1] [LINK http://www.iit.bme.hu/~szirmay/paper50_electronic.pdf]‎
[2] [LINK http://www-graphics.stanford.edu/papers/metro/]

(L) [2013/11/14] [ost by Dade] [Re: About volumetric caustics.] Wayback!

>> toxie wrote:But that doesn't include all the additional mumbo-jumbo that the rest of the renderer has to support to make it "simple" like this..
The above code just generated (on demand, it implements Kelemen-style lazy evaluation) float values as the most simple Random Sampler, there isn't any particular support to add around the code. The main real difference, when compared for instance to a Random or Sobol Sampler, is the requirement to "close the loop" (i.e. the Sampler needs to know the sampling result before to generate a new value).  Metropolis is also tile-rendering unfriendly (i.e. doesn't make very much sense in that case) but otherwise is easy to implement.

Now, if we talk about GPUs, that is a different matter. MTL has some peculiar limit on GPUs.

P.S. indeed, I'm talking about Kelemen's Metropolis. I don't see the point in implementing Veach's Metropolis after Kelemen's paper. It doesn't seems worth the (insane) effort to me.

(L) [2013/11/15] [ost by friedlinguini] [Re: About volumetric caustics.] Wayback!

>> shiqiu1105 wrote:Is it really that simple?! I am using a QRNG already. I am using sobol sequence.
Is MLT just a matter of replacing the RNG?!
There's more to it than that, but not much. There's the warm-up that I mentioned, you let the RNG dictate where to place samples rather than iterating over pixels, and you have to scale the intensity of the individual samples, since messing with the RNG changes the PDF of the sample. For bidirectional path tracers there's some funkiness about keeping dimensions in random number space associated with path segments, but the same logic would apply to QRNGs (you don't HAVE to do it, but it helps). Paper [1] that zsolnai mentioned lays it all out pretty completely, including code.
 >> Dade wrote:P.S. indeed, I'm talking about Kelemen's Metropolis. I don't see the point in implementing Veach's Metropolis after Kelemen's paper. It doesn't seems worth the (insane) effort to me.
Veach's MLT is more computationally efficient, since it lets you reuse portions of the path between mutations, but it's harder to get right.

I find it truly weird that there has been almost no additional research done in primary sample space MLT. I think Csaba Kelemen posted some code for a newer version (on the original ompf, in fact) at one point, but with no explanation about its workings. That code still exists at [LINK http://www.hungrycat.hu/MetropolisSampler.html]. It's terrifyingly short and supposedly doesn't need the warm-up phase.

(L) [2013/11/15] [ost by shiqiu1105] [Re: About volumetric caustics.] Wayback!

Anyway, I guess the take home msg for volumetric caustics is I need to at least do a Metropolis sampled BDPT right?

And, besides sampling methods, I am also quite unsure about how to implement multiple scattering with BDPT or PT either. Any recommended tutorial?

(L) [2013/11/15] [ost by ingenious] [Re: About volumetric caustics.] Wayback!

>> shiqiu1105 wrote:Anyway, I guess the take home msg for volumetric caustics is I need to at least do a Metropolis sampled BDPT right?
First try basic BPT. It may work well for your scenes. You can then add Metropolis sampling on top.
 >> shiqiu1105 wrote:And, besides sampling methods, I am also quite unsure about how to implement multiple scattering with BDPT or PT either. Any recommended tutorial?
I haven't seen a tutorial, but there was some SmallPT-like code around that included participating media. In a nutshell, you do standard PT/BPT, just that a path can also scatter in media. So the vertices on a path can be either in a medium or on a surface.
 >> friedlinguini wrote:There's the warm-up that I mentioned...

...I think Csaba Kelemen posted some code for a newer version (on the original ompf, in fact) at one point, but with no explanation about its workings. That code still exists at [LINK http://www.hungrycat.hu/MetropolisSampler.html]. It's terrifyingly short and supposedly doesn't need the warm-up phase.
I think there are some misconceptions about MLT, warm-up and bias. The problem seems to root in the thesis of Veach, who made MLT unbiased, but did not clearly state that in order to converge to the correct solution you need to average over many independent chains. His warm-up method performs simple resampling of paths to choose the initial element in the chain from a distribution that is closer to the target. He then described an algorithm that uses a single chain for the whole image. This algorithm is unbiased, but does not converge with a single chain due to the chain weighting. The ERPT paper showed that you can indeed go without a warm-up phase and instead sample many independent chains. If Veach had pointed this out more clearly in his thesis, the ERPT paper could have been much harder to get published [SMILEY :)] There's obviously the trade-off here between adaptation (a few long chains) and stratification (more short chains). We've discussed this topic on the OMPF before. One could argue that a longer chain is better when you have very difficult paths to find, but one should keep in mind that in such scenes the warm-up phase needs to sample a much higher number of initial candidates so as to obtain a reasonably accurate scaling factor.

Edit: OK, Veach's algorithm actually samples a number of chains. But there's no fundamental requirement to do the warm-up. Interestingly, the one-chain algorithm actually corresponds to traditional Metropolis sampling, where the weighting obtained in the warm-up phase is essentially the estimate for the target PDF normalization. So if you're doing one-chain MLT, I'd think it's better to forget about the warm-up and start-up bias, and do it the classic way where you accumulate the target PDF normalization on the side. This way you'll converge to the correct solution.

Sorry for turning the topic into an MLT discussion [SMILEY :)]

(L) [2013/11/16] [ost by shiqiu1105] [Re: About volumetric caustics.] Wayback!

Now that we are discussing this, I am curious that if MLT like algorithm is so robust, why do we still care about algorithm like VCM?
Can MLT handle SDS path efficiently?

(L) [2013/11/16] [ost by ingenious] [Re: About volumetric caustics.] Wayback!

>> shiqiu1105 wrote:Now that we are discussing this, I am curious that if MLT like algorithm is so robust, why do we still care about algorithm like VCM?
Can MLT handle SDS path efficiently?
It very much depends on the scene whether VCM or MLT would be more efficient. If you have complex visibility, MLT could be better. But if your make sure that the light can reach important regions easily, then VCM will be. I think that VCM should perform better for most scenes, and MLT is for the more pathological cases. But my opinion is biased [SMILEY :)]

(L) [2013/11/16] [ost by Dade] [Re: About volumetric caustics.] Wayback!

Does make sense to compare VCM and a Metropolis Sampler ? I mean, aren't they orthogonal and solve different kind of problems ? I use BPT+VCM with a Metropolis Sampler; there is nothing preventing to use both.

Anyway a Path racer with a Metropolis Sampler have no hope to render any no trivial SDS paths.

(L) [2013/11/16] [ost by shiqiu1105] [Re: About volumetric caustics.] Wayback!

>> Dade wrote:Does make sense to compare VCM and a Metropolis Sampler ? I mean, aren't they orthogonal and solve different kind of problems ? I use BPT+VCM with a Metropolis Sampler; there is nothing preventing to use both.

Anyway a Path racer with a Metropolis Sampler have no hope to render any no trivial SDS paths.
Yeah, I agree with you.

However I am really sick of the noise produced by Monte Carlo based methods like path tracing/BDPT.
The following is an image produced by my own BDPT renderer, over 1000 SPP but still quite noisy!

So is VCM, like photon mapping, able to give you an image that's noiseless much faster?
Or will irradiance caching helps BDPT get rid of the noise?

[IMG #1 EDXResult.jpg]
Also, is the white noise in the far door a bug in my BDPT..?

---

[IMG #1]:Not scraped: /web/20201124004154im_/http://ompf2.com/download/file.php?id=142&sid=238b6d6515cd87cc956081fdb65309fc

(L) [2013/11/17] [tby ingenious] [Re: About volumetric caustics.] Wayback!

On this scene neither VCM nor Metropolis will help. I suggest caching illumination in some data structure and then do distribution ray tracing at the first bounce from the camera to query this structure. That is, using something like VRay's light cache. Irradiance caching is also great for this scene, but people in high quality rendering seem to move away from algorithms that interpolate directly visible illumination.

(L) [2013/11/17] [tby shiqiu1105] [Re: About volumetric caustics.] Wayback!

>> ingenious wrote:On this scene neither VCM nor Metropolis will help. I suggest caching illumination in some data structure and then do distribution ray tracing at the first bounce from the camera to query this structure. That is, using something like VRay's light cache. Irradiance caching is also great for this scene, but people in high quality rendering seem to move away from algorithms that interpolate directly visible illumination.
What about photon mapping. I knew that it can produce noiseless images fast. But it's not recommended?

(L) [2013/11/17] [tby shiqiu1105] [Re: About volumetric caustics.] Wayback!

>> ingenious wrote:On this scene neither VCM nor Metropolis will help. I suggest caching illumination in some data structure and then do distribution ray tracing at the first bounce from the camera to query this structure. That is, using something like VRay's light cache. Irradiance caching is also great for this scene, but people in high quality rendering seem to move away from algorithms that interpolate directly visible illumination.
Also, I was trying to google light caching algorithm, but got little useful result of how it's implemented. Any pointers? Thanks~

(L) [2013/11/17] [tby friedlinguini] [Re: About volumetric caustics.] Wayback!

>> shiqiu1105 wrote:What about photon mapping. I knew that it can produce noiseless images fast. But it's not recommended?
Not recommended by who, and for what? There are some things that photon maps are good for (avoiding noise, rendering LSDSE light paths, ease of implementation), and some things that they are less well suited for (rendering landscapes, slower convergence than BDPT, glossy materials, might require some manual parameter tweaking).
As far as I know we don't yet have a One True Algorithm (low bias/error, noiseless, accurate previews, parameterless, handles arbitrary materials and geometry, easy to implement, etc.). You have to decide what features are important, and what weaknesses you can live with.