SPPM renderer (CPU-only)

[guibou]

A small bug I have spotted

SPPM does not handle hitpoints on litted surfaces.

This diff may correct it :

Code: Select all

diff -r 3ee98fe779df renderers/sppmrenderer.cpp
--- a/renderers/sppmrenderer.cpp   Tue Feb 22 11:58:41 2011 +0100
+++ b/renderers/sppmrenderer.cpp   Tue Feb 22 13:31:26 2011 +0100
@@ -446,6 +446,9 @@
      alpha *= alpha2;
      alpha /= lightPdf;

+      // Handle zero bounce, ie. when hitpoints are stored on surfaces
+      renderer->hitPoints->AddFlux(photonRay.o, photonRay.d, sw, alpha);
+
      if (!alpha.Black()) {
         // Follow photon path through scene and record intersections
         Intersection photonIsect;


(on top of 3ee98fe779df)

See attached image

[guibou]

Thinking of it, there may be an issue because hitPoints.AddFlux use the BSDF of the surface, which does not mean anything in the context of emitting surface.

Each point sampled on a light source may be added to any in-range hitpoint with a pdf of 1 and with all the flux coming from light->f. But this is not a trivial fix (may certainly add a custom method to HitPoints).

Any ideas ?

[guibou]

Ok, a bit further informations on that,

In slg, there is a special case on hitpoint. When they are stored on light source, they also store the amount of radiance the light emit in the right direction.

Also, when slg is tracing photon path, it stops on surfaces that are flaged as light.

I can see an issue here, sometime it may be interesting (especially with lights groups) to get light interaction (reflection) with surface that are light sources.

A short example with a light bulb. The filament is a light source, so hitpoints on the filament only takes into account the light from the filament, but when the light bulb is off, the filament act as a reflecting surface we want to see in the image.

[jeanphi]

Hi,

Can't you just compute the emitted light when creating a hitpoint on an emitting surface and use it to initialize the hitpoint radiance estimate or store it alongside so that you can later properly add it to the estimate?

Jeanphi

[guibou]

Hi,

Can't you just compute the emitted light when creating a hitpoint on an emitting surface and use it to initialize the hitpoint radiance estimate or store it alongside so that you can later properly add it to the estimate?

Jeanphi

Yes.

Dade, I propose to remove the "type" attribute of HitPoint.

Instead, when setting hitpoints, we increment the accumRadiance with the one at hitpoint position/location and we increment the "constantHitsCount".
When photon are traced, they still increment the accumReflectedFlux and accumPhotoCount.

Radiance estimation is done as usual.

What do you think ?

I have also another question. Currently the renderer only stores hitpoints on diffuse surfaces, but what about glossy ones ? As far as I understood SPPM, hitpoints can be stored on glossy surfaces. Diffuse are far more interesting, but I see no reason to ignore glossy ones which may scatter light.

Perhaps the "end" vertex of the path can be selected by RR ?

[Dade]

A small bug I have spotted

SPPM does not handle hitpoints on litted surfaces.

This should have been fixed by a commit I did today: I forgot to account emitted light on the eye path (it something wasn't possible in SLG). I added an eyeL field (probably going to rename it to eyeLe) to the HitPoint class to keep track emitted light along the eye path. Your fix was a work around to this problem but I don't thing is really correct to deposit flux on the surface emitting the photon.

The problem I'm looking into at the moment is how exactly handle all SWCSpectrum: eye paths, photon paths and SPPM computations are all done on different wavelengths. At the moment, I'm using the trick of using XYZColor but some of SPPM math involve interpolation and doing interpolation in XYZ color space sounds as a bad idea to me.

P.S. I hate the SWCSpectrum class so much as I hated the RayDifferential one

[Dade]

I have also another question. Currently the renderer only stores hitpoints on diffuse surfaces, but what about glossy ones ? As far as I understood SPPM, hitpoints can be stored on glossy surfaces. Diffuse are far more interesting, but I see no reason to ignore glossy ones which may scatter light.

The current behavior is coherent with the one used by exphotonmap integrators. Glossy surfaces are not "ignored",they are just rendered by the "stochastic" part (i.e. eye passes) of SPPM. If we choose to handle them as a diffuse surface, it will lead to wrong results in the case of a nearly specular glossy surface (i.e. something that nearly looks like a mirror).

[jeanphi]

The problem I'm looking into at the moment is how exactly handle all SWCSpectrum: eye paths, photon paths and SPPM computations are all done on different wavelengths. At the moment, I'm using the trick of using XYZColor but some of SPPM math involve interpolation and doing interpolation in XYZ color space sounds as a bad idea to me.

Why don't you just keep the same wavelengths for a given eye pass and only update it when going to the next eye pass? Otherwise you can store the SpectrumWavelengths data and interpolate it like I do for exphotonmap, but thanks to the stochastic part that might not be necessary.

Regarding glossy surface handling, with exphotonmap I introduced a trick : if the probability of the bounce on a glossy surface is above a threshold it is treated like a specular surface, otherwise it is treated like a diffuse surface. Maybe you could try the same trick?

Jeanphi

[Dade]

Why don't you just keep the same wavelengths for a given eye pass and only update it when going to the next eye pass?

I was thinking too something like that, the question is how exactly to do the last step of the process: a SPPM pass is relative to the previous one and this is going to involve SWCSpectrum with different wavelengths anyway. I wonder if doing this step in XYZColor space is introducing artifacts or not

Regarding glossy surface handling, with exphotonmap I introduced a trick : if the probability of the bounce on a glossy surface is above a threshold it is treated like a specular surface, otherwise it is treated like a diffuse surface. Maybe you could try the same trick?

Is the "pdf > 100.f" I have seen somewhere ? I think, from a theoretical point of view, this introduces a bias (i.e. not a big dial in standard photonmapping but it is a bit different with SPPM). We could just have a renderer option to enable/disable this behavior (i.e. a Carbonfluxed option ).

[jeanphi]

I was thinking too something like that, the question is how exactly to do the last step of the process: a SPPM pass is relative to the previous one and this is going to involve SWCSpectrum with different wavelengths anyway. I wonder if doing this step in XYZColor space is introducing artifacts or not

Sure, you update the previous pass, however that's not much different than when you update the hitpoints keeping the same radius and estimate values. You could do the computations in SWCSpectrum space during a given eye pass, compute the resulting XYZ values for the pass and update the radiance estimate in XYZ space (that's what we're doing with standard film).

Jeanphi