1
$\begingroup$

In the Multiplexed Metropolis Light Transport implementation of the book Physically Based Rendering, the proposal samples are generated by the Primary Sample Space Sampler MLTSampler.

I'm not sure if I really understand what the authors mean in the following paragraph:

In the context of MLT, the resulting sequence of sample requests creates a mapping between components $X$ of and vertices on the camera or light subpath. With the process described above, the components $X_0,\ldots,X_n$ determine the camera subpath (for some $n\in\mathbb N_0$), and the remaining values $X_{n+1},\ldots,X_m$ determine the light subpath. If the camera subpath requires a different number of samples after a perturbation (e.g., because the random walk produced fewer vertices), then there is a shift in the assignment of primary sample space components to the light subpath. This leads to an unintended large-scale modification to the light path.

Does this mean that even for a fixed strategy with $n\in\mathbb N_0$ vertices on the camera subpath, the number of random numbers needed to generate such a subpath may vary? Or do they mean that the shift in the assignment is happening only when we switch to an other strategy?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

For a fixed strategy, you can end up consuming a different number of samples depending on your mutation. This can happen for at least two reasons. If your perturbation changes some material along the path to, say, a multi-lobe BSDF, you would need more samples to account for the lobe choice. This would shift everything by the number of extra samples used. If your ray eventually escapes the scene as you are tracing your mutation, or it hits a light source prematurely, you would use fewer samples. In these cases, you'd have to reject this proposal automatically.

One way of mitigating this issue in practice is to separate the two random number vectors for the camera and light subpaths and always mutate all dimensions of the unit hypercube $\mathcal{U}^{o(k)}$, regardless if they are being used or not by the mutation. This doesn't remove the shift caused by BSDF changes (which is unavoidable) but at least you're not spilling your samples between camera and light subpaths.

Note that changing the strategy can also lead to an undesired rippling effect as primary samples will be used to perform a slightly different task (i.e. tracing a different strategy). This can be handled by introducing inverse mappings to preserve the geometry of the path, which is what is done by Reversible Jump MLT.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Thank you for your answer! "If your ray [...] hits a light source prematurely, you would use fewer samples.": Consider the $(s,t)$-strategy so that we generate a camera subpath with exactly $t$ vertices. If we hit a light source prematurely, then the GenerateCameraSubpath routine returns a vertex count less than $t$ and the PBR implementation returns $0$ radiance. So, "In these cases, you'd keep the subpart of the path that is relevant to avoid discarding the full state.", seems to be wrong. Am I missing something? $\endgroup$
    – 0xbadf00d
    Jan 7, 2020 at 16:12
  • $\begingroup$ You're right, I've edited my answer. There might be a way to actually recycle but you'd have to adjust the MH ratio accordingly and I'm not sure how. In my experience, this recycling is probably not worth doing. $\endgroup$
    – Hubble
    Jan 7, 2020 at 16:30
  • $\begingroup$ I think that I still don't understand the citation: Say the current primary sample space state is $u\in[0,1)^\mathbb N$ and we generated a path $x$ of length $k=s+t-1$ with $s$ and $t$ vertices on the light and camera subpath, respectively, from it. Say the camera subpath was generated using $u_1,\ldots,u_{d_1}$ and the light subpath using $u_{d_1+1},\ldots,u_{d_2}$. In the next iteration $u$ is mutated to $v\in[0,1)^\mathbb N$ (i.e. all dimensions are mutated). If I got you right, then - no matter whether we are still using the $(s,t)$-strategy in the next iteration or any other strategy - $\endgroup$
    – 0xbadf00d
    Jan 7, 2020 at 19:31
  • $\begingroup$ it might be the case that a subset of $v_1,\ldots,v_{d_1}$ is now used for the light subpath and a subset of $v_{d_1+1},\ldots,v_{d_2}$ is now used for the camera subpath (and any dimension $>d_2$ might be used for the light subpath as well). Is this correct? (a) If so, how does the index scheme described in the paragraph solve this problem? (b) You've mentioned the inversion described in RJ-MLT: How does this solve the problem? (c) Is there an implementation of the inversion in PBR available? See also my other question for that: computergraphics.stackexchange.com/q/9443/9254. $\endgroup$
    – 0xbadf00d
    Jan 7, 2020 at 19:31
  • $\begingroup$ Or let me put question (a) otherwise: If I understand correctly what they are doing, they actually have three separate vectors for each "stream" so that never a component of the camera stream vector is used for sampling the light subpath (and vice versa). If that's the case, I don't understand why they use the (somehow complicated) indexing scheme of a single vector. $\endgroup$
    – 0xbadf00d
    Jan 7, 2020 at 19:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.