Page MenuHome

Cycles: Use correct multisample MIS model for branched path tracing
Needs RevisionPublic

Authored by Lukas Stockner (lukasstockner97) on Jun 12 2017, 5:46 AM.



Currently, the code just always uses the regular MIS model with one light and one BSDF sample that's been used for path tracing.
For BPT, however, that is not really great since the user can control the amount of samples taken there. Therefore, while it still converges to the correct result, there's unneccessary noise when using very different values for light and BSDF samples.

This patch makes the MIS calculation account for sample numbers when using BPT, which can lead to a huge decrease in noise in some scenes (examples following soon). PT results are unchanged.

Diff Detail

rB Blender
Build Status
Buildable 695
Build 695: arc lint + arc unit

Event Timeline

Here's the tests:
First off, a very simple one - a diffuse plane illuminated by a HDRI background using BPT, 1 AA sample and 64 World samples per AA sample:


And here's a recreation of the famous Veach MIS scene:

It contains two setups, one for lamps (layers 1+2) and one for meshlights (layers 1+3).
Lamps (Sample All, 1 AA sample, 16 samples/AA/lamp):




Rendertimes are identical (within fluctuation).

Also, note another unrelated problem in the meshlight scene: Since sampling weights are only based on area, the smaller lights get almost no samples despite emitting the same total energy. However, determining the average radiant exitance of a shader is tricky, so I didn't look into this yet.

Some more changes to light MIS handling, this time giving a slight improvement for regular path tracing by moving the lamp picking PDF into the actual light sampling PDF instead of having its inverse in the eval_fac.

Also, it includes a fix for incorrect brightness in BPT when using both lamps and meshlights.

And here's example renders for the new improvement:

Veach MIS scene in lamp configuration, Path Tracing, 32spp:


Brecht Van Lommel (brecht) requested changes to this revision.Jun 19 2017, 9:53 PM

Besides the comments it looks right to me, but this is tricky code so I can't say it confidently. Perhaps best to leave for after 2.79? Though it's a great improvement if the number of samples are very different between BSDFs and lights...


I think this 2.0f factor is only needed if(kernel_data.integrator.num_all_lights != 0)?


kernel_data.integrator.pdf_lights is being multiplied into ls->pdf in both light_sample and lamp_light_sample, that seems wrong?


Same here.

This revision now requires changes to proceed.Jun 19 2017, 9:53 PM