Separate BSDF can extract a color from BSDF node. A user edit color like BI, then Combine BSDF combine the edited color and BSDF.
These nodes can make following results.
@Clément Foucault (fclem), I guess you can comment on how this fits in the Eevee design. This probably won't be supported by Cycles soon.
Any reason this is called "Separate BSDF" rather than "Separate Shader"? Does it only work with BSDFs, or do Emission nodes work as well?
Also related discussion here:
Either add your name here, or remove this line.
We use the term "Alpha" instead of "Opacity" in Blender shader nodes, so we should be consistent with that.
This exec function can be removed, it is for Blender which no longer exists. We kept the exec functions since that system might be reused for textures nodes in the future, but nodes involving BSDFs wouldn't be part of textures.
I think this is the easy way. It's just extracting radiance from the bsdf struct so it's a bit unpredictable with most of the bsdfs.
The more correct and maybe more intuitive would be to just convert closure to color implicitly.
This implicit conversion would collapse the bsdf values to a simple color/alpha.
The problem resides in the Screen Space deferred outputs. We should not use SSR or SSSS for any node in upstream. But these upstream nodes can be linked to the output node via another route.
So what I suggest is to just evaluated the specular reflections at the conversion point. For the SSS just multiply the radiance by the SSS color and don't do anything fancy. I know
SSRefraction is already evaluated in the forward pass so it's not a problem.
I had plans to do this stuff but if you are feeling like doing it please let me know so we don't duplicate work.
A good starting point would be to see how we convert color to values with the convert_rgba_to_float function and implement a similar function (convert_closure_to_rgba).
For the inverse conversion (RGBA to Closure), I would do that implicitly too by just considering this RGBA as radiance + opacity.
From a UX perspective i'm not quite sure what would be the most clear, intuitive and reliable way between adding conversion nodes or implicitly converting.
I tend to think the conversion node are there if you want to only extract component one by one.
But in practice, the closure is not set in stone and I would prefer to blackbox it.
So my vote goes to implicit conversion.
I am working on this also, check out: https://devtalk.blender.org/t/contribution-npr-nodes-in-eevee/372/13
My solution does "blackbox" the BSDF by having a Split Shader node for the ramp, and a Half Lambert BSDF to have as the base of the lighting (but you can use Specular and other nodes also with good results).
I also added a third node type which is the same as the Seperate BSDF here, for more flexibility, but my original design was just the two nodes mentioned above.
There isn't a need for Combine BSDF, as Brecht mentioned, because you can use Emission.
In my testing, the Split Shader + Half Lambert combination works quite well and is easier to use than plugging stuff in a ramp. Not to mention more powerful because you can use shaders instead of just flat colours, and plug textures in to the ramp "stops".
I will have a patch for it by next week, so we can test it all together.
I will leave the development of Shader to Color to Kinouchi-san. Should I submit my other two nodes in a new patch or integrate them into this one?