What is the use of SSS's blue response?

@bagginsbill ok that makes a lot of sense, thank you, and I'm also not claiming to be any kind of chromogeometric genious, but that explanation in itself reveals the answer that should be able to solve the problem, wouldn't you agree? If this dipole cross over and influence deep enough to make the opposing side of the mesh blue, the fact that the mesh actually turns blue shows that the math has done its work... now just reverse that and discover whatever entered into this 'bluemaking'zone and stop the dipoles from doing their damage much like making the opposing geometry part of a different scatter group, with some proximity method or something. If it takes more calculation time, make it an option then. Either way, this blue thing is annoying and mathematically necessary, don't you think?

As I said I don't understand the math and cannot explain how the thing actually works, nor what equation is actually producing the artifact. It's known (by the users) and yet unacknowledged (by the authors) that subsurface scattering using dipole approximations just doesn't work when the pole distance is larger than the diameter of the object itself. When that happens, the negative pole is actually outside the volume. This is easily seen here:
Cycles SSS seemingly incorrect colour for thin surfaces or small objects

Note as we've heard absolutely NOTHING from the new product manager, I cannot tell you if the remaining engineers even have the math skills to tackle this issue on behalf of the Cycles designers who clearly don't.

@bagginsbill ah well we will have to see then. Its not the worst problem in the world as there are ways to fudge it I suppose, but yeah I don't see how this cannot be fixed down the line somewhere. Math is the language of reality, the sloppier the translation, the more abstract our depictions of it will be.
Thanks a tonne for the info in any case!!!

Essentially, subsurface scattering is a volumetric effect. You're trying to calculate the light that has entered an object surface, bounced around for any number of times inside the object, and finally exited the object at a different point. Ideally, you'll need the contribution from all light that hits the object anywhere, as SSS is not a local effect (if could put the sun in my nostril, my toes would glow from the scattered light).
Now, one could calculate that effect in a brute force fusion: just trace lots of random volumetric bounces inside an object and wait for a very long time for the render to finish. That is certainly possible, it will deliver accurate results and can be achieved in SuperFly by using the volumetric nodes with very high density values. Note that the accurate calculation will now make other approximations visible, notably that bump maps or smooth shading are just a hack to replace real geometry. Be prepared to either see facets or to use lots of subdivision.
Since the brute force method is not very practical (and certainly was not 15 years ago), a very clever approximation was introduced: the BSSRDF. It's a function, that given an entry point and an exit point for light, calculates the scattered light that travels between those two points. There are several BSSRDF functions out there, such as the dipole (FireFly's scatter node), sum of gaussians (Subsurface Skin in both Fire and SuperFly, Cycles SSS node), or Burley's Approximation (Cycles SSS node). A limitation that they all inherently have is that they have no knowledge of the geometry of the object  all they have is two points. And they all rely on the assumption of fairly dense materials compared to their size and are approximating a semiinfinite flat object. This is why they fall apart when the scatter radius approaches the object size.
In order to calculate the integral of the BSSRDF over all light reaching the object, one can either do a prepass and gather light over the surface (as done by FireFly) or one can just randomly pick points on the surface on the fly (as done by SuperFly). The latter can be done in unbiased methods, but then you're only getting an unbiased estimate of a function that approximates scattering.
PS: It is a very common misconception that "unbiased" means "correct"  it doesn't. The importance of bias (or the lack of) in light transport is mostly academical and rarely has any practical implications. See http://cs.au.dk/~toshiya/misc.pdf for details.

Regarding the brute force method: Disney has used that on occasion where the diffusion approximation wouldn't cut it, notably snow and ice  see page 10 in this document: http://blog.selfshadow.com/publications/s2015shadingcourse/burley/s2015_pbs_disney_bsdf_notes.pdf
Skin in most productions though is rendered with the same methods available in SuperFly  it implements state of the art methods such as BSSRDF importance sampling*:
https://www.solidangle.com/research/s2013_bssrdf_slides.pdf
and Burley's exponential BSSRDF:
http://graphics.pixar.com/library/ApproxBSSRDF/paper.pdf*The weighted sum BSSRDF for skin in the slides has been in Poser's Subsurface Skin node since the beginning, as the method has been around for a while. See https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch14.html

This is roughly how I'd do brute force skin scattering in SuperFly.


Yay! Stefan is here.
I have noticed that in SF, Burley and the PhysicalSurface don't show blue so easily (or at all), while Cubic and the Custom_Scatter node do it rather severely. Should I be telling people to just stick with Burley and stay away from the others?

I don't see any reason not to use the Burley BSSRDF. For what it's worth, Solid Angle removed all other options from Arnold 5 and the (as they call it) empirical BSSRDF is now the only profile it offers.

@stefan I was experimenting with Burley SSS in PP11 here on Baby Luna. I am impressed, especially since I am no material room pro, but I ran out of time to play.

very interesting to read and check up on @stefan thank you for your time explaining that!