[Question] Details on computing VPL area

[VC86]

Hello,

I was trying to reproduce the results of your work on AMCW ToF simulation with simplified indirect lighting (using RSMs) as I'm interested in evaluating how fast this technique can run (by the way, very nicely written).

Among the equations reported in the paper, with reference to one finds that:

• the scene radiance contribution of indirect light can be approximated by summing elements of the RSM, where each element contributes with a quantity depending on scene radiance at the target point
• if we assume all Lambertian BRDFs ($f = \rho/\pi$) we can reuse the scene irradiance from direct illumination to compute the above radiance
• my main question pertains the weight factor $W$ which models light traveling from the VPL at a given location $P'$ to $P$ where the (e.g., Lambertian) reflector is placed. However, both in your documentation and in the paper the weight depends on a VPL area quantity $A_{P'}$ that is not explicitly defined in the paper. I perhaps lack background and this may be trivial to you -- how do you define the area of the VPL? I see that in RSMs one uses flux to avoid having to specify area, but in the paper you say you compute and store explicitly the areas of the individual VPLs. Could you pinpoint where this is done in the code and/or an explicit formula for the area of the VPLs?

Thanks (and thanks for your interesting work).

[marlam]

Hello, thank you for your interesting question!

CamSim contains a reimplementation of the RSM idea and does not implement the paper 1:1. It uses a different derivation of the light transport approximation, described in doc/illumination.tex (see illumination.pdf). This version intentionally avoids area estimations. Furthermore, it also avoids the problematic one-over-distance-squared term from Equation (10) because that breaks down for very small distances, e.g. in corners. See also src/simulation-everything-fs.glsl line 469ff.

There are more ways in which CamSim differs from the paper. For example, in CamSim the RSM is a cube map so that it can capture the entire environment.

I am not sure how the VPL area was estimated in the original implementation for the paper, and I don't have access to the original source code; if you need that, please contact A. Kolb.

As a side node, nowadays I would suggest using path tracing to simulate multipath effects (and all other relevant effects), even if your goal is speed, since GPUs can now accelerate path tracing too (even though rasterization will still be faster). See for example WurblPT for a CPU-based path tracer that implements ToF simulation.

[VC86]

Dear @marlam,

thank you for this reply and your support! I have a few questions to clear out the differences between the paper and your implementation, if you don't mind. I fully agree that it could be possible to switch to path tracing but I'd still like to have at least the original option for comparison up and running.

Related to that:

• You mention that you are able to work around the $1/r^2$ term (which is known to be an issue in VPL approaches and I've found a few papers tackling it directly). What is the gist? I would expect that this squared distance decay is required to model the bounce between $Q$ and $P$ (in the notation of the paper and your notes). Where is it "hidden" in your formulation?
• You mention no area is required in your computation: what's the reasoning behind your approach vs. that in the paper? I was indeed able to implement most of the paper except for the undefined area computations, but I believe the incorrect areas I used are creating the scale issues I observed (global orders of magnitude stronger than direct when observing a wedge). So how does one get around that?
• Note: in my case I cannot assume point light source, but I believe this shouldn't be a problem as long as I have the (direct, light source to point) radiance $L_{S \rightarrow x}, \forall x$ in the scene.
• In your notes I see an $|\text{RSM}|$, I assume it denotes cardinality so you're taking a mean over all Q in the RSM?
• If one is to replace $\forall x, fx = \rho/\pi$ (Lambertian BRDF) then in your writeup (assuming $S$ is the source location) one would have $$L{\rm scene} = L{\rm direct} + L{\rm global}$$ where $$L{\rm global} = \frac{1}{|\text{RSM}|} \sum{Q \in \text{RSM}} \frac{\rhoP}{\pi} \left({L{S \rightarrow Q} \frac{\rhoQ}{\pi} \cos \vartheta{Q \rightarrow S} }\right) \cos \vartheta{P \rightarrow Q} $$ where I have put in parentheses the radiance $L{Q \rightarrow P}$. Is this expansion correct?

Thanks again for your attention!

[marlam]

Hmm, it seems I did not remember the details correctly. There is indeed still a $1/r^2$ term in CamSim, in the attenuation_factor which models the OpenGL attenuation term. With the defaults attenuationConstant=1, attenuationLinear=0, attenuationQuadratic=1, it is basically $1/(1+r^2)$. This avoids the breakdown for $r<1$, but it just sweeps the problem under the rug instead of solving it. The CornellBox example uses attenuationConstant=0 to get the original $1/r^2$ behavior, presumably to be closer to physically based renderers.

Regarding VPL areas and scaling problems: unfortunately I cannot remember the details anymore. The changes in the CamSim model were made to use radiance and avoid area estimations where possible. For details regarding the original paper implementation, please contact A. Kolb.

Yes, $|RSM|$ is the cardinality, so it's basically the mean of all VPLs.

Yes, I think your formulation for Lambertian BRDFs is correct.

[VC86]

Many thanks for these details @marlam , I asked directly Prof. Kolb for details on the area computation. I also see in some papers there is such a thing as clipping the geometry term (in your case, the weight factor) to avoid overshoots that cause known artifacts for $r \rightarrow 0$; will post the reference later. I will close the issue once I have reported back the answer.