SSS slated for release in 2.67

speaking of volume shaders? what happened to them? sometimes I look at the nodes “volume” input and think wouldn’t it be beatifull to be able to connect something here that would do something? too long for a placeholder to be in an output node!

Allelujah cycles SSS!!!

Hail Brecht!!!

I like the way on Arnold also better than in Cycles. I would call it “Ray Filter”.

Just the mix node and the factor on it put in 0 or 1 does this boolean, no? Or this boolean is using OR, XOR, AND, etc (in this case a math node to create the 0 and 1) ???

The ideal setup for me in Blender Internal was:

  • 3 SSS: Epidermis, Dermis, Subdermal
  • 2 Reflection: Broad and Highlights
  • Diffuse
  • Overlay color (this one is essential and it was a composite using “Overlay” photoshop mode on top of the whole thing. But we don’t have “Overlay” node to be able to apply to the end (because shaders can be only Mixed and Added at the moment). So I really wonder how we will do this. Perhaps overlaying before the SSS but that way is not the same. Perhaps a different setup we will come with. Or perhaps we will post the actual problems and convince Brecht. But well, wait first for the shader to come and see what we can do with it and what the limitations are and then we will think what is needed to fix it.

A question tothe other Arnold users. In Arnold, is it possible to control de scale factor of SSS with a texture (a la spec map)??

shit Im swamped at work cant get a second to surf, but I saw the first render! awesome! it’s good it’s coder art :slight_smile: quicker to get a preview. but I can’t find that pic was it CPU or GPU rendered? would be cool to know if brecht is doing CUDA enabled code straight off, or focusing on C just to get the implementation working.

if anyone knows please enlighten me I’ll check the thread when I get home.

yeah but it works, And volumentric is not working at all. i think it is more important then SSS in one node.

Volumetric has a timeline already. It’s a goal for 2.69. They’ll work on it when they work on it.

RE: mapping SSS with a texture in Arnold, you can control any material setting with a texture. SSS specifically can be done with a B&W image mapped to diffuse weight, overall SSS weight, or individual SSS weights, or all of them at once if you prefer.

@ace and others about my earlier post…
I am fully aware this is not a dedicated skin shader…I follow the same lists as everyone else :wink:
I just think that now there may be a possibility the have a depth option with or without a color ramp…or an additional light path…some way to avoid a dedicated skin shader. that is my speculative question…I’m really not about dedicated shaders…I feel in the long run, they are limiting…well not limiting, but are not good for many uses, unlike many smaller generic shaders that can be linked to create far more complex shader… :slight_smile:

Thanks m9105826 !! This is amazing!! Hope will have this kind of control.

We already have this kind of control. SSS and diffuse weights are nothing more than mix values, and mix factors can already be driven via images in Cycles. On day one that SSS is available to us I’ll have a skin shader similar to Arnold’s up for testing.

looking forward to it.

I still hope that Cycles isn’t getting to mich bloated because all of this “special” things like SSS, special BSDF’s for everything etc.

SSS would be a special thing?

lol at SSS as a extraneous “special” feature.

Yes too exotic we don’t need this!

On that note, I don’t think a skin shader or an ubershader would be “exotic” either. Skin is one of the most common materials for animation, and an ubershader would speed up the creation of 95% of materials, both of which would speed up production considerably. Not all Cycles speedups need to come from the render core itself. All in all artist time is much more expensive than render time.

You watch too much Fajardo keynotes :wink: I basically agree but there is a difference between Cycles and Arnold, i.e. the audience. Freelancer/small studios (Cycles) Vs blockbuster productions (Arnold). If Cycles is aimed to small ones for real, this “render time is not that important” thing isn’t applicable so well for Cycles too, personally i wouldn’t be so sad to see some sort of small bias to speed up things. Imho.

If you compare workflows and deadlines between small studios/freelancer and big ones, well, rendertimes matter.

I agree, as long as it looks good, its good to me, if I ever want totally accurate stuff, I’ll use Maxwell or similar!

I was told that Cycles was aimed primarly at character animation, which requires fast render with good looking results, and so far so good as far as looks goes, and if all of these features ever get ported to a workable GPU render engine, then We’ll have speed and We’ll be in business! :slight_smile:

Cycles already has bias, about as much bias as a path tracer can have before it stops being a true path tracer. I’m not saying that there shouldn’t be more speedups to the Cycles core, but other parts of the pipeline shouldn’t be completely ignored.

Does anyone know if there was a Sunday Meeting today (since it’s Easter), if so, has Brecht made another report on the status of the SSS project?

m9105826 - well i guess you got my point. I’m not a fan of pre-pass and such stuff either.

@Ace- no Ton, no Brecht no devs. Nope, no meeting.

@PA3D - I used Maxwell for a while. My god, a PITA, took ages for basic stuff. Never back again. :slight_smile: