[Bf-cycles] Lightprobe importance sampling

Mike Farnsworth mike.farnsworth at gmail.com
Thu Jan 5 18:55:56 CET 2012


Replying to myself for a li'l progress report.

>> I've refactored the code a bit now in svn to shader evaluation for
>> this possible, is a bit tricky with kernel/device changes. Attached a
>> patch that will dump the background to an image as an example.
>
> Thanks!  I'll try that out today.  Last night I just iterated the
> shader graph looking for environment image nodes, then used OIIO to
> load it and iterate it quickly to build the map, but that is pretty
> hackish and restrictive.

Brecht, your changes worked like a charm.  Thanks for doing that.  I
have pretty much everything working I think, and the reduction in
noise is pretty substantial.  But there is one (hopefully final)
detail I discovered last night.

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.

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.

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.

I'm going to get a first-pass patch ready tonight with all of this so
that you can see it, but there's a bit more polishing I'd like to do
before I ask for it to be committed.  If any of this is confusing, let
me know, and I'll make some diagrams to show what I'm talking about.
=)

-Farny


More information about the Bf-cycles mailing list