SSLT: A handy and compact SDL feature!

....but does it bring any functionality beyond using media? On initial trials,
I'm thinking media scattering is more versatile (but no good with ambient
lighting with radiosity scenes), and can do quite good milk, wax, moulded
plastics, semi-opaque glass, particulate/impure water, atmosphere, etc.

I couldn't find rationale for SSLT, so can I ask (of the dev team) what it was?
(speed, accuracy, simplicity?)

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
> SSLT: A handy and compact SDL feature!

Awww.  It's in the beta?  I picked a fine time to run 'rm -rf /media/WINDOWS'.
I guess I'll have to be patient.  Oh well.  No regrets.

If I had to take a guess at the answer to your question, I'd say that
restricting the use to surface illumination from subsurface scattering means
you can make quite a few optimizations.  Here's an example, but I'm not sure
how much of this is included in the beta:

http://graphics.ucsd.edu/~henrik/papers/fast_bssrdf/fast_bssrdf.pdf

I think photon mapping and such was also mentioned, but again, I'm not sure
exactly what is implemented, and I think we all know whom to ask for a better
explanation...

 - Ricky

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
> SSLT: A handy and compact SDL feature!
>
> ....but does it bring any functionality beyond using media? On initial trials,
> I'm thinking media scattering is more versatile (but no good with ambient
> lighting with radiosity scenes), and can do quite good milk, wax, moulded
> plastics, semi-opaque glass, particulate/impure water, atmosphere, etc.
>
> I couldn't find rationale for SSLT, so can I ask (of the dev team) what it was?
> (speed, accuracy, simplicity?)

All of these, basically.

To begin with, media was designed with low to moderately scattering / absorbing
/ emitting substance in mind; the algorithm is a fair and efficient
approximation of reality only under the assumption that scattering happens so
infrequently that double (or triple or multiple) scattering can be neglected.

The SSLT approach used by POV is designed for just the opposite, with highly
scattering substances in mind; the algorithm is a fair approximation of reality
only under the assumption that scattering happens so frequently that unscattered
light can be neglected, and the scattering function can be modeled as isotropic.

So what can SSLT do that media cannot?

Try the "subsurface.pov" sample scene. Look at the shadow cast onto the
checkered plane by the candle and chrome sphere: Do you see the light
"bleeding" into the shadow cast on the bright slab?

This is not area lights. This is not light filtering through the candle. This is
light transported below the slab's surface - genuine Subsurface Light Transport.

*This* is what SSLT can do that media cannot model.


A few other factors that might be worth mentioning:


Speed:

I never tried modelling a pint of milk using media; however, I fancy that it
takes an awful lot longer to render than the same done with SSLT.

Morover, the SSLT implementation in POV is just at the very beginning; there's a
whole lot of opportunities for optimization waiting to be exploited. Right now,
no caching is done for SSLT whatsoever.


Accuracy:

As mentioned, there are aspects of SSLT that media just can't capture. I also
expect that even those aspects that can be approximated with media are still
somewhat inaccurate.

As of now, SSLT's accuracy still suffers from RNG patterns, but these will
certainly be eliminated in future versions.


Simplicity:

Setting up media for subsurface scattering approximation is quite a hassle: It
doesn't work with the physical material coefficients, and tweaking is
non-trivial.

As of now, tweaking SSLT materials is just as non-trivial, or maybe even worse;
however, it *can* operate on physical material coefficients (like those
presented in the Jensen et al paper); plus, mathematically sound work has been
done (again by Jensen et al - though this time some other al - in a follow-up)
to re-parameterize the algorithm in a different, fairly intuitive manner (I
recently posted a macro that implements this approach).


Flexibility:

You mentioned radiosity. As a matter of fact, there is a clear path of how to
make the SSLT algorithm radiosity-aware, and it has been high on the agenda
even before I got my fingers dirty with the code. Once it's accomplished, this
will be another "can't do with media".

Similarly, making the algorithm photon-aware should be not a too big deal
either.


So to sum it all up, I guess these are reason enough to add SSLT.

Post a reply to this message

"triple_r" <nomail@nomail> wrote:
> Awww.  It's in the beta?  I picked a fine time to run 'rm -rf /media/WINDOWS'.
> I guess I'll have to be patient.  Oh well.  No regrets.

It's in the beta, but it's still alpha - very, very alpha ;)

> If I had to take a guess at the answer to your question, I'd say that
> restricting the use to surface illumination from subsurface scattering means
> you can make quite a few optimizations.  Here's an example, but I'm not sure
> how much of this is included in the beta:
>
> http://graphics.ucsd.edu/~henrik/papers/fast_bssrdf/fast_bssrdf.pdf

Exactly those. Can't be implemented 1:1 in POV due to the different basic
approach (relies on a mesh to pick sample locations), but it shows a general
direction to go regarding optimization.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "MessyBlob" <nomail@nomail> wrote:
> > I couldn't find rationale for SSLT, so can I ask (of the dev team) what
> > it was? (speed, accuracy, simplicity?)
>
> All of these, basically.
> [...] the algorithm is a fair and efficient approximation of reality
> only under the assumption that scattering happens so infrequently
> that double (or triple or multiple) scattering can be neglected.
> Try the "subsurface.pov" sample scene. [...]

Yes, some of those subtleties had escaped me at first. I guess you've just
written a part of the new manual in this thread, so now I don't feel quite so
guilty asking the questions. :o)

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

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.

Standards-based parameters are good, in that parameters are not arbitrary, so
people are less likely to be adversely surprised when the algorithm improves:
given that you're already most of the way there, any change would not be very
significant.

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.

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

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.

All round, I think a good decision to include it, and a brave decision to try
it! It's unfortunate that you'll perhaps need to justify the decision (and I
hope this thread has helped). I'm sure many enthusiasts will love to play with
this 'new toy' to produce demo scenes that have an extra edge to their reality:
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.

Post a reply to this message

"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

clipka wrote:
> So what can SSLT do that media cannot?
> 
> Try the "subsurface.pov" sample scene. Look at the shadow cast onto the
> checkered plane by the candle and chrome sphere: Do you see the light
> "bleeding" into the shadow cast on the bright slab?
> 
> This is not area lights. This is not light filtering through the candle.
> This is light transported below the slab's surface - genuine Subsurface
> Light Transport.
> 
> *This* is what SSLT can do that media cannot model.
> 
> 
> A few other factors that might be worth mentioning:
> 
> 
> [...]
> 
> So to sum it all up, I guess these are reason enough to add SSLT.

I suggest putting all this in the wiki!

Post a reply to this message