SPPM renderer (CPU-only)

[Rom1]

I remember a fix from guibou few month ago

17d0510aeb9a) SPPM: fix normalisation issue


=== (+2,-2) renderers/sppm/lookupaccel.cpp ===
@@ -42,7 +42,7 @@
// Epanechnikov kernel normalised on a disk
float s = 1.f - d2 / md2;

- return s / (M_PI * md2) * 2.f;
+ return s / (M_PI * md2) * 3.f;
}

I check and this fix have been recoded, this is what I have now

inline float Ekernel(const float d2, float md2) {
// Epanechnikov kernel normalised on a disk
const float s = 1.f - d2 / md2;

return s * 2.f / (M_PI * md2);
}

I don't know if this is the problem, but you probably can try it

- return s * 2.f / (M_PI * md2);
+ return s *3.f / (M_PI * md2);

[guibou]

Hi,

I did the following experiment. There is a huge plane of the white color and a point like light source 1m above. The camera is very far away (I used the orthographic luxrender camera). It is easy to get the analytic solution for this setup. The visible intensity distribution across the plane is given by (1+x^2)^(-3/2), where x is proportional to the distance from the light source. I rendered the image with bidir and sppm methods and used linear tonemapping with gamma=1. As expected bidir gives right answer and sppm doesn't. The difference for sppm is in the power, instead of -3/2 we get -2. Maybe it can give someone a hit where to look for this extra 1/2 power in the code.

Luxrender test result copy.png

Could you do the same experiment with sppm but changing the number of photon per pass please ?

[guibou]

I remember a fix from guibou few month ago

17d0510aeb9a) SPPM: fix normalisation issue

I was right the first time I introduced the normalization factor of the integrand of the E kernel over a disk. But when I checked it after, I made a mistake and push a wrong commit. Lord noticed it and correct it.

So as far as I know, the right factor is PI.R.R / 2. The 2/3 must come from somewhere else.

[Vutshi]

Could you do the same experiment with sppm but changing the number of photon per pass please ?

I could not see any difference for 50K, 500K and 5M photons per pass.

EDIT: Ooops, something is emerging for 5M... Why does it make any difference?

5M is blue.

[binarycortex]

EDIT: Ooops, something is emerging for 5M... Why does it make any difference?

If I had to guess, I would say that it offers better coverage for a given search radius before the next pass when it reduces. Unless I misunderstood when the search radius is reduced.

[Rom1]

I would like to understand something :

When the search radius is reduce ?

after each pass ?

or after a certain quantity of light/photon is obtained on each radius ?

is there some kind of mechanism to "reset" the search radius ?

Let me explain : we launch a lot of photon at each pass, but on my scene I have very specular path with a lot of rebound and only one or two small light source.

I use a mix material with 0.5% matte to have the sppm working on my glass product, and 150 as maxpath value.

At each pass I have a very small amount of chance to have interesting contribution with my specular path. So if I missed them in the first pass, do i have chance to find them on the other pass ? Or is there only a refinement of my existing contribution ?

[Vutshi]

Here is the latest results:

50M is red for ~100 passes and green for ~170 passes, 500K is black, and blue is bidir

50M photons per pass converges very slowly, but it is definitely different from 500K and it doesn't fit to the analytic formula at all.
UPDATE: Apparently, it is not yet converged. In the end it could be the same as 500K

A couple of side questions:
1) From what I have measured I can see that luxrender uses not a proper rounding but takes integer part in order to convert to LDR image. Is it true?
2) It also looks like luxrender doesn't apply any dithering during the conversion. Is it the case?

Finally, I could not obtain a HDR image with the same gamma=1 as LDR. I have checked Output HDR images tonemapped, but I still had to correct gamma of the HDR image to obtain the same result as from LDR tonemapped one. What did I do wrong?

[guibou]

When the search radius is reduce ?

After each pass, proportionnaly to the quantity of light/photon which falls inside the hitpoint during the pass, or if you use the knaus branch, by the same amount after each pass (amount depends on the pass number)

is there some kind of mechanism to "reset" the search radius ?

What is the point ?

I use a mix material with 0.5% matte to have the sppm working on my glass product, and 150 as maxpath value.

Which means that, with current SPPM, you are still loosing 0.995 ** 150 = 50% of the light energy.

At each pass I have a very small amount of chance to have interesting contribution with my specular path. So if I missed them in the first pass, do i have chance to find them on the other pass ? Or is there only a refinement of my existing contribution ?

You will get new contribution at each pass, with less chance of getting them, but they will have more energy (so it is energy conservative). The radius reduction removes

Vutshi:

I'm not sure I fully understand your graph. What are the units of it ?

About the test with a different number of photon per pass, It was because previously this was an influence, so I wanted to be sure it was not a regression introduced by late patches.

As far as i know, the difference of 50M may come from the bias introduced by so much photon per pass. It should disappears with a smaller starting radius.

Is your plane having infinite extends ? (Or is the visible area convolved by the searching radius is still contained inside the plane ?) It may comes from boundary effect of the density estimation.

Ie, if your plane is 1*1 and your search radius is 1.5, you get a small part of your search radius which is outside the plane, so cannot gather light, so leads to less light.

But this is in contradiction with the 50M curve, because a bigger starting radius leads to more boundary effects hence to less ligh, and your 50M curve have more light than the 500K, if I understand correctly the graph

[Vutshi]

I'm not sure I fully understand your graph. What are the units of it ?

It is dimensionless. Horizontal axis is a coordinate of a pixel. Vertical axis is Logarithm of light intensity at the pixel normalized to be 1 at the brightest point.

About the test with a different number of photon per pass, It was because previously this was an influence, so I wanted to be sure it was not a regression introduced by late patches.

As far as i know, the difference of 50M may come from the bias introduced by so much photon per pass. It should disappears with a smaller starting radius.

Unfortunately my machine crashed during the calculation and I can not see weither 50M will converge further. It certainly was not fully converged yet, the latest result is shown in green in the picture.

Is your plane having infinite extends ? (Or is the visible area convolved by the searching radius is still contained inside the plane ?) It may comes from boundary effect of the density estimation.

Ie, if your plane is 1*1 and your search radius is 1.5, you get a small part of your search radius which is outside the plane, so cannot gather light, so leads to less light.

But this is in contradiction with the 50M curve, because a bigger starting radius leads to more boundary effects hence to less ligh, and your 50M curve have more light than the 500K, if I understand correctly the graph

The size of my plane is 1000x1000 and distance from plane to light source is 1. Effectively the plane is infinite. Is it possible to make a really infinite plane in Luxrender?

I think in the end the 50M will be the same as 500K, it is just going very slowly to the limit.

Regarding the theory. The intensity of the light reflected from the plane is proportional to 1/R^2 * H/R, where R is distance from light source to the point of interest on the plane and H is distance from light source to the plane. The H/R part comes from Cos(theta). It follows from the curve fitting that for SPPM we have intensity proportional to 1/R^4. It could mean that there is an extra Cos(theta) somewhere.

[Pilchard123]

So is a wider or narrower curve better in this case? I've seen a few of these graphs around and don't really get what they are showing. How does the x-coordinate of a pixel affect the light intensity there? At least, how does it it affect it in such a way to produce a graph that looks kind of like a normal distribution?