If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Arnold skin shader ported to Cycles

NOTE: THIS SHADER IS NOW OBSOLETE. IT HAS BEEN REPLACED BY THE FREE SHADER IN THIS THREAD. And if you want to support the work that's gone into this port and its improvements over the past year, consider checking out my premium skin shaders available in that same thread! Thanks!

My project for the day has been porting the Arnold skin shader to Cycles now that we have SSS. I've made good progress, but there are still speed up options that I need to figure out how to properly implement. Mostly some math relating to light paths that's holding me up, but I should be able to work through it soon.

UPDATE: Version 2 (link below) - Adjusted some weighting after Brecht fixed difference between prog/non-prog rendering. Reflections are now clamped at 1 provided that you don't enter a weight higher than that. Should help with noise a bit as well.

Secondary Reflection settings are the same as primary. It's recommended that you use primary for tighter reflections and secondary for broader reflections.
Global SSS Radius Multiplier:

Overall scales: 0.1, .5, 1, 1.5, 2.0

Allows you to control the global scale of your SSS components. Use to change the overall depth of your SSS.
To Do:

Options to only sample only the SSS material in GI and Glossy rays. Should save a good amount of time and help clear up noise without changing the look any appreciable amount.

Bugs:

Not sure if it's my material or SSS in general, but I get very different results between progressive and non-progressive rendering. I've been using non-prog for all of my tests.

Special thanks to Lukas Tonne for helping me with figuring out how to clamp SSS/Diffuse contributions. Special thanks to Thomas Dinges for helping me get my build environments up and running to actually get a copy of Blender working with SSS!

Long time 3D artist and member of the official Cycles Artists Modulehttps://www.youtube.com/user/m9105826 - Training, other stuff. Like and subscribe for more!
Follow me on Twitter: @mattheimlich or on my blog

Comparing to Arnold, Non-Prog would appear to be the "correct" setting.

Long time 3D artist and member of the official Cycles Artists Modulehttps://www.youtube.com/user/m9105826 - Training, other stuff. Like and subscribe for more!
Follow me on Twitter: @mattheimlich or on my blog

Doesn't run on GPU yet. Brecht is working on it per the comment in the commit logs.

Long time 3D artist and member of the official Cycles Artists Modulehttps://www.youtube.com/user/m9105826 - Training, other stuff. Like and subscribe for more!
Follow me on Twitter: @mattheimlich or on my blog

Long time 3D artist and member of the official Cycles Artists Modulehttps://www.youtube.com/user/m9105826 - Training, other stuff. Like and subscribe for more!
Follow me on Twitter: @mattheimlich or on my blog

About the non-prog/prog integrator differencies, as you said there is a really big difference. But I am not sure the non progressive is looking better. Isn't the SSS way too deep in the non progressive (i am talking about the big file with the scanned face)? On the other hand the progressive with the default file settings looks too sharp, but increasing the radius a bit in my opinion give the best result (and by far also the fastest render time).

why is there a difference between progressive and non-progressive to begin with?
shouldn't the final images be identical? that's the beauty of unbiased renderers right?
i'm glad cycles offers us a way to introduce bias to cut rendertimes but i wouldn't expect
that each integrator produce a completly different image. or is this something solely sss-specific?
if yes, what integrator should we use to get the most correct result?
i get that this sss implementation is not the most physical correct there is – but it is fast – and i'm loving
this but the idea of twisting the knobs till il looks right – then changing the integrator and do all over
again is not something i'm really fond of

why is there a difference between progressive and non-progressive to begin with?
shouldn't the final images be identical? that's the beauty of unbiased renderers right?
i'm glad cycles offers us a way to introduce bias to cut rendertimes but i wouldn't expect
that each integrator produce a completly different image. or is this something solely sss-specific?
if yes, what integrator should we use to get the most correct result?
i get that this sss implementation is not the most physical correct there is – but it is fast – and i'm loving
this but the idea of twisting the knobs till il looks right – then changing the integrator and do all over
again is not something i'm really fond of

I think this is due to the fact that SSS was just added yesterday and still has some bugs...