SPPM renderer (CPU-only)

[pciccone]

Thank you guibou and Lord CRC. So, if I set the outlier rejection to 0 the issue should go away?

Asbjorn, the wavelengthstratificationpasses seems to be useful to get better initial feedback but not really change anything in the final result. Or maybe I'm misinterpreting the description?

Cheers.

[Lord Crc]

Thank you guibou and Lord CRC. So, if I set the outlier rejection to 0 the issue should go away?

This is not the outlier rejection, this is a much more primitive system. I'm removing it entirely, as outlier rejection is superior and doesn't cause issues like this. Note however that for now, outlier rejection won't be fully compatible with SPPM, so I suggest you disable it for SPPM for now.

Asbjorn, the wavelengthstratificationpasses seems to be useful to get better initial feedback but not really change anything in the final result. Or maybe I'm misinterpreting the description?

You got it entirely right, and that was exactly the point It was simply to improve the colors of the first few passes.

[guibou]

Thank you guibou and Lord CRC. So, if I set the outlier rejection to 0 the issue should go away?

This is not the outlier rejection, this is a much more primitive system. I'm removing it entirely, as outlier rejection is superior and doesn't cause issues like this. Note however that for now, outlier rejection won't be fully compatible with SPPM, so I suggest you disable it for SPPM for now.

Asbjorn, the wavelengthstratificationpasses seems to be useful to get better initial feedback but not really change anything in the final result. Or maybe I'm misinterpreting the description?

You got it entirely right, and that was exactly the point It was simply to improve the colors of the first few passes.

By the way it add a slight biais, but it may not be noticable after many passes.

This feature is discutable because it only improve the result of the first say ten passes. But well, this is nice to have.

[Lord Crc]

This feature is discutable because it only improve the result of the first say ten passes. But well, this is nice to have.

The beauty of sppm is of course that you can get a fairly nice idea of the overall lighting after 8-10 passes, so nice to have some appropriate colors as well no?

[SATtva]

I think i told this already, but you guys are amazing.

[jeanphi]

Hi,

Great to see that much progress on SPPM. Just a few things: why not use StratifiedSample1D or RadicalInverse instead of open coding it, is it that much more efficient? What about adding some jitter? Instead of open coding the contributions queueing, couldn't the eye sampler be adapted to not increase the sample count if it doesn't need to? That would allow some fancier samplers later on.

Jeanphi

[Lord Crc]

why not use StratifiedSample1D or RadicalInverse instead of open coding it, is it that much more efficient? What about adding some jitter?

I found that the first offset really should be 0.5, or some other handpicked constant. It's very sensitive for the first 3-4 passes. I'll try the RadicalInverse thing though.

Instead of open coding the contributions queueing, couldn't the eye sampler be adapted to not increase the sample count if it doesn't need to? That would allow some fancier samplers later on.

Sounds good, I'll make the modifications.

[guibou]

Instead of open coding the contributions queueing, couldn't the eye sampler be adapted to not increase the sample count if it doesn't need to? That would allow some fancier samplers later on.

Honestly I'm totally lost on what the film are really doing.

Currently SPPM needs:

- A normalization per pass for the eye buffer (or per sample per pixel)
- A normalization per photon for the photon buffer (or per AddSample())

Also, as usuall, now that everything works, I have broken SPPM again , Some patchs had been pushed which reduce a bit memory usage, but perhaps at the code of some speed (it replace a cached Point by a pointer indirection read).

Also, I have started a new branch, ppm_proba, using the "PPM: a probabilistic approach" to radius reduction. I seams interesting because :

- it reduce cache trashing because of the removal of atomics
- because photon statistics disapears, HitPoint size is now 64 byte, which fits perfectly in the CPU cache (But without any speed improvement, I'm surprised...)
- More generally, I'd like to test this approach for a while. I discussed a lot at siggraph asia and EGSR with people involved in sppm research and everybody seams to think the Knaus approach is a better way of handling PPM. I'll try to merge both branch regular (or perhaps make this a runtime parameter). If some people want to test it, please.

Please also note that with the fixes pushed yesterday we make a big step forward in SPPM. Every result you may have seen previously may be totally different (I'm thinking about the firefly issue, or the ringing issue in the MP3 scene, or AMCMC not working well).

[Chawl]

I have built changeset 3419 ppm_proba branch (on VS2008) and Peff is always "0". Is that normal?

Latest SPPM improvements are really thrilling btw Tx.

[guibou]

I have built changeset 3419 ppm_proba branch (on VS2008) and Peff is always "0". Is that normal?

Yes, I need to remove that field. Because photon statistics disappear, There is no way to fill the Peff field.

Please, about changset number, could you use the fully qualified number (the hash after 3419). the number 3419 exists for a given repository at a given time, but this number will change next time someone push commits to the repository.