While looking for a block allocator I stumbled across your blog. I wanted to get a bit of advice on using your allocator with my multimap. I have included my initialization of my multimap and would appreciate your advice in making the modifications to use your allocator in my code shown below.

Many thanks,
TonyL

[code language="c++"]
/* Define Coordinate list (COO) multimap. */
typedef multimap <mwIndex,double,std::less > COO_mmp;
/* Define Coordinate list (COO) multimap iterator. */
typedef COO_mmp::const_iterator mmpi;

/* Declare the multi-map of un-merged non-zeros. */
static COO_mmp non_zeros_um;
[/code]

Apart from that, a very neat sum-up! Thanks for the work

You can also notice that often we only need to sample an hemisphere (when sampling the sky).

ie. that we can separate the sky sampling into 2 hemisphere sampling… and use 2 different sampling probability too.

Of course, it depends of the scene !

You only need to add the distance sampling, which results in slightly different pdf if the point ends up being in the medium or on a surface, but that’s essentially it.

Well maybe it’s just my maths that are a bit rusty then, I didn’t find the new path space measure to be trivial, but that’s essentially it.

Please confirm that to me.

I’ve been playing recently with path reuse in a bit more general sense than BDIR, and unfortunately I’ve established that it’s rather difficult to reuse paths in an unbiased way. The main reason is that you have to compute marginal densities, for which an unbiased estimator is not sufficient to obtain unbiased final pixel estimates – the expected values just don’t work out. This is quite unfortunate, since there’s a lot potential for path reuse. There have been some successful attempts (e.g. Baekert’s path reuse paper), which are very restricted though.

The lesson is, it’s straightforward to estimate light transport along the full paths we trace with random walks, but it’s difficult or even impossible in the general case to obtain unbiased estimates along paths constructed by reusing vertices/segments from other paths.

1). In the definition of the virtual sensor, the z in the diagram is \(\mathbf{z}_0\). \(\mathbf{z}_1\) is formed as the second vertex of the eye subpath from the virtual sensor. This should indeed be clarified, I’ll try to update the text to improve this later. Note the \(\mathbf{v}_i\) are only used to estimate \(P_A\), they do not take part in BDPT.

2). The VPLs are indeed created directly from BDPT. I think perhaps I should move the “Bidirectional Path Tracing” section first with more details, then cover the virtual sensor later. Bidirectional paths start at a light source and end at a VPL, this is why in the S=T=3 example there are VPLs only where the sensor is sampled (at \(\mathbf{z}_0\)) or hit (at \(\mathbf{y}_1\) and \(\mathbf{y}_2\), which do indeed need marginal density calculated). Edit: this is mentioned by Segovia et al, but I think a lot of the work done for the density can be reused for resampling later.

3) Ah yes this is mentioned by Segovia et al, estimating \(P_A\) does introduce bias. I’m quite interested if approximations to this can be used (e.g. some CDF over all surfaces in the scene) instead of an estimate. If the approximation has an analytical pdf, this would eliminate the bias (as well as a ton of visibility tests).

Thank again for the feedback, I’ll post another comment when I get chance to address the changes.