[Bf-cycles] Lightprobe importance sampling

[Mike Farnsworth]

On Thu, Jan 5, 2012 at 11:59 AM, Brecht Van Lommel
<brechtvanlommel at pandora.be> wrote:
> On Thu, Jan 5, 2012 at 6:55 PM, Mike Farnsworth
> <mike.farnsworth at gmail.com> wrote:
>> In kernel_path.h it samples the background on ray misses.  But now the
>> background is also sampled as a light (when that light is chosen), so
>> sampling the background on a ray miss amounts to doubling up the light
>> from the background at the last bounce.  I added a check in
>> direct_emission where it'll notify the calling integrator if the light
>> it sampled was the background, so it can avoid sampling the background
>> again the next time through the path trace loop if the next ray
>> misses.  So far so good.
>
> I don't think this is needed, it should not disable sampling the
> background the next time, they should just be weighted with MIS.

Agreed, this is essentially the end-product of what I'm proposing.
Since the BSDF sample happens anyway, we just need to remember the
BSDF PDF and calculate the light's PDF; that way we can do the other
side of the MIS when we hit the background on that path bounce.

Although, I swear I tried reusing the BSDF's direction/PDF for the
next leg of the path with the direct lighting MIS in RenderSpud, and
it didn't behave right.  I still do a separate sample of the BSDF and
an extra ray against the chosen light (only) there.  I'm pretty sure
that's what PBRT does as well, but I would be very happy to prove
myself wrong and avoid the extra sample.

>> However, it ends up being darker than it should be, especially for the
>> more specular surfaces.  I think I figured out why.  In
>> kernel_emission.h light sampling routines, we sample the light and its
>> PDF, then ask the BSDF for its PDF given that direction, and then we
>> perform MIS.  However, we never ask the BSDF for a direction and then
>> ask the light for its PDF for *that* direction as well (with a shadow
>> ray check), and add that in.  We have to have both, or else the tight
>> glossy surfaces never have a chance to add in light based on the
>> BSDF's preferred direction.
>
> For mesh lights, this is done in indirect_emission. Other lights don't
> use MIS yet.

Well, the background lights do participate in MIS (that's part of my patch). =)

>> I double-checked both PBRT and RenderSpud, and they both have that
>> second direction's contribution mixed in when doing MIS for lights.  I
>> think the technically correct thing to do is generate the BSDF's
>> preferred direction, cast a ray, and if it hits *any* area light (area
>> light, mesh/triangle light, background light) then factor that in.
>> But for now, I'm just going to have it cast a ray for the BSDF
>> direction to see if it hits nothing, and then sample the background,
>> and mix that in with MIS with respect to the BSDF's PDF for the second
>> direction.
>
> The way I see this is, you have two ways to render the emission, one
> using BSDF sampling and one using Light sampling. When leaving out the
> MIS factor, they should both converge to the same result.

This is true, but once you include the MIS weighting, you have to
sample the one with respect to the other, and vice versa, and then mix
both using MIS.  Without MIS, yes, you can choose direction/PDF and
it'll eventually converge.

> It is not needed that for every Light sample ray, there is a matching
> BSDF sample ray, all that is needed is that the pdf's match. Avoiding
> that extra BSDF sample and instead doing it using the BSDF sample that
> is already done for the next path vertex gives a nice speedup.

Definitely.  I think I'm going to have the background sampling
explicitly calculate the background light's PDF, then apply MIS with
respect the BSDF's PDF on the last bounce.  I think that will cover
it, and hopefully not complicate the code much.  I'm sure you'll have
some feedback for me in this regard when you see it.

-Farny