## SPPM renderer (CPU-only)

Discussion related to the implementation of new features & algorithms to the Core Engine.

Moderators: jromang, tomb, zcott, coordinators

### Re: SPPM renderer (CPU-only)

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
jeanphi

Posts: 6624
Joined: Mon Jan 14, 2008 7:21 am

### Re: SPPM renderer (CPU-only)

binarycortex wrote: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).

binarycortex wrote: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.

binarycortex wrote: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).

binarycortex wrote: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.

binarycortex wrote:Is there any advantage to using hybridhashgrid over the hashgrid?

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

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

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

Posts: 4854
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

### Re: SPPM renderer (CPU-only)

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.

jeanphi wrote: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.
Competition Coordinator.
Current Competition: Math is Beautiful / Abstract Wallpaper

Member of the first official jeanphi-fan club

binarycortex

Posts: 1509
Joined: Fri Feb 22, 2008 10:44 pm

### Re: SPPM renderer (CPU-only)

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!
Down Rodeo

Posts: 145
Joined: Sun Nov 11, 2007 3:24 pm
Location: Scotland

### Re: SPPM renderer (CPU-only)

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.
Competition Coordinator.
Current Competition: Math is Beautiful / Abstract Wallpaper

Member of the first official jeanphi-fan club

binarycortex

Posts: 1509
Joined: Fri Feb 22, 2008 10:44 pm

### Re: SPPM renderer (CPU-only)

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 maxeyedepthinteger maxphotondepthfloat startradiusfloat alphainteger photonperpassstring lookupaccelbool 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?
-Jason

J the Ninja

Posts: 2250
Joined: Wed May 19, 2010 9:54 pm
Location: Portland, USA

### Re: SPPM renderer (CPU-only)

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.
guibou

Posts: 271
Joined: Fri Dec 04, 2009 10:14 am

### Re: SPPM renderer (CPU-only)

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
-Jason

J the Ninja

Posts: 2250
Joined: Wed May 19, 2010 9:54 pm
Location: Portland, USA

### Re: SPPM renderer (CPU-only)

J the Ninja wrote:(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 qinithg qnew -f "mypatch.diff"hgqrefresh -e<<< my commit message
guibou

Posts: 271
Joined: Fri Dec 04, 2009 10:14 am

### Re: SPPM renderer (CPU-only)

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.
Attachments
sppmlb25.patch
Last edited by J the Ninja on Tue Mar 08, 2011 12:13 pm, edited 2 times in total.
-Jason

J the Ninja

Posts: 2250
Joined: Wed May 19, 2010 9:54 pm
Location: Portland, USA

PreviousNext