1
$\begingroup$

I'm working on a monte carlo path traced application. To make life easier I've only been looking at Lambertian surfaces with LR = 1. I've implemented multiple importance sampling, with one sample for NEE and one for cosine weighting. The trouble I've come into is that the sampling from NEE has a tiny weight and even though the sampling correctly hits the light source very frequently, because of the low weight (e.g. 0.05 to 0.999 for cosine weight), the results are essentially discarded and the light has very low effect. I'm using the power heuristic for weighting, and after doing some cancellation and removing redundant terms (e.g. only 1 sample each, and LR = 1) this is the result:

$$ \sum_{D\,\in\,distributions} \sum_{I\,\in\,S(D)} \frac{L_i(P, I)\,pdf(D, I)\,dot(N, I)}{\pi\,(pdf(NEE, I)^2 + pdf(cosine, I)^2)} $$

In this case I'm using a single sphere light uniformly cone sampled according to PBRT, so this is $cos\,\theta = (1 - \xi) + \xi\,cos\,\theta\,$ for sampling and a PDF of $\frac{1}{2\pi (1 - cos\, \theta max)}$ for NEE samples, and $cos \,\theta = \sqrt{\xi}$ with PDF $\frac{cos \theta}{\pi}$ for cosine weighting. When computing the PDF for NEE samples, I check if the sample is actually within the light source's cone, and if not, set the weight as 0 as this sample can't be generated with the NEE distribution.

The basic issue comes when $\theta$ is quite small, so the NEE PDF works out as quite high for any given sample; I picked a pixel where this was 5.4. This blows out the bottom term so that the final weight is very low. Meanwhile cosine samples have a value of zero so they maintain a high weight. Or in other words, the NEE samples seem very likely just because they can be picked by the NEE distribution at all, whereas cosine samples seem way more unlikely than they really are. This seems to make MIS weight them very highly.

If I had to guess, I'd say the issue is that the PDF for the cone is based on the assumption you are picking a sample from just the cone, which I'm combining with a PDF for the whole hemisphere, so the domains are wrong?

I tried adding a fixed bias for NEE samples, which improves the situation, but only a little; when the bias is big compared to the PDF the result looks good, but as the angle gets smaller, the PDF dominates the bias, so it only works out to some fixed distance.

Any suggestions on fixing my weights so that NEE samples are weighted correctly?

$\endgroup$
5
  • $\begingroup$ The NEE PDF is normally: 1 / emitter_pdf * geometry_term, where 1 / emitter_pdf is usually the inverse area of the emitter, and geometry_term converts the area product measure to the solid angle measure (at the shading point). So I really don't understand the NEE PDF of yours (and even, the light sampling method), since I can find neither of them. Maybe you can share the link to your code to clarify this? $\endgroup$ Commented Sep 30, 2024 at 4:58
  • $\begingroup$ I used the method and PDF given by PBRT, pbr-book.org/4ed/Sampling_Algorithms/…. This is the relevant HLSL github.com/DeadMG/dx12/blob/master/Renderer.Direct3D12/Shaders/…; for efficiency I'm precomputing all terms other than $L_i$. Currently there's only ever one LightSource which is a spherical light. $\endgroup$ Commented Sep 30, 2024 at 11:58
  • $\begingroup$ Did you forget to normalize the nee pdf by the sum of all lights' power? Line171: total += light.Power * (1.0f / (2.0f * PI * (1.0f - cos(angle))));, you return total without normalizing it, light.Power should have been light.Power / sum(lights[...].Power) to make total a valid PDF. $\endgroup$ Commented Sep 30, 2024 at 14:01
  • $\begingroup$ There's a separate normalization step for the lights and their powers that occurs first, to adjust each light's power for distance and such. Additionally in this test there's only one light with a power of 1. I think the issue probably arises from what you have said above that I should not be using the cone sample PDF as the NEE PDF? $\endgroup$ Commented Sep 30, 2024 at 15:51
  • $\begingroup$ After some experimentation, angle / PI seems to work well, so I'll just stick with that even though I feel moderately sure it's probably not exactly correct. I'll probably leave the question open for any definitely correct answers. $\endgroup$ Commented Oct 1, 2024 at 16:41

0

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.