SSS slated for release in 2.67

The purpose of this thread is to draw attention to a new feature slated for release in Blender 2.67, true subsurface scattering (sss). There are many threads discussing how to fake SSS, and some old information about the various methods that could potentially be candidates for a system in Blender.

But because SSS is now a target for the next release, we can now stop talking about this feature strictly in hypotheticals. SSS, I think, now deserves its own, current News thread, to make finding the latest information about it easier.

Here’s some recent information from Brecht about the papers he’s been referencing:

Paper links:

Implementing a skin BSSRDF (or several…)

Bidirectional Lightcuts:

Brecht mentioned SSS as a priority on the cycles roadmap (as noted in the developer meeting notes here):

You can see development targets for 2.67 here:

to make finding the latest information about it easier.

It’ll be available possibly next week and will be in the 2.67 release (release date available on

LOL, seeing that piece of “coder art” in the meeting minutes cheered me up! Thanks Ton and Brecht and everyone, it’s looking good.

Edit: Richard is faster on the trigger… :slight_smile:

what does ton mean by Brecht van Lommel has “first” SSS code working ?

Well, it is the first SSS implementation for cycles. I don’t think it’s unrealistic to except optimizations, or even implementations of other algorithms in the future.

it means first run code I guess before fine tuning…
I’m curious what the render time was for that image since the only really grainy area is inside suzanne…

Yeh thats what I thought,its probably right.I did also think I might have been missing something,since other software have things like simple/fast sss,and physically accurate sss. I thought it might of been away of saying there is going to be another code.

The image shows quite a lot of promise, this is really good news for the prospect of this target making it into trunk for 2.67.

I would also agree with others that there will be a lot of tweaks and/or optimizations made to the code over the next week now that it’s actually in a working state, so it would be understandable if we still have to wait a week or so yet before we can play with it.

The cycles method is a pure raytraced method, so this is the physically accurate one. :slight_smile:

will this lead to another lightpath in the lightpath node? can we tweak underlying colors like a fatty tissue for skin?..I know I am jumping the gun…

It’s possible you might be jumping the gun because we do not yet know what the parameters for the SSS node will be, Brecht also says that this initial shader will not be a dedicated skin shader (though in theory, it will be possible to create more complex effects through the use of more than one SSS node, much like what you can do with all of the other shaders).

Basically Ace has it:

You can see later in the mail conversation link from above:

It appears that he will consider it for 2.68, but said no promises.

The skin shader in Arnold is basically nothing more than a dedicated node group. You can see the setup here

It would be hard to port to the Cycles node system as you have a LOT more access to things in SoftImage/Maya. Also, the Cycles ray switch node works from the opposite direction, which I really think should be changed. Being able to say “this material is visible to camera/diffuse/etc” by plugging it into those rays is much easier than a dozen ray/mix nodes. Also, we don’t have boolean switches in the Cycles node system. But you may be able to come up with something based on that tree. Good luck until dedicated skin is in!

In essence to get skin with this shader you would use 3 SSS shaders of different depths, using different colors, combined with a diffuse shader, and play with the mix values to control the weights of each. Then add two glossy shaders on top, one for tight reflections, one for more glossy reflections. You can find some good starting weights/colors here

Can’t wait to play!

excuse my ignorance,as the sss i’ve played with is in maya,and that was a long time ago and I forgot most of it.

With this new SSS node,to create skin,i’m guessing you have your epidermal subdermal layers etc. plugged into various different SSS nodes and then all combined with mix nodes etc.? I think thats how its usually done.

How would a dedicated skin shader work? what would the difference be?

edit: looks like @m9105826 cleared that up lol.

The difference would mostly be convenience. There is some math that goes on behind the scenes to get the measured values for skin to be accurate, and some ray-type magic can be done to greatly speed up render times without really changing the final output (see the ray switch at the end of the Arnold shader tree). It could be built by hand, but it would be tough with the existing Cycles node options. Also, if a skin shader were hard coded it would save a significant amount of time compared to simply creating a node group. The time differences between my ubershader and a simple diffuse shader are a good example of this. The Arnold shader also has an option to only have the SSS component be visible to secondary rays which can also really cut down on overall noise. Hopefully this makes an appearance as well.

On second examination of the Arnold skin it would appear to be impossible to completely recreate with Cycles nodes until we have switches/booleans. These are used mostly for things like the “Is Visible Only To Secondary Rays” options. I’ll definitely be playing around trying to duplicate the setup to the best of my ability and sharing my group as soon as the SSS shader is available to the public.

I usually just string the result of the output through a ‘color invert’ node, it seems to work well enough for me as the data is basically either 1 or 0.

I think you misunderstood what I’m saying about the node. Look at how the ray switch works in the skin shader tree I posted. Basically instead of 10 ray nodes plugged into mix nodes you use one ray node at the very end of the tree and plug individual shaders into the ray types they will be visible to. It’s much cleaner and more user friendly to only need one node rather than many mix nodes and ray switch nodes.

I don’t think I’m quite getting what you’re saying, because even though I can see the fact that ‘ray switch’ is the Arnold equivalent of the lightpath node (only reversed like you mentioned), what I don’t see is what necessitates using a lot of different copies outside of just one per group along with one on the outside, are you sure your setup is something that can’t be avoided through the use of math nodes to filter out unwanted information?

Real SSS…awesome!

Thanks!!! :smiley:

Question: Is this a surface shader or a volume shader? :slight_smile:
Makes sense to me if it’s a volume shader.