SPPM renderer (CPU-only)

[Dade]

some really hard lightpaths captured there!

I know you noticed the caustics on the wall reflected on the mirror

[binarycortex]

some really hard lightpaths captured there!

I know you noticed the caustics on the wall reflected on the mirror

Yea, they look great. But I noticed a problem. It is not using the data from the tabulated data file. The water should be water colored. See here: viewtopic.php?f=14&t=5092&hilit=famous+pool+scene#p53143

EDIT: Updated render attached.

[Lord Crc]

Yea, they look great. But I noticed a problem. It is not using the data from the tabulated data file. The water should be water colored.

I'm guessing this change is related

Code: Select all

SPPM: removed Volume related code (can't work, SPPM requires specific support) and the use of normal sampler for eye pass (it was a random sampler anyway). Reduced the memory required to store hit points.

[jeanphi]

Hi,

Since only scattering will cause issues with SPPM, not absorption, wouldn't it be better to reactivate volume support and suggest the use of the "emission" volume integrator (it has no scattering)?
Also it'd be interesting to see renders of the "official" pool scene from the repository, it has more complex paths than this one and it should make SPPM really shine.

Jeanphi

[Dade]

Since only scattering will cause issues with SPPM, not absorption, wouldn't it be better to reactivate volume support and suggest the use of the "emission" volume integrator (it has no scattering)?
Also it'd be interesting to see renders of the "official" pool scene from the repository, it has more complex paths than this one and it should make SPPM really shine.

Yes, I forgot that the volume integrator can be used for something else than scattering. I will restore the code but as you know, scattering support will require a very specific code path (i.e. store an hit point where the scattering event is, etc.).

[Dade]

Ok, restored the code for volume rendering.

This is a 90 secs rendering with SPPM:

and this a 90 secs rendering with MTL+BiDir:

First of all, the SPPM low frequency noise looks soooo much better than BiDir path tracing high frequency noise. Second, in my opinion, the SPPM water looks a lot better too.

P.S. there must be a bug in exphotonmap integrator, it traces photons with Sample having uninitialized values for the VolumeIntegrator.

[jeanphi]

Yes, I forgot that the volume integrator can be used for something else than scattering. I will restore the code but as you know, scattering support will require a very specific code path (i.e. store an hit point where the scattering event is, etc.).

Storing a hit point at the scattering event is really easy since the scattering event returns an intersection. The hard part will be to have light rays passing nearby a scattering hit point detect that condition and interact with the hit point. I fear that if we wait for a light scattering event to be nearby a scattering hit point, it might take ages to converge.

Jeanphi

[jeanphi]

First of all, the SPPM low frequency noise looks soooo much better than BiDir path tracing high frequency noise. Second, in my opinion, the SPPM water looks a lot better too.

Great! That's what I anticipated, however you can also notice that the sun reflection on the water surface seen through the copper sphere has a harder time converging. That scene is really great to exercise all kinds of light paths.
Also note how clear is the reflection of the sun light either at the bottom of the pool or on the wall even when seen through the copper sphere!

I also wonder if there's an issue involving the use of adjoint BSDF, the light at the bottom of the pool looks way too strong, but maybe it's just that we're not used to seeing it like that.

Jeanphi

[binarycortex]

Jeanphi, I adjusted my scene to match closer to the official one. Here is a 5 minute render.

[binarycortex]

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

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

Render time 4 hours.
10mil photons per pass
startradius 1.0
alpha 0.1
max eye depth 32
max photon depth 32

Other questions.
Does the search radius ever get reset to the startradius setting? If not it seems to me that this would help convergence.
Is there any advantage to using hybridhashgrid over the hashgrid?
Can you confirm that the kdtree lookupaccel option is currently non functional?

Cheers,
Ian