Volumetric SSS

Been experimenting replicating SSS using Volumetric scatter/absorption. Much slower than the inbuilt SSS nodes, but much more accurate IMO.

I have uploaded the material to blendswap if you are interested in having a play.


Same material settings, just lit from different angles.


1 Like

Nice tests - though Isn’t this technique kind of what the new (in 2.79 Master) Random Walk SSS does only less optimized?

Yep kinda - although random walk is still an approximation and suffers from it’s own little niggles.

This nodegroup includes more options and tunability. Random walk also doesn’t contain scattering anisotropy, which this node group does.

Plus - I don’t think you can add true volumetric effects like this using SSS.

1 Like

Brecht actually has a patch that adds the anisotropy, but he is unsure whether it’s worth the additional complexity as his initial tests showed similar results to changing the radius (and it’s not like SSS is the shader you want for things like light-shafts and other volumetric effects highly dependent on such a setting).

i like these testrenders.anisotropy makes a huge difference as render result.

i would like to see reference materials, with its scatteringcoefficent value used.
i guess your renderings are eyeballed random values?

it would be nice, if we would have a input value, in the shader for the k (for absorption) and s (for scattercoefficent) maybe with uncheck option if not used.this would be give a fast possibility, to render real scatter and absorption results.because in many material papers, often you can found these values.and the math is quite easy.

It’s not as straight forward as that though. Volumetric effects in Cycles depend not only on the material values - but also on the render settings (particularly the number of volumetric bounces and the volumetric step size). Render settings can also have a huge effect on performance.

The following three renders have identical material settings - but a different number of volumetric bounces.

This image has 2 volumetric bounces (the “limited global illumination” default). It took 42 seconds to render.

This image has 128 volumetric bounces (the “full global illumination” default). It took 3 minutes 12 seconds to render.

This final one has the “full global illumination” default settings - except the number of volumetric bounces has been reduced to 5. It took 1 minute 7 seconds to render.

yes sure you are right ,about differnent render settings.i have set ,for the teeth renderings, the volume setting to 6-7 so the light is bounced enough ,and all more increases the rendertime unnessesary.if you go lower i found the light darkens mor and more,means not enough bounces.
edit.and transparent to 12 iirc to avoid black spots.

Yep - I have found 5 is the absolute minimum. Somewhere between 5-10 is probably a good compromise between speed and accuracy.

here a video how to calculate light intensity from k,and calculate the distance from intensity and k.

this has helped me ,to make sample cubes ,with a given thickeness (distance), to render with backlight (with emission plane under or behind the sample,with str at 1)and measuring the intensity with a colorpicker,to set the scatter density from the sample right.

a tip from me.i would use 0.5 intensity in medium and set the thickness for the sample.especaly if you render with filmic,because the log curve from the filmic at the high values (seems to start at 80-90%).

some formulas


I=I0e **-(kd)
or simple if I0 is 1
I=e **-(k*d)


A=2-log (%T)

I0=lightintensity from the lightsource
I=lightintensity in medium
k=extintion coefficient
d=distance in medium

blood with principled volume shader,first render with anisotropy 0.95 and second render with reduced scattering coefficent (1-g).
reduced scttering coefficent method found in this paper.




best from both worlds,blood volume shader + random walk sss mixed together

here the blood volume shader is over 80% and 20% random walk mixed,skin like fresh born rats

1 Like

I’ve noticed that the translucent shader is not affected by the higher density of the volume shader,

with the transparent shader, as expected, the transmission, at higher volume

density, muted.I’m not sure if that’s what you want, or if it’s pbr correct

.maybe a bug the translucent shader is not involved? .I mean if you set

Density to 1000 or whatever exaggeratedly high, how should there be a material yet

remain translucent? the density has no effect on the translucent shader.

edit here testpics,first with translucent 0 and volume density at 0.4
and second render with translucent at 1 and volume at 1000
with the principled volume shader backlight tested.

edit…i found the reason for this.the emission plane was overlaping with the cube.i moved it a bit away from the cube and it renders as it should.

good experiment , I noticed that volume shader perform the new add feature of sss ( random walk )

Does this mean Brecht has no intention of adding anisotropic effects to random walk? From what I’ve seen, forward and back scattering makes a massive difference; it’s not the same to just changing the radius. They produce different results, especially based on the type of environment lighting.

Deliberately neglecting anisotropic effects for SSS is like saying, “Well, I don’t want renders to look too realistic. Better to exclude it.” It truly adds a layer of detail necessary for photorealism.

Anyway, I’m going to experiment with moony’s nodegroup.

There is a tradeoff between accuracy and speed.

There will come a point where adding various aspects to the SSS shader will make it so slow - you might as well brute force it like I have done here.

I think the SSS shader should be considered a tool in the box.

Need only an acceptable level of accuracy - use SSS shader. Need a very high level of realism including anisotropic effects, use full volumetric scattering via a node group like mine (but accept the render will be slower).

Thanks for sharing your material, it’s faster than the Random Walk SSS for me (when keeping reasonable amount of volumetric bounces), and also way more realistic. Tweaking the color of the random walk with the radius value isn’t user-friendly at all either.

Great job :slight_smile: