Choosing clamping limit in VPL rendering back

(L) [2014/01/26] [ost by khalidsalman] [Choosing clamping limit in VPL rendering] Wayback!

Hi all,

I was looking at the IGI algorithm for VPL rendering. A well known issue is the spikes\singularities resulting from a high Geometry factor in the rendering equation. The issue is well laid out by Simon Brown at his blog:  >> "The second issue is a problem because the optimal b (one that removes just enough energy to hide the singularities) will vary with light path density in the scene, and exposing a parameter for something generally means it will be set to something very inoptimal."
A simple issue that comes to mind with a fixed limit value is that just scaling the scene will require a different limit value to get the same effect.

I was looking at literature concerning this and didn't find much help, probably I missed some important hints, not sure. Any thoughts?

Thanks you!

(L) [2014/01/26] [ost by ingenious] [Choosing clamping limit in VPL rendering] Wayback!

A very easy and relatively robust solution is to only clamp the final pixel contribution to some maximum value, say 10. This way you make sure that a single VPL cannot contribute huge amount of energy (either due to low PDF, due to landing around a corner, or due to a sharp BRDF). This parameter is much easier to control than some world-space minimum distance. In addition, you'll get lower bias automatically when you increase the number of VPLs  (because the weight of each VPL, and thus its contribution to the image, will be lower).

If you have a progressive rendering pipeline, then you can make the algorithm consistent by increasing the clamping threshold at every iteration. You can read more about this here:
[LINK http://www.iliyan.com/publications/ProgressiveLightcuts]

(L) [2014/01/27] [ost by khalidsalman] [Choosing clamping limit in VPL rendering] Wayback!

Many thanks ingenious for the response. I am also looking at your other papers on the subject, great work!

(L) [2014/01/27] [ost by Zelcious] [Choosing clamping limit in VPL rendering] Wayback!

Or don't clamp:

Illumination in the Presence of Weak Singularities
with Alexander Keller
Monte Carlo and Quasi-Monte Carlo Methods 2004

But it of course depends on how you render your vpl, you may not have the option.

(L) [2014/01/27] [ost by ingenious] [Choosing clamping limit in VPL rendering] Wayback!

>> Zelcious wrote:Or don't clamp:

Illumination in the Presence of Weak Singularities
with Alexander Keller
Monte Carlo and Quasi-Monte Carlo Methods 2004

But it of course depends on how you render your vpl, you may not have the option.
True, however if you can afford tracing subpaths from the camera, you'd probably be better off doing full bidirectional path tracing of which this clamping compensation is a special case. Especially if you have glossy materials.

(L) [2014/01/27] [ost by Zelcious] [Choosing clamping limit in VPL rendering] Wayback!

Glossy is one thing and should be treated with care but I'm not sure bidirectional is more efficient otherwise. Would be interesting to see some statistics.

(L) [2014/01/27] [ost by toshiya] [Choosing clamping limit in VPL rendering] Wayback!

>> ingenious wrote:A very easy and relatively robust solution is to only clamp the final pixel contribution to some maximum value, say 10. This way you make sure that a single VPL cannot contribute huge amount of energy (either due to low PDF, due to landing around a corner, or due to a sharp BRDF). This parameter is much easier to control than some world-space minimum distance. In addition, you'll get lower bias automatically when you increase the number of VPLs  (because the weight of each VPL, and thus its contribution to the image, will be lower).

If you have a progressive rendering pipeline, then you can make the algorithm consistent by increasing the clamping threshold at every iteration. You can read more about this here:
[LINK http://www.iliyan.com/publications/ProgressiveLightcuts]
Pixel-space clamping (?) sounds interesting, but can we use it in the progressive algorithm where VPLs are accumulated immediately and the contribution of each VPL gets progressively lower?

(L) [2014/01/27] [ost by tomasdavid] [Choosing clamping limit in VPL rendering] Wayback!

>> Zelcious wrote:Glossy is one thing and should be treated with care but I'm not sure bidirectional is more efficient otherwise. Would be interesting to see some statistics.
One of the main advantages of the paper, the limit on max path length of the compensating rays, works only when you know you have purely diffuse scene, I am afraid. Without it, it is pretty much just a BPT with different weights. Also, clamping in glossy setting is not well explored (you probably need to clamp BSDF as well as G term).

(L) [2014/01/28] [ost by ingenious] [Choosing clamping limit in VPL rendering] Wayback!

>> toshiya wrote:Pixel-space clamping (?) sounds interesting, but can we use it in the progressive algorithm where VPLs are accumulated immediately and the contribution of each VPL gets progressively lower?
In a progressive setup, where at each rendering iteration you sample a fixed number of light paths and accumulate all resulting images, you need to progressively increase the pixel clamping threshold, as discussed in our Siggraph sketch linked above.
 >> tomasdavid wrote:Without it, it is pretty much just a BPT with different weights.
And not too well justified weights, I'd add. It's effectively a combination of different path sampling techniques based on a heuristic classification of paths (instead of the smooth weighting provided by Veach's MIS heuristics).

(L) [2014/01/28] [ost by toshiya] [Choosing clamping limit in VPL rendering] Wayback!

>> ingenious wrote:
In a progressive setup, where at each rendering iteration you sample a fixed number of light paths and accumulate all resulting images, you need to progressively increase the pixel clamping threshold, as discussed in our Siggraph sketch linked above..
My question is, wouldn't it be kind of "suboptimal" in the sense that we ignore the fact that the more VPLs you have in total, the lower each contribution becomes?

For example, let's say we trace 100 light subpaths for each iteration and do 1000 iterations (i.e., we get O(100K) VPLs). If we clamp pixel-contributions of VPLs considering only VPLs (100 VPLs) within each iteration, which I think you suggest and with the progressively increasing threshold, wouldn't it be different from clamping pixel-contributions of all the VPLs (i.e., O(100K) VPLs) with the same threshold adjusted according to the number of VPLs?