Hm,if it works fine.What about changing to front keylight with backlight off,without changing SSS color setup?
So you currently can’t use SSS in GPU mode, and need to switch to CPU rendering?
Yes, before the bug gets fixed we can only use CPU for SSS for now.
Principled v2: Lukas published a branch with an early (incomplete) version, there is a feedback topic with active discussion.
If I got it right, the new v2 Principled is incompatibel to the v1?
I think backwards compability is pretty important, espeically for all these people who started to create an material Asset Library or all the third party shader and assets packs. Would be not great if all of those would need an update.
Are there any plans for a 100% backwarts compability?
Maybe having a dropdown, with v1 and v2?
https://developer.blender.org/T99447
Also currently there is a dropdown in the build, not sure if the dropdown will be kept in the final version though.
Thanks so much for giving the Principled shader more attention! All of the changes here look amazing.
Is there going to be an input for translucency, or is that part of the thin surface discussion that comes later? The one weakness of the Principled shader right now is that it can’t do paper, grass, etc. I regularly have to mix it in afterwards.
I’m not sure how physically accurate the effect is, but if it mixed with the diffuse before the glossy and other components at no more than 0.5 then it should be close enough. It could potentially even be an option under the SSS type dropdown to save space since the two wouldn’t be used in combination, and it could use the subsurface radius to determine which colors of light get let through.
Is something like that possible here?
These comments remind me of an old RCS proposal:
If you guys think some ideas could be worth I can update those mockups, to gather ideas from
And anyway @lukasstockner97 do you know where we can checkout for that UI improvements todo list?
I don’t think node UI should get overcomplicated. At the moment, all we need is separators, possibly with labels. The proposal seems to want to do much more than that.
With the amount of inputs I think collapsable panels are going to be important. Complex geometry node groups also need this, to make a good UI for the modifier stack.
Something like this old prototype:
I think it would be good to have a node for ‘Specular map to IOR’ conversion provided with Principled BSDF v2. Quixel assets all come with measured specular textures, for example. Specular maps are incredibly useful for fixing issues with micro occlusions in textures. They can provide a higher fidelity look especially for environment textures where you might not have every detail modelled out in high poly since you can use the specular map to remove any reflection from micro occluded areas. There are numerous examples where they can help with rendering quality.
Hello I like the new Clearcoat.
I attach images of my tests with IOR at 1.52 to standardize on all Engines
Vray Glossiness 0.7 + Coat:
Corona Glossiness 0.7 + Layered Mtl for Coat:
Arnold Roughness 0.3 + Clearcoat:
Cycles Roughness 0.3 + Clearcoat:
I am not sure. I can sort of understand it for node groups, but not sure about the base nodes. If there’s ever need for collapsible panels on base nodes, it’s a clear sign that the idea of node based workflow (simple building blocks) has been defeated. Simple separators would be fine, but collapsible panels are now additional concept user will be forced to interact with and therefore wrangle.
You say standardize. Are you certain you used the same color transform/tonemapping in all the engines? Some engines these days do some tone mapping out of the box, others don’t. That can make significant differences. Also, in Arnold version, you’ve clearly forgot to increase the reflection trace depth. Doing comparisons like these requires some advanced knowledge.
Hm. I don’t agree. For most nodes it should be simple enough but some - like the Principled BSDF - just are more complex. Ideally the granular nodes that can build the complex BSDF node are still there but ultimately in some cases there will be more slots. And those cases need a solution.
I really like Juan Linietsky’s approach to adding features to Godot - if a problem arises it needs to be solved just don’t try to solve constructed problems for cases that don’t exist yet or will be very fringe cases. I’d consider large nodes with many inputs a long existing problem at this point. They have been there before Blender 2.8 and they can be found in many other software packages as well. I like the approach of finding a sensible solution for them better than trying to wish their existence away.
I absolutely agree that they should be the exception but I really wouldn’t want to always piece together something as complex as BSDF from granular nodes. I’d end up with a large node group with a ton of inputs eventually. And then the problem of too many input collapsing is still there.
There are almost no large nodes with many inputs in Blender. Just nodegroups, where this could be justified. But regarding nodes themselves, the Principled BSDF is really an outlier here. So I am not sure it’s worth introducing a while new UI concept because of just a single node that has gotten out of control. I am not against separators, but I am against something that actually requires user’s input interaction, and therefore takes time. It will add yet another layer of management to a UI system which is already time consuming to manage and keep clean.
BTW I don’t mean that the alternative to Principled BSDF overcomplicated UI should be building the shader yourself out of atomic BRFDs/BSDFs. In fact I keep saying for at least couple of years now they should be deprecated.
I vote yes on collapsable panels. This is at least better than the previous compact node design which just moves everything to the N panel.
If we can get away with less user interaction I am all for it. How would you solve it, then?
