[Bf-cycles] Cycles and Fresnel

Dmitry Andreev andcoder at gmail.com
Sat Jun 1 04:43:28 CEST 2013

I don't have a preference here. I am not that familiar with the code base.
So I am ok with anything as long as it produces correct results. I am going
to try out this extra output only because it would not break any existing
shaders and it feels like it could be done easily and would allow for very
robust material control.
It might not work, but at least I will have a better understanding of
what's going on there. Mix and Add things do something sketchy in the
compiler, wondering is it will work with that.

Fresnel handling has to be fixed for sure. Just looked at OSL glass
yesterday and it wrong as well (uses average normal).

The bottom like is to create a separate BSDF that will handle all those
things consistently. What you really define is a layer, it's thickness,
absorption coefficients (color), IOR ramp (it might be dielectric or
metal), normal distribution. And then, like in that paper, you just have an
extra node that would do the layering. So light hits the top layer,
reflects, then refracts from the same normal, passes thru the layer and
gives you transmitted component. Then you can plug it into a different
layer node and so on.

Current mixing and adding closures is only good think layer blending and
for general material mixing, like when you want to get a more complex
distribution. But you have to respect microfacet normals or else it's going
to break.

- Dmitry

On Fri, May 31, 2013 at 5:01 AM, storm <kartochka22 at yandex.ru> wrote:

> Very interesting paper, thanks. What is your preference to implement
> that, another BSDF output "Microfacet facing"? Make it as ShaderData
> member, expose in BSDF nodes GUI, and allow general (not only mix/other
> bsdf) connect to them ? It will require to respect that in every other
> BSDF as additional "hidden" mix ?
> ---------- Forwarded message ----------
> From: Dmitry Andreev <andcoder at gmail.com>
> To: bf-cycles at blender.org
> Cc:
> Date: Fri, 31 May 2013 04:26:24 -0700
> Subject: Re: [Bf-cycles] Cycles and Fresnel
> >Probably it makes sense to include the fresnel in the Glossy BSDF node
> >itself yes, if it needs to depend on the specific BSDF normal.
> That's an option. Though I think it's a common issue for Refraction and
> Glass BSDFs. Anisotropic Ward BSDF doesn't even have fresnel term in theory
> that causes other issues.
> For layering (in a long term I think) it would be nice to have
> this “Arbitrarily LayeredMicro-Facet Surfaces” by Weidlich and Wilkie.
> http://www.cg.tuwien.ac.at/research/publications/2007/weidlich_2007_almfs/weidlich_2007_almfs-paper.pdf
> Generalized coating that also has to work with proper microfacet normals.
> Mixing or Adding shaders can't do that. I think of those are really
> interleaving different materials in the same layer on micro level.
> One way, I guess, to make layering work currently is to output Fresnel
> component from BSDF nodes themselves and then you it for Mixing when
> needed. Generally speaking you can't do stuff like mix( diffuse, specular,
> fresnel ). Yes, it guarantees that the energy is conserved, but it's too
> conservative. For plastics, for instance, one would do things like diffuse
> * Fresnel( at normal angle ) + specular * Fresnel( half angle ).
> Ashikhmin Shirley while using Fresnel( half angle ) for specular modifies
> diffuse in a different way which also doesn't always work. Not for all
> materials.
> It looks to me that there is no good generalized solution for that. So
> it's up to an artist, which is ok.
> So BSDFs output F and anyone can use it for mixing/weighting if they want
> to.
> Then the second question is how to handle metals there. Metals are colored
> at normal incidence and then get darker at some point and then get
> desaturated at 90 degrees.
> It could be a separate BSDF with more parameters just for metals.
> Or if instead of Fresnel they output partial Fresnel like pow( 1 - dot( n,
> h ), 5 ) or just simple microfacet facing (dot(n, h), then for dielectrics
> you would plug it first into MixRGB node with Color1=0.04 and Color2=1
> which would correspond to IOR 1.5 and then you plug it into Mix Shader node.
> For metals you would plug that value into ColorRamp and get the desired
> effect there so you could do really advanced metals with spectral curves.
> That would require modification to Mix Shader node so it could mix channels
> separately but it already does it internally with Weight and SetWeight
> operations (in SVM).
> Then you can do really advanced artistic stuff along with realistic
> things. You can take n,k data and convert them into ramps like this:... (I
> attached examples of what you can generate from n,k data for aluminum,
> chromium, copper, gold, nikel). You can represent any metal like that.
> Of course very few people would figure how to use it. But with some
> tutorial one could do a lot of fun cool.
> Some render engines only give you IOR, or IOR + color of normal
> reflectance, or raw n,k data. But all of them are hard to control.
> Especially with n,k data. Most or real world metals are alloys and covered
> with oxides but ramps like that would give you more artistic control while
> being plausible.
> Anyway, that's just an idea.
> Alternatively, BSDFs might take another BSDF as an input that they cover,
> and then handle all that stuff inside.
> Sorry for throwing so much stuff in here. I guess I'll think more about it
> over the weekend and maybe try this extra BSDF output thing.
> - Dmitry
> On Thu, May 30, 2013 at 6:17 PM, Brecht Van Lommel <
> brechtvanlommel at pandora.be> wrote:
>> Hi Dmitry,
>> On Fri, May 31, 2013 at 12:43 AM, Dmitry Andreev <andcoder at gmail.com>
>> wrote:
>> > I have local changes only for Glossy BSDF with GGX distribution but
>> would
>> > like to generalize it to everything. The question is how to do it best
>> > within Cycles kernels and SVM (without side effects) ?
>> >
>> > I have/had a few ideas of how to do it best but some of them had side
>> > effects. The one that I am thinking of right now is that everything has
>> > basic IOR input, but you could plug a special advanced Fresnel node
>> into it
>> > that would be evaluated withing closures themselves. That advanced node
>> > could have multiple options: 1. simple dielectric IOR, 2. spectral n,k
>> data
>> > that could be pre-integrated into LUTs using standard CIE illuminant and
>> > standard CIE observer. It would look something similar to ColorRamp
>> node.
>> > And add some presets there that could be easily generated from n,k
>> > databases.
>> Probably it makes sense to include the fresnel in the Glossy BSDF node
>> itself yes, if it needs to depend on the specific BSDF normal.
>> > Another idea was to have closures leave something on stack like
>> microfacet
>> > normal. So by default it would be average geometry/pixel normal, but it
>> > closure is microfacet based it would override that with H vector. Then
>> > Fresnel node that is connected to its output will use that. But this
>> would
>> > not work with all the mixing and other stuff unless you plug that
>> Fresnel
>> > node directly after the BSDF.
>> I don't think this woud work, node should be self contained and only
>> pass data forward through node links.
>> When we put the fresnel in the BSDF node, the main issue is how you
>> mix / layer such BSDF's. I haven't figured out a design yet for more
>> advanced layering of BSDF's. Maybe the BSDF node needs to output some
>> mix / layer weight, or we need a new Layer Shader node, or something
>> else entirely? What would need to be done is look at some layered BSDF
>> models, write down the equations and figure out how we can split that
>> in composable nodes.
>> I'm not familiar enough yet with this stuff to give good advice, would
>> need to do a lot more reading and thinking for that. The design would
>> have to fit in the OSL closure model, where the result of a shader
>> evaluation is a linear combination of closures. If a linear
>> combination is not possible then a special layering closure could be
>> created too, which takes other closures as parameters but I'm not sure
>> if this will be needed.
>> Brecht.
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130531/ca3b831a/attachment.htm 

More information about the Bf-cycles mailing list