If we can get away with less user interaction I am all for it. How would you solve it, then?
2 Likes
By simple separators?
I also think the Reflection model and the SSS model dropdowns should go away. These should not be user facing options. The best model should simply be selected and used.
2 Likes
As the Principled shader is meant to be a solution between realism and easy effects for artists, I would like to propose to include a faux glass option for clear and fast-rendering glass, plastic, eyes, etc… Right now I’m using node setups like these to achieve that:
It could be a simple checkbox named something like “Faux Glass”, placed below the Transmission entry. A certain other renderer has a “Fake Shadows” checkbox.
Ideally, the option would also benefit rendering speed and clarity of semi-transparent effects like SSS.
11 Likes
Separators might be OK, but in this concept they are very weak and don’t improve the situation. And please don’t remove the SSS method dropdown. There is no “best” option. I choose them depending on the situation and object and so switch them quite frequently.
3 Likes
I think it should happen automatically whenever the users disable refractive caustics in render settings. Users should not be forced to set that up manually.
Once that’s done, the refractive materials shadows rays should be just shadows by a simple fresnel amount. When caustics are off, transparent, fresnel masked shadows are usually much closer to the ground truth than completely opaque shadows:
Comparison (click to expand)
I’ve set Filter Glossy to 0 and Indirect Light clamp to 0 to disable any bias:
This is the reference with Refractive Caustics ON:
This is with Refractive Caustics OFF:
And this is with fresnel masked shadows:
And this is how the glass shader setup looks like:
Once again with HDRI:
Refractive Caustics ON (reference):
Refractive Caustics OFF:
Fresnel masked shadow:
As you can see, transparent shadows are still fake/biased compared to the ground truth caustics reference, but they are much less fake/biased then completely opaque shadow. And the softer the shadow is (and therefore less pronounced the caustics pattern is) the more the difference between ground truth and transparent shadows fades away. More importantly, unlike just naively mixing with Transparent BSDF, you will still get increasing shadow occlusion of your refractive material as the angle between the light source and the surface becomes increasingly parallel.
Alternative way to go about it would be to remove the refractive Caustics checkbox from the render settings, and instead have it per material. If Enabled, it’d render real caustics, and if disabled, it’d render the fake shadows described above. But if it was per material, I think it should be in the material output node, not in the Principled BSDF node.
7 Likes
ProRender addon has nice UI solution about components, may be something like this will be suitible for Principled
6 Likes
Principled has too many attributes, I think a good way to minimize the overhead is to group them by their effect, and call these components as needed.
In this way, you would start with a very basic material and as you add components to it, it will increase in complexity.
In the attached image I show the minimum Principled and the Principled adding the translucency attributes.
I see that PetrTarasov suggests something similar.
6 Likes
The “idea of node based workflow” is not one of “simple building blocks” but one of non-linearity
7 Likes
Thank you @lukasstockner97 for making Blender more and more of a professional, state-of-the-art tool. Your work is invaluable.
I’m not a professional UI designer, but I like to think along when it helps. Would separating the components into nodes be worth exploring?
1 Like
We use panels throughout the UI to organize settings. Remember that geometry and shader nodes are also editable from the properties editor, where we already use panels, and so they would fit in naturally.
If the proposal is to be inconsistent with that, there should be an argument for why it’s significantly better. And it should ideally then also explain how the problem of complex node groups will be solved, if the same method can be applied to that or if it would require us to implement and maintain two systems for organizing node inputs.
15 Likes
Many people use home-crafted ubershader in the form of complex nodegroups. I used to do as well, and that’s how the idea of the nodes-UI proposal come out. I still think that having separators, dropdowns, checkboxes, etc. would be really useful when combining granular nodes into in large setups.
Now, since Principled is somehow a big network of connected components, why not just think of it as a nodegroup? Not an “outlier node” but an “outlier nodegroup”, one that can’t be opened.
Seeing it this way, would make logical for it to have an improved interface, as that in Brecht’s mockup
3 Likes
Yes, you can see that in the exact sentence you quoted, I mention nodegroups. I am not against collapsible node group sections. My point is that nodes so long they requires collapsible sections should be a rare exception, and should be avoided whenever possible.
Node groups and perhaps Principled BSDF could be that exception, but most nodes should stay simple enough so that they don’t need any sections. We should have as few ubernodes as possible.
Collapsing sections just introduces whole new UI concept users now have to interact with, and also lots of new UI problems to solve. For example what happens when you collapse a section which has node links connected to some of the inputs in the section.
I think inputs with connected links should not be collapsable. Think of it as a manual version of Ctrl H where you can choose to hide certain sockets instead of hide all unconnected ones (I currently would connect the sockets temporarily, Ctrl H, then unconnect them. Rather cumbersome). I think it makes sense.
1 Like
I said standardize IORs. My goal is to show just how these engines are working with Coat and how they display renders as much as possible in their default settings. In all the engines, lower the settings to get the renders in less time and that’s right Arnold is the most affected because it even affects the reflections and this is noticeable in the chrome sphere and not so much in the red one (which is where the Coat is appreciated ). I have no problem getting everything high again, but right now I don’t have the time. Even if you do everything to get closer between engines there will always be differences, times, noise, some will be better with one task, others with another…
Hmm the result of changing doesn’t seem to make sense either, now we have clearcoat tint working even when there is no clearcoat… I still believe it would make more sense to desaturate the orange as the slider decrease.
Yes, that’s more the way I see it, too. Everything should be kept as fast and easy as possible for the sake of user experience. At the same time I feel that complex nodes that solve a problem without having to piece together individual components all the time is exactly that - faster and more eficient in the long run.
How to organize the large amount of nodes and inputs has to be seen as a separate subject.
3 Likes
Alternatively, could the smartest rendering geniuses come up with the end-all-be-all-alpha-omega-absolute best ever faux glass node group and put that in the official asset download package?
Why are these the default? If it has to do with human skin, as someone who doesn’t make humans with skin, I’d prefer if these defaulted to something neutral.
And why can’t this just be a color input?
1 Like
If you look at measurements for real materials, it’s typically (practically always?) R > G > B. The choice is somewhat arbitrary, but R = G = B does not seem like a good “neutral” value, if there is even a useful definition for that.
Because they are scattering distances and not represented well by a color. A valid scattering distance may for example be 10, or there may be a significant visual difference between 0.01 and 0.02.
3 Likes
In the light of this, i.m.h.o. it would be clearer if those values would have a unit indicator behind them. Lots of people don’t realize that those values are in Blender units. If “m” would be behind the values, that would make it clear.
Alternatively, the “Subsurface Radius” label of the drop-down menu could be changed to “Subsurface Radius (units)”.
Also, I think a tenth of the current values would be a better default (0.1, 0.02, 0.01), as the default values in meters cause a very large SSS penetration in models with realistic dimensions. It’s the first thing I always do when using SSS: dividing the Subsurface Radius values by 10.
13 Likes
And what if my Unit Scale in Blender is set to “0.01”? Will that still be meters? My whole workflow is in centimeters otherwise.
2 Likes