New Corona Physical Material (PBR) playground!

[pokoy]

it would probably be a good idea to allow  mapping ior values ​​with rgb where  ​​1.0 is 0.0.0 and 3.0 is 255.255.255, in this case we can easily clamp our speclvl map values ​​to 0-128 and get reasonable results. Just my thoughts.

Is this (screenshot attached) solution good enough for you, or would it be vital to have some kind of native Corona feature for this?

I've said it many times and always will - this setup is so cumbersome it hurts. Thinking this is good enough is a mistake, sorry.
You should map incoming images so that RGB 0 is IOR 1.0 and RGB 255 is the specified IOR in the material UI. Or make a new IOR map where users can specify the value mapping in a similar way.
But to me, your setup is just not sufficient in terms of use ease nor setup time, plus you can't see what the values specified are unless you inspect all nested maps, that's absolutely insane.
It looks like you guys are going the Autodesk way on this one - "half-assed will do it, let's not think any further."
I don't mean to offend, but we already discussed this elsewhere and it's frustrating you think it's good enough.

[romullus]

It doesn't have to be cumbersome, just set-up this map once, save it to a material library and never get bothered by creating it again. And you can control everything from slate editor view, no need to go to parameter editor.

I think you are well aware that remapping Corona IOR slot as you ask, would break other people's workflows and your suggestion to introduce new IOR map would go directly against Corona's policy about simplicity. I think that current solution is more flexible and it's not complicated at all to anyone who's using slate material editor.

[agentdark45]

Would it not be easier to just create a dedicated "IOR map" that the source bitmap feeds into, that automatically inverts, and internally changes the high value according to whatever the main material IOR is? This implementation shouldn't need a material rewrite or break any pre-existing material setups (kind of like how a bitmap feeds into a "normal map" before going into the bump slot).

[pokoy]

It doesn't have to be cumbersome, just set-up this map once, save it to a material library and never get bothered by creating it again. And you can control everything from slate editor view, no need to go to parameter editor.

I think you are well aware that remapping Corona IOR slot as you ask, would break other people's workflows and your suggestion to introduce new IOR map would go directly against Corona's policy about simplicity. I think that current solution is more flexible and it's not complicated at all to anyone who's using slate material editor.

If you work on projects with some pressure behind or have to inspect existing materials and need  the fastest visual feedback you can get, going into submaps to figure out values is the last thing you need. The new workflow is flawed.
We can agree to disagree.

[Juraj]

I've placed the above macro that Romullus wrote into my base Corona material in Editor and inactivated it (checkbox off). I did this since day one.

Yes it's effectively what Pokoy writes could be called 'IOR map' but I am ok with this solution which is how FresnelIOR map should have always been (Since no one really uses it because of how cumbersome it is).

[maru]

it would probably be a good idea to allow  mapping ior values ​​with rgb where  ​​1.0 is 0.0.0 and 3.0 is 255.255.255, in this case we can easily clamp our speclvl map values ​​to 0-128 and get reasonable results. Just my thoughts.

Is this (screenshot attached) solution good enough for you, or would it be vital to have some kind of native Corona feature for this?

I've said it many times and always will - this setup is so cumbersome it hurts. Thinking this is good enough is a mistake, sorry.
You should map incoming images so that RGB 0 is IOR 1.0 and RGB 255 is the specified IOR in the material UI. Or make a new IOR map where users can specify the value mapping in a similar way.
But to me, your setup is just not sufficient in terms of use ease nor setup time, plus you can't see what the values specified are unless you inspect all nested maps, that's absolutely insane.
It looks like you guys are going the Autodesk way on this one - "half-assed will do it, let's not think any further."
I don't mean to offend, but we already discussed this elsewhere and it's frustrating you think it's good enough.

Your answer is exactly why I posted the question in the first place. Thanks.

(Report ID=CRMAX-168)

[pokoy]

Looking at my answer above I see that I should have put this in a more polite way, sorry for the harsh tone. I should back up my critique with screenshots and examples but I'm not going to be in front of my PC for the next 1-2 weeks and just can't be more specific right now. Not ideal, but I hope it's clear why the current approach isn't very user friendly right now.
What I dislike is that without inspecting maps or map trees you won't be able to tell what the IOR value is. Also, by using values outside of 0-1 map thumbnails will always be white, making it impossible to quickly check the final map, especially if you stack them you want to know what you're doing - an all white final map result won't tell you anything.
By mapping the map/map tree values instead you can immediately see what the final map stack is, since it displays in 0-255 and you specify the max IOR value in a numerical way right within the material's UI. This way you get the info much quicker with the same result.
I'm eager to see why others don't see anything wrong in going the more winded route. Maybe I'm missing something and judge too quickly.
Sorry again, Maru.

[maru]

No problem at all! I am happy to hear any feedback and actually using a more straightforward tone usually makes the message easier to understand.

[dacian]

How do you set a translucency color in the new material? other than the base color.

[maru]

How do you set a translucency color in the new material? other than the base color.

See:

we are aware that some of the features which are grayed out are not really clear UX/UI-wise on how to enable them. We have a fix ready in our development build, which should arrive to you soon.
In the meantime:
Translucency requires "Thin Shell" in General Tab
Refraction>Thin Absorbtion requires "Thin Shell" in General Tab
Opacity>Clip requires a texture map in the Opacity Texture
Volumetrics require refraction to be enabled
SSS requires Refraction at lower than 100 value.

Source: https://forum.corona-renderer.com/index.php?topic=31989.msg180472#msg180472

[Nejc Kilar]

How do you set a translucency color in the new material? other than the base color.

Seemingly you cannot quite do that anymore. GeorgeK posted this line a couple of pages ago: "In regards to your second question, the translucency fraction is still there labeled as "Translucency" you can enable it and use it without the use of a map simply by enabling the Thin Shell (no inside) option above Base Layer. The color of the translucency depends on your base layer color."

Maybe I'm wrong :D

[maru]

Ah, damn, it looks like I misunderstood the question, sorry!

[Nejc Kilar]

Ah, damn, it looks like I misunderstood the question, sorry!

For what its worth, you answered a couple of my questions with it, ha! :)

[marchik]

There is one more thing, due to the connection between roughness of reflections and roughness of refractions, it became virtually impossible to add, for example, fingerprints to the glass surface, because even the stained glass remains with 0 roughness, at first I thought that this could be solved with clearcoat but my attempts did not lead to anything good. It seems a little strange to me that when adding new functions, old ones break) and ofc the same concerns translucency color map, which in some cases just necessary

I hope you wont delete the legacy shader because sometimes some "fakes" lead to good results or maybe it will be a good idea to add "expert" mode in our new physical material which will break those "physicall correct connections"

And I also recently remembered how we discussed the idea of ​​adding a fake thickness function https://forum.corona-renderer.com/index.php?topic=15639.0 for thin meshes that would allow using the opacity map to simulate an effect similar to corona round edges in legacy mode without having to make a separate super-detailed normal map. It would be a great addition to the new thin shell and volume switching function in the new shader

[Nejc Kilar]

There is one more thing, due to the connection between roughness of reflections and roughness of refractions, it became virtually impossible to add, for example, fingerprints to the glass surface, because even the stained glass remains with 0 roughness, at first I thought that this could be solved with clearcoat but my attempts did not lead to anything good. It seems a little strange to me that when adding new functions, old ones break) and ofc the same concerns translucency color map, which in some cases just necessary
I hope you wont delete the legacy shader because sometimes some "fakes" lead to good results or maybe it will be a good idea to add "expert" mode in our new physical material which will break those "physicall correct connections"

I haven't tried it myself yet but I suspect that a potential workflow for this could revolve around having the glass be the base in a Corona Layered material while the fingerprints come on top with a mask using it's own separate material.