Micro/angle dependent Roughness & Iridescence

[pixelgrip]

@Secrop i understand.To make things clear,you are talking about implementing the shader to the source code not OSL?

you a talking about some points that need solutions

-thin film tickness roughness
-structural iridescence
-Diffraction gratings

are the main points if im not wrong

diffraction grating could be implemented in the anisotropic BRDF if i read your posting right.

i guess building a new shader for the iriscence is the better way.the reason for this is,if you like to stack more layer,this could not be possible or tougher to implement in the principled shader.

for easy understand.i have posted some UIs from plugins or shader solutions from other renderengines ,see post #211
i think this could be the same way the UI could look,based on the features that become implemented of course.

i think one problems for the thickness roughness would be the scaling,im not sure atm.

the thin film code itself could be easy implemented as you sayed a few post before.maybe the best way is to keep it stupid simple as possible, to make it work first.

i have a idea of 3 shader solutions :

one would be the basic thinfilm code as seen in the other renderengines
second would be the thinfilm code with an option for multiscattering (could be implemented in shader one as well)
third would be a seperate shader for structural iridescence.

the structural shader could be work like a subsurface scattering shader.
for the shader basis i would chosse an glossy brdf shader.on top of it if would implemeting the thinfilm code.all the transmission that goes trough the layer underneath the thinfilm would be simply scattered by the roughness from the glossy code (with custom ior for the mat of course).

the reason to bulid the thinfilm on top of a glossy shader for the strucural iridesence,is to keep the calulation trough the layers if that makes sence.

like in this picture

Structural coloration

just some ideas

[MartinZ (Martynas Žiemys)]

@Secrop

Now, things we need to consider:
-how do we want to implement iridescence in a way simple to use and understand?
-how do we want to deal with the roughness when mixing closures?

It’s a hard problem from developer’s perspective I guess. But then why solve it completely? Fresnel is used by everybody and it is not integrated into any of the shaders. And this works for everybody. The less advanced users use materials shared by the more advanced users, and advanced users can make whatever they want out of the parts provided. Just a random thought: What if all BSDFs were somehow split into even finer parts as nodes?.. What if we had tools to construct BSDFs out of parts using nodes? What if we had access to those ray path vectors from shaders in nodes? Or maybe a node that exposes the math of the bidirectional scattering distribution function and nodes for inputs of light that goes in it from the scene… Does this sound crazy?

[Ace_Dragon]

@MartinZ

Just a random thought: What if all BSDFs were somehow split into even finer parts as nodes?.. What if we had tools to construct BSDFs out of parts using nodes? What if we had access to those ray path vectors from shaders in nodes? Or maybe a node that exposes the math of the bidirectional scattering distribution function and nodes for inputs of light that goes in it from the scene… Does this sound crazy?

I would be for that as long as they were placed in a separate shader node category, how about shader (low level).

In the same vein, we should have a shader (high level) category for nodes like Principled, Skin, Cloth, ect… That way Cycles can cover all bases for all types of users.

[MartinZ (Martynas Žiemys)]

@Ace Dragon

I would be for that as long as they were placed in a separate shader node category, how about shader (low level).

In the same vein, we should have a shader (high level) category for nodes like Principled, Skin, Cloth, ect… That way Cycles can cover all bases for all types of users.

There are already node groups for simplifying. There would be nothing functionally different from other nodes. Currently nodes are not divided by complexity, I don’t think they should ever be. That would be unnecessary level of complexity and confusion in my opinion.

I think this would be logical for node workflow as there is basically nothing different from how nodes are now, just more control and more functionality. I don’t think this would be the hardest thing to implement as well, would it? Everything is already in place in the UI, no new workflows for current users…

[Ace_Dragon]

@MartinZ

There are already node groups for simplifying. There would be nothing functionally different from other nodes. Currently nodes are not divided by complexity, I don’t think they should ever be. That would be unnecessary level of complexity and confusion in my opinion.

That’s not what I meant, when I mean separate categories I don’t mean different socket types, I mean separate categories in the add node menu (otherwise you would have an incredibly long list of entries).

[MartinZ (Martynas Žiemys)]

@Ace Dragon

That’s not what I meant, when I mean separate categories I don’t mean different socket types, I mean separate categories in the add node menu (otherwise you would have an incredibly long list of entries).

Oh, that, yes off course. I cannot disagree to that. Not only to make it look nicer, but for functionality - a lot of people use keyboard letters for shortcuts like if you press shift+A -> H -> L it adds Glossy shader and so on. At the moment Input -> Value is already without a letter in the long list. It would be nice if they had enough letters for every list.

Do you think such an idea could actually become reality some day?

[pixelgrip]

@MartinZ

But then why solve it completely? Fresnel is used by everybody and it is not integrated into any of the shaders. And this works for everybody.

the Fresnel function is needed for calculting the thin film code.but the good news are,you dont need to programming the Fresnel function again.You can use the Fresnel function that is allready in the Blender math headerfiles available.you can simply include the math you need into your main shader code.

here a Fresnel headerfile for example

Blender Developer - developer.blender.org

edit,wait no you dont need the Fresnel,cause the thinfilm code itself is a Fresnel function.
but if you need some math functions,you can include the math code from the library as described.

edit,just for fun here my leather attempt with moonys shader

[MartinZ (Martynas Žiemys)]

@pixelgrip

the Fresnel function is needed for calculting the thin film code.but the good news are,you dont need to programming the Fresnel function again.You can use the Fresnel function that is allready in the Blender math headerfiles available.you can simply include the math you need into your main shader code.

I don’t get how it works at the moment. Does not make a whole lot of sense. The way I understand it GGX Microfacet models should have Fresnel in the maths. It must be hard-coded inside at the moment. It should be exposed to the user. Glossy shader should have Fresnel input in it. Or at least IOR for approximating Fresnel.

[Hadriscus]

If I remember correctly a metal bsdf with n & k values was in the works and was supposed to replace the glossy bsdf. Authored by Lukas, I think.

[pixelgrip]

@MartinZ

I don’t get how it works at the moment. Does not make a whole lot of sense. The way I understand it GGX Microfacet models should have Fresnel in the maths. It must be hard-coded inside at the moment. It should be exposed to the user. Glossy shader should have Fresnel input in it. Or at least IOR for approximating Fresnel.

What do you mean,that thin code need a Fresnel input? that isnt nessesary.As i said before ,the code need only the three ior values (like in the UIs from the other renderengines i posted) and a thickness value for calculation.

I dont know the whole code from Blender too ,but if you are interestet in some shader functionality or the math behind,you can have a look into the source code all the time.For exaple you mentioned the GGX Microfacet model.simply have a look at the code from it.

see line 236 for code documentation.(in general its very helpful if devs document they code,for revisit or better readability for others)

and look at line 249

Blender Developer - developer.blender.org

[MartinZ (Martynas Žiemys)]

@pixelgrip

What do you mean,that thin code need a Fresnel input? that isnt nessesary.As i said before ,the code need only the three ior values (like in the UIs from the other renderengines i posted) and a thickness value for calculation.

I dont know the whole code from Blender too ,but if you are interestet in some shader functionality or the math behind,you can have a look into the source code all the time.For exaple you mentioned the GGX Microfacet model.simply have a look at the code from it.

see line 236 for code documentation.(in general its very helpful if devs document they code,for revisit or better readability for others)

and look at line 249
https://developer.blender.org/diffusion/B/browse/master/intern/cycles/kernel/closure/bsdf_microfacet.h

I mean in my opinion Cycles shaders could make a bit more sense. Some hardcoded Fresnel is used in GGX microfacet models and then some other is used to mix the whole thing with diffuse by the users. Fresnel with it’s controls should just be fully integrated into Glossy shader in my opinion or even better, the shader should have an input for Fresnel - that way the users can make it as simple or complex as they want.

[moony]

@MartinZ

I mean in my opinion Cycles shaders could make a bit more sense. Some hardcoded Fresnel is used in GGX microfacet models and then some other is used to mix the whole thing with diffuse by the users. Fresnel with it’s controls should just be fully integrated into Glossy shader in my opinion or even better, the shader should have an input for Fresnel - that way the users can make it as simple or complex as they want.

I think glossy and aniso could be combined - they give identical results when anisotropy = 0 and as far as I can tell have identical performance too.

Rename aniso to glossy - then just remove the glossy node.

[lsscpp]

@MartinZ

I mean in my opinion Cycles shaders could make a bit more sense. Some hardcoded Fresnel is used in GGX microfacet models and then some other is used to mix the whole thing with diffuse by the users. Fresnel with it’s controls should just be fully integrated into Glossy shader in my opinion or even better, the shader should have an input for Fresnel - that way the users can make it as simple or complex as they want.

That is as it was in the very first versions of cycles: glossy node used to have IOR value

@moony

I think glossy and aniso could be combined - they give identical results when anisotropy = 0 and as far as I can tell have identical performance too.

Rename aniso to glossy - then just remove the glossy node.

Really agree with you, unless some dev has strong points against doing this, for reasons that I can’t figure out

[Secrop]

@MartinZ

Just a random thought: What if all BSDFs were somehow split into even finer parts as nodes?.. What if we had tools to construct BSDFs out of parts using nodes? What if we had access to those ray path vectors from shaders in nodes? Or maybe a node that exposes the math of the bidirectional scattering distribution function and nodes for inputs of light that goes in it from the scene… Does this sound crazy?

Not really. Actually I believe is the path things going to eventually take. Now a days, 3D artists are becoming more aware of the math involved in their work, and it’s time to start giving artists more control instead of repeating the stereotype that ‘artists cannot do logic’.

For example, OSL will probably have in the future the possibility to program closures. I still don’t know what kind of interface we could have for that…Should we allow things like sss, and have output vectors away from the point being sampled? For other types of shaders there would be no problem except perhaps the ‘optimization’ vs ‘compiling time’.

[pixelgrip]

@moony

I think glossy and aniso could be combined - they give identical results when anisotropy = 0 and as far as I can tell have identical performance too.

Rename aniso to glossy - then just remove the glossy node.

i guess, the aniso shader was programmed based on the glossy shader code,they added the aniso function into a glossy.like Secrop mentioned the microroughness code would fit into the aniso shader.

MartinZ,i dont see much benefits from a Fresnel integration into a glossy shader.what would you get? a black glossy shader with Fresnel reflections,ok.but you have to mix it anyway with another shader.and thats not so easy then.think about a white diffuse with your black glossy Fresnel.you cant mix it the old way because you have add Fresnel to your glossy allready.you cant mix it with a add shader ,you are double your light as you sayed to my shader a few postings before.in a mix shader the reflections intensity from your fresnel are 50% reduced (outgoing from 50/50 mix).

[MartinZ (Martynas Žiemys)]

@pixelgrip

MartinZ,i dont see much benefits from a Fresnel integration into a glossy shader.what would you get? a black glossy shader with Fresnel reflections,ok.but you have to mix it anyway with another shader.and thats not so easy then.think about a white diffuse with your black glossy Fresnel.you cant mix it the old way because you have add Fresnel to your glossy allready.you cant mix it with a add shader ,you are double your light as you sayed to my shader a few postings before.in a mix shader the reflections intensity from your fresnel are 50% reduced (outgoing from 50/50 mix).

That’s awesome. More inputs then. An input for a base shader - problem solved. No need to invent anything new - Luxrender does it:

Maxwell as well. If you have specular reflections you don’t see diffuse - that’s how it is - it gets darker then and with more roughness you see less Fresnel, so you see lighter blurrier reflections. Fresnel curve can be different than what Cycles Fresnel Node gives as well.

I think, the more things get exposed to the users the more flexible it is going to be - I think this is where magic happens when not only the developers who can code think of creative usage of the tools available to them but all the users of the software. That’s the strength of Cycles nodes system already - you can make a lot of things with it. It seems to me it would only build further on top of this strength.

[Hadriscus]

@MartinZ

Just a random thought: What if all BSDFs were somehow split into even finer parts as nodes?.. What if we had tools to construct BSDFs out of parts using nodes? What if we had access to those ray path vectors from shaders in nodes? Or maybe a node that exposes the math of the bidirectional scattering distribution function and nodes for inputs of light that goes in it from the scene… Does this sound crazy?

Not at all, you’d simply end up with a monster called Mantra.

[Ace_Dragon]

@Hadriscus

Not at all, you’d simply end up with a monster called Mantra.

Would it be so bad, a lot of people consider Mantra one of Houdini’s strong points.

The idea anyway is that you should only be expected to use them if there’s more or less no other way to physically recreate a certain material (and even then they might primarily be used as an extension to higher-level blocks).

When it comes to extending though, these elemental blocks could be even more useful if they could modify the output of an existing shader node (with shader inputs and outputs, so you can do effects you simply can’t do with the mix or add shader blocks). Imagine adding something like a Bend Rays or Scatter Rays node that the output of a Transparent shader goes through).

[lsscpp]

@Ace Dragon

Would it be so bad, a lot of people consider Mantra one of Houdini’s strong points.

The idea anyway is that you should only be expected to use them if there’s more or less no other way to physically recreate a certain material (and even then they might primarily be used as an extension to higher-level blocks).

When it comes to extending though, these elemental blocks could be even more useful if they could modify the output of an existing shader node (with shader inputs and outputs, so you can do effects you simply can’t do with the mix or add shader blocks). Imagine adding something like a Bend Rays or Scatter Rays node that the output of a Transparent shader goes through).

“Bending rays” combined to Is shadow immediately makes me think of more accurate fake caustics for refraction (oxymoron accurate/fake, I know…)

[Hadriscus]

Nah I don’t have experience with Mantra I’m just talking out of my ass, but I’ve dived a few times inside Mantra off-the-shelf shader networks and I quickly got out, sweat dripping down my face, feeling dizzy and helpless. With great power…