SPPM renderer (CPU-only)

[guibou]

I have bisected the darkening effect, it comes from the revision where I replaced the custom accumulator of sppm by the film interface. So perhaps I have missed something.

The old interface was storing an XYZColor inside the hitpoint (called accum). Each time a photon fell on an hitpoint, its flux was added to accum. This may happen many time per photon (if there is many hitpoint in the neighboorhood and if the photon do many bounces). This value is then copied to the film buffer by Film::SetSample normalized by dividing by totalNumberOfPhoton.

Now, in the new interface, each time a photon falls on an hitpoint, its flux is added to the sample by AddContribution. At the end of the photon path, we call sample.AddSample()

So in theory, the pixel inside the film contains the sum of every photon contribution on the hitpoint associated to the pixel (in fact, the pixel filter is taken into account here)

So the film must, for each pixel, return the value stored / the number of photon shooted. Which is equal to the number of time AddSample method had been called, which is stored in Buffer::_numberOfSamples. It is what I had implemented in the PerScreenNormalizedBufferScaled.

Where did I miss something ?

[Dade]

Where did I miss something ?

The "darkening" could be an hint of where the problem is: it must be something related to the increased number of passes. If I remember correctly, the film is cleared at each pass so there shouldn't be any relation with passes. The problem shouldn't be inside the Film class or in the class usage.

[guibou]

If I remember correctly, the film is cleared at each pass so there shouldn't be any relation with passes. The problem shouldn't be inside the Film class or in the class usage.

It was the case with your first implementation, but since sppm use the Sampler/Sample/Contribution pipeline. Each shot photon trigger a GenNextSample() and AddSample() and each hitpoint hits by a photon generate an AddContribution. I think I missed something in the usage of this API, but what ?

[pciccone]

Hello.

Here is a quick comparison between Bidir and SPPM:

The SPPM version is better, IMHO, in all details except for the BG, which is really coarse. The DOF doesn't seem to work a nicely as with Bidir. My SPPM parameters:

- Eye and Photon depth: 32
- Photons: 2,000,000
- Start radius: 1.5
- Alpha: 0.7
- Start k: 30

I like the shadows of SPPM and the hair looks a lot better. The lighting is using just two meshlights. The face was pretty much this good after 1.5 hr, I let the render cook overnight to see if the BG would improve, which it didn't. Any suggestion is very welcome.

Cheers.

[Vutshi]

Hi pciccone,

To me the last image doesn't look like it has been rendered by an unbiased renderer.

[jeanphi]

Hi,

I have to agree with Vutchi, I find the bidir render much better. Look at the nose for example or the absence of shadows over the eyes.

Jeanphi

[J the Ninja]

Why would that happen with sppm? Too high of a starting radius?

[pciccone]

I didn't explain myself. Yes, the Bidir is better, and that's why I posted here. I'd like to get the quality of the Bidir with SPPM.

[Lord Crc]

I've added a new parameter "wavelengthstratificationpasses" (lengthy but not completely cryptic). Set to a power-of-two number N it will non-randomly stratify the wavelength samples for the first N-1 passes. This can improve the initial color balance, preventing the "weird color effect". From the N-th pass it continues using the regular method.

It works in a kind of hierarchical subdivision. It starts with one bin, and takes the midpoint (0.5). It then subdivides the bin into two new ones and takes those midpoints, etc. It uses the midpoints in reverse order, as I found it to be slightly better. Thus if N is 8, the offsets used for the wavelength sampling are 0.5, 0.75, 0.25, 0.875, 0.625, 0.375, 0.125.

This will introduce a slight initial bias, so if you want to disable it just set it to 0. The default value is 8.

[guibou]

We got it !!!

By the way, Lorc Crc got it. thanks to him ! After many day of hunt with him, he just found the solution.

It comes from the old firefly rejection system in luxrender. If the contribution of a sample is above a specific threshold, it is clamped. It is not an issue with others renderers, but SPPM increase variance through passes, so leads to really big contribution, which are all clamped.

Btw, this will also change the fact that sppm appears to stop converging after a few time, because of the same issue.

Lord Crc does not stops here, he also found a memory issue and a fixed a long standing normalisation issue of sppm (this guy is crazy and skilled!). Everything will be in hg in a few.