SPPM renderer (CPU-only)

[jeanphi]

Hi,

alpha must be less than 1 otherwise the search radius won't be reduced and the precision won't increase, if the value is too small the radius will shrink so fast that soon the probability of a photon hitting it will be negligible.

Jeanphi

[Dade]

Dade, is there a way other than a small startradius or small alpha to get the tight caustics?

The initial start radius represent the initial bias of the rendering. Larger it is => more initial bias there is.

Alpha is the amount of reduction of the radius for each pass (i.e. 0.7 => 30% reduction of the radius).

Here are my findings when dealing with SPPM, can you confirm/deny these Dade.

1. To get the picture to clean up faster you need a larger start radius with a larger alpha. The defaults (startradius 2 and alpha 0.7) work pretty good for this. However it produces muted caustics.
2. For tighter caustics you need a small photon search radius (startradius of 0.1 and alpha 1.0), or a larger startradius and small alpha (startradius 2.0/1.0 and alpha 0.05/0.1).
3. If you use the small startradius of 0.1 with an alpha of 1.0 there will be a lot of noise and convergence is very very slow. This is because the photon search radius is so small that the photons don't overlap and won't flll in very fast.

alpha = 1.0 means there is no convergence at all.

3. If you use a larger startradius of 1.0 and a smaller alpha of 0.1 it will converge slightly faster because there is more photon overlap but due to the small alpha it will become noisy and still take a long time to converge.
4. Larger startradius increases the photon pass time, but improves convergence at the cost of caustics. Conversely, a smaller startradius decreases photon pass time, but improves caustics at the cost of convergence time.
5. The alpha setting controls the eventual size of the photon search radius. Larger settings have better convergence rates, again, at the cost of caustics.
6. When dealing with a small startradius or an eventually small search radius due to a small alpha setting, more photons per pass is more efficient/better convergence rate. At the cost of the speed of the photon pass.
7. The speed of the eye pass is controlled by the size of the image.

It is all a trade-off between blurred image with a lot of initial bias and sharper image but with high frequency noise.

However, doesn't matter from where you start, the end result will be always the same on long term (it is unbiased).

Other questions.
Does the search radius ever get reset to the startradius setting? If not it seems to me that this would help convergence.

No, the radius of each hit points (receiving photons during the pass) is multiplied by alpha (i.e. reduced) at each pass.

Is there any advantage to using hybridhashgrid over the hashgrid?

hybridhashgrid is a lot faster than hashgrid (nearly 2 times).

Can you confirm that the kdtree lookupaccel option is currently non functional?

Mmm, it was supposed to work but I see it doesn't.

[binarycortex]

I did another test before your response. This was a startradius of 2 and an alpha of 0.05 with 10 million photons per pass. This only ran for 1 hour. 1/4 the time as the previous one and is the same or better converged.

Hi,

alpha must be less than 1 otherwise the search radius won't be reduced and the precision won't increase, if the value is too small the radius will shrink so fast that soon the probability of a photon hitting it will be negligible.

Jeanphi

So if I understand what you are saying, the search radius will decrease by the alpha amount (0.7 = 30% reduction) every pass. Which means that given enough time it will produce tight caustics anyway. Is that correct? That would certainly explain all the noise.

[Down Rodeo]

Can I just say that this looks absolutely gorgeous, seeing all the reflections in the sphere from the pool was amazing. No joke. Fantastic work!

[binarycortex]

Ok, another test. This time I tried the defaults (startradius 2.0, alpha 0.7) and I lowered the photon count to 250000 per pass hoping that it would not only converge the whole picture but reduce the search radius enough so that a significant amount of time would be spent trying to find the tiny tight caustics. This did not work.

EDIT: It worked a little, just not as much as I wanted, given the amount of convergence in the prior render which was only 1 hour.

After over 7 hours and 4000+ passes the caustics are still muted.

07:12:18 - 2T: 4.056 kpass 39.10 kP/s
Writing Tonemapped PNG image to file default.png

I am guessing that despite the lower photon count, which should allow more passes at a tighter search radius, could not over come the long time spent at larger search radii. Time to lower the alpha I think. But if I lower the alpha, it will shrink the search radius faster. Which means I will need more photons per pass to compensate.

[J the Ninja]

For those who also want to play with it, but don't use Blender 2.49, here are the switches for the surface integrator (I had to fish them out of the lb249 file, couldn't find a full list posted anywhere)

Code: Select all

integer maxeyedepth
integer maxphotondepth
float startradius
float alpha
integer photonperpass
string lookupaccel
bool includeenvironment


Remember to change both "renderer" and "surface integrator" values to "sppm". The string for hybrid hash grid is simply "hybridhashgrid" Disregard the bit about samplers and pixel filters in the first post, that's not true anymore.

Oh, and it seems the number of pixel samples used for Low Discrepancy affects the length of both the eye and photon passes? So only photonperpass can control how long the two halves (eye/photon) of the pass are relative to each other?

[guibou]

There is something I don't understand :

http://src.luxrender.net/lux/file/1e957 ... el.cpp#l36

BSDF_ALL | BSDF_DIFFUSE is the same as BSDF_ALL, so what is the need for BSDF_DIFFUSE ?

Does BSDF_REFLECTION | BSDF_TRANSMISSON | BSDF_DIFFUSE is more correct ?

Did i miss something ?:

This come from that changset dcaca6612b.

It appears (because of this explicit changset) that we want to ignore glossy component when a photon falls on a hitpoint radius, but I'm wondering when this component is taken into account ?

so :

a) Am I right thinking that BSDF_ALL and BSDF_ALL | BSDF_DIFFUSE is the same ?
b) Is the correct behavior BSDF_ALL or BSDF_REFLECTION | BSDF_TRANSMISSON | BSDF_DIFFUSE ?

Have a nice day.

[J the Ninja]

Hey, cool, I actually got it to work! (Ok, the surface integrator panel is a little messed up, but it exports perfectly fine)

(so how do I make a patch when there is more than one file changed?)

EDIT: cooler pic

[guibou]

(so how do I make a patch when there is more than one file changed?)

Code: Select all

hg diff


or :

Code: Select all

hg qinit
hg qnew -f "mypatch.diff"
hgqrefresh -e
<<< my commit message


[J the Ninja]

Oh, that does work for multiple files? So it does! Ok, it's attached. Another little bit got in there that I forgot I changed, it fixes the type of "minkovsky exp" that was fixed in the core for 0.8. I left it in, since I figured it was useful. Also, if anyone knows what I did wrong with the surface integrator panel so those params show up twice (but export once) please tell me.

EDIT: to be clear, this patch will add sppm support to luxblend25

EDIT 2: Forgot to pull first, use the newly attatched patch instead.