"MessyBlob" <nomail@nomail> wrote:
> I like the effect: I can 'look into' the surface, and 'see the illuminated
> volume', and where the light comes from. In fact, the RNG patterns are helping
> me to see which effects are attributable to SSLT. The patterns look like a
> consequence of choosing sampling points, intervals and directions; I'm only
> guessing there, but it seems that when sufficient randomness is implemented,
> there can be a sliding scale of 'quick-and-dirty' to 'smooth-and-accurate'.

You're guessing perfectly right (in fact it's all about picking sampling
directions - to in turn compute sampling points - for the diffusion
approximation, and picking sampling "depths" for the - less prominent -
single-scattering term).

> I'm seeing some (RNG) SMP blocking artefacts on the effect, most noticeable
> around the specular highlight on the candle, and near the horizon line on the
> (reflected) sphere when looking into the floor. I'm sure shared cacheing would
> help with this. Would memory be a problem? I imagine SSLT cacheing would need
> more memory than radiosity for applicable surfaces - process limits are already
> a problem for most (W32) users on simple radiosity scenes.

I think the strong noise near the horizon line on the reflected sphere are in
fact aliasing artifacts from the checkered pattern; I'm not perfectly sure
though.

With SSLT, there are two things worth caching: Incoming light, and outgoing
light.

Caching the incoming light would require no more effort than radiosity as long
as the object is uniformly lit; however, sharp shadows would demand a good deal
more effort. Maybe an adaptive approach could be implemented to keep the effort
at the same order of magnitude as for radiosity.

Caching the outgoing light would probably be easier to cache, as it is
inherently "blurry" (plus, it would reduce the workload even further). At sharp
shadows, the effort will still be higher than for radiosity (especially with
low-translucency materials), but not as high as for incoming light.

For "memory-poor" applications, maybe it would be worthwile designing a
"passthrough" mode in which the cache is turned off completely, or samples are
only stored if they are estimated to be re-usable over a significant distance.


> So I have a question on the back of this. I could answer it myself by testing,
> but I expect other folk would like to know the answer too: Is this presently
> calculated against light sources, or from the light calculated at the surface?
> I'm asking because the former wouldn't work with radiosity scenes (having no
> light sources), and the latter would.

IIUC you're basically asking whether the SSLT implementation works with
radiosity, or is limited to classic light sources instead.

As of now, only light sources (more particularly: point light sources) are
supported. However, radiosity support is on the roadmap, so in future versions
it will be possible to use SSLT even in radiosity-only scenes.

> Caustics/photons would look especially good and be efficient, provided the
> algorithm is adaptive. Would it the light have a 'momentum vector' into the
> subsurface, to give a volumetric diffusion, e.g. for a laser-thin shaft of
> light would the sub-surface continue to show the shaft to some extent, or would
> it just be a surface glow observed in the locality of the sub-surface? (I expect
> the latter, given the isotropy assumptions, and that the unscattered light is
> omitted).

I'm not sure about this one yet. While the main component of the SSLT - the
so-called diffusion approximation term - does not account for a "momentum" of
the incident light, the algorithm also has a secondary component - the
so-called single-scattering term - that is highly dependent on the incident
light direction, and should lead to the effect you describe. However, I'm not
sure yet how tho successfully integrate this term with the existing photon
mapping implementation (or radiosity, for that matter), so maybe even the first
stable release will not have it.


> IOR seems to be well-handled (re. exit angle from the sub-surface of the floor),
> but I haven't thought about that in any detail.

Yes, as a matter of fact IOR is a key thing in the formulae.


> All round, I think a good decision to include it, and a brave decision to try
> it!

Well, not really *that* brave; after all, I knew I wasn't implementing a tweaky
kludge but a scientifically sound model. The worst that can happen is either
(a) someone proving that my implementation is buggy (I could imagine that for
the less significant single-scattering term; the diffusion term seems to work
fine and realistically though) or incomplete (it is: the model should account
for a "zero-scattering" term, i.e. translucency, which isn't in there yet), but
not that the whole approach would be bogus; or (b) people complaining that I'm
not working faster on the remaining tasks :P


> It's unfortunate that you'll perhaps need to justify the decision

I don't expect many people to actually challenge the decision. Still I don't
mind either; as you can see, there is ample justification for it.


> cue the skin models, the milk glasses, the acrylic dice, the cloudy glass
> sculpture, the marble chess set and anything else that has ever been carved
> from marble ... They will all help make your case for SSLT in POV-Ray.

Yep - looking forward to those! :)

Post a reply to this message