Better Eevee/Principled Materials
Issue #1082
resolved
From my study of the Uber shader (#1075) I came up with an improved node network for Eevee/Principled. It does not use any of the techniques or principles I found in the Uber shader MDL file however, this is purely a custom design to get around shortcomings of the current exporter and the Uber shader.
As I explained in #1075 many Daz textures are unnaturally bright because they’re made to be mixed between diffuse and translucent. They become unsuitable for use in Blender as they are. This can be fixed with Cycles and BSDF nodes, but this doesn’t work for Eevee or the principled BSDF. Eevee can’t use volumetrics so there isn’t any way to “consume” light passed into the volume, and the principled shader does not have a translucent BSDF option.
My process fixes both of these issues. And one issue about the BSDF option is the confusing routing both Cycles and Eevee inputs and outputs through all nodes for no reason since Eevee doesn’t benefit from it. Based on my preliminary results I think Eevee can be removed from the BSDF option entirely and the principled shader mode made to be its default.
Current exporter on the left, my custom node network on the right (applied the head, ears, and lips only).
Angharad 8 (Daz Original)
SASE Neveah (Sabby/Seven)
Evangeliya (iSourceTextures)
The new setup handles subsurface scattering much better aswell, though I haven’t found the right way to convert the units from Daz yet.
To start with, the diffuse textures is routed through a MixRGB node that multiplies it against the base tint and the SSS Reflectance tint. Then to convert it from a blinding white Daz texture to a useable texture, it’s passed through an HSV node to darken it. The HSV node is driven by the inverse of the translucency weight. The darkened texture is sent to a MixRGB node set to Color Dodge. When dodged with the base texture, driven by the translucency weight (not its inverse), it restores the color lost in the darkening.
The same process is done for the translucency texture too except with the translucency tint. Since Evangeliya uses mono SSS mode, the SSS color is the translucent color. So that is routed through some vector math nodes to adjust it to a proper SSS radius, though I didn’t figure how the right way yet as I said. The SSS amount itself should never go above 0.2, 0.3 max. Certainly not using the translucent weight that could go up to 90%.
While making this I discovered the specular map is totally useless. If you plug a bump map into a fresnel node, and plug the fresnel node into the principled shader’s specular socket, it does the same thing with one less 4k texture. But I keep it here for the sake of completionism. This specular map was made for Daz’s “reflectivity” properties, so it’s a 0.0 - 1.0 normalized float map. Too bright for a specular map. I multiplied it by 0.08 to squeeze it down into the correct 0.0 - 0.08 range. Then I used a fresnel node to mix it with pure white and used that as the input for the specular socket.
In this case the character also had a dual lobe specular node group added after the principled shader, but this seems unnecessary. You can accomplish the same thing by splitting the bump map off and using some MixRGB nodes to combine it with the specular map (probably using a Schlick fresnel blend) to get the same effect.
Comments (46)
-
reporter
-
Personally this time I don’t agree with most of what you say. But this doesn’t mean that you can’t propose an alternative solution to convert the daz shaders to the principled shader. You have to provide the equations for Thomas to follow for the values in your nodes. Or if some values are intended to be manually inserted by the user then this has to be specified.
You may want to take
#179One note if it may help. Eevee doesn’t follow any node connected to the radius, just the default socket values. So your whole chain connected to the radius will only work with cycles. Plus cycles and eevee are extremely different in the output they produce with the same sss values. Unfortunately.
The rest of your setup I simply don’t agree. The idea behind the actual principled conversion is to take what’s possible to be converted, then approximate the rest with “artistic“ choices. As I see it your setup is “artistic“ to start with, it doesn’t even try to convert something. But this is just my opinion.
note. As for the bsdf option not being fit to eevee I totally agree and it’s what I always “argued“ with Thomas, in a good way of course, so finally he was kind enough to provide the eevee bsdf option in the global settings, where you can turn off the dual output.
note. The actual principled setup works fine with most skins but it is intended to be manually adjusted by the user, because as you noted a good conversion from iray is not possible. In most cases it is enough to adjust the subsurface value to improve the skin.
-
reporter
This is not artistic. This is accurate to how the Uber shader handles skins but with a custom algorithm.
Iray does not have real subsurface scattering so it is faked with translucency and volumes. Translucency is meant for paperthin objects like leafs, not human bodies. So it uses the volume to consume light and keep it from passing right through. Every Daz character is essential a seethrough skin-shaped “leaf” wrapped around a dense fog. This is an awkward, unnecessary convoluted setup for a feature lacking from the engine.
We do not need to be faithful to the translucent step in Eevee because it cannot use volumes to “fog” the light enough it can’t pass through, seen in the rightmost image below.
And the principled shader does not have a translucent option anyway.
My node setup (for the diffuse and translucent) is the same the gamma node in the current implementation does (darken textures to a useable level), except driven by the translucency weight like the actual Uber shader.
Test with Rhonwen by iSourceTextures at 0.1 translucency and 0.5 translucency. Iray on top, default import in the middle, my custom setup on the bottom. In the default import the SSS value is changed directly to match the translucency weight, in my custom import the SSS value stayed at 0.3 and the translucency weight was only used to drive the texture darkening.
This was only meant to test the diffuse coloration, I didn’t focus on or removed gloss, normal mapping, etc.
Driving the subsurface with the translucent weight is not correct. At 0.1 (the default for this character), it results in unnaturally pale skin. But using my setup for diffuse and translucent textures results in more accurate skin tone to Iray. It does not reproduce the higher translucency (obviously) but again this is a hack in Iray for its lack of true SSS and not something we should or can replicate. We could expose translucent weight and subsurface amount individually for the user, but they should not be coupled. Or they should be coupled such that the translucent weight is mapped to subsurface within a limited, accurate range.
Eevee does make use of the radius value, you’re mistaking that for IOR and anisotropy.
I’m not a Python programmer, I barely know the Blender API, so I can’t help with scripting. But in all my tests using the translucent weight from Daz Studio with a value of 0.2 or 0.3 for subsurface was an improvement over the current option.
I’m mainly focused on converting the glossiness settings from Iray to Cycles BSDF so I don’t have time for deep, rigorous testing of this method. This is for the benefit of Eevee users, and I’m not one of them. Replicating the node network and using the translucent weight from Daz should be more than enough for the purposes of testing by others.
-
Below it’s eevee making use of the radius, it only follows the socket values. I agree on everything you say about iray and the principled shader, and indeed the limitations you point are what the actual design is based on. Since principled doesn’t support translucency we approximate it with sss. The sss value is the mixer between diffuse color and sss color that’s exactly what the translucency value does in iray hence the conversion. Then the iray volume is approximated with the gamma node (absorption) and the radius (scattering).
https://docs.blender.org/manual/en/latest/render/eevee/materials/nodes_support.html
Subsurface Scattering
Random Walk sampling is not supported. Per color channel Radius is specified by the default socket value. Any link plugged into this socket gets ignored. Texture Blur is not accurate for any value other than 0.0 and 1.0.
It may very well be that I miss your overall design and I see “spaghetti“ where you see otherwise. In your pictures you miss to compare with iray that’s everything that matters to show if something is better. That is, better is not “I like it more“, but it is “see it’s closer to iray“. Then without equations for the values it’s just a custom shader that the user needs to fix by hand. A conversion should at least provide a starting point similar to iray, that’s what the actual conversion tries to do.
In my post
#179 -
repo owner
Instead of changing the existing materials, we could perhaps make a dedicated skin shader. The general-purpose materials are needed for things that are not skins, and they should mimic iray as closely as possible, with warts and all. Textures and raw parameters are taken from the iray data, but a skin material could be optimized for Blender in ways that a general material can not. And we can already identify which materials are skin quite well; the plugin uses that to set the viewport color. I also think the official bridge has dedicated skin materials, or at least the first versions of it had.
-
I agree we can also use custom shaders for the principled option. Especially for skins (iray translucency + volume). What I point out it’s a custom shader is useless if we don’t have the input values for it, I mean it has to take some input values somewhere, then the user can adjust.
Or, if the custom shader is intended for no conversion but total user control/tweaking, then please make it an option. So users who want a conversion can use the conversion, and users who want a custom shader can use the custom shader.
note. important. But of course be aware that, if we start with custom shaders, then anyone can come out with his own “better version“ that he likes more. I mean there are a number of skin shaders for blender that are even better than iray. They are good but don’t convert the iray skin.
-
reporter
The current design is conceptually wrong. SSS is controlled by SSS Amount not translucency weight. Translucency weight drives the relative strength of diffuse and translucent textures to mask how much light enters the volume, it has no affect on the strength of SSS itself. Adding an HSV node and a Color Dodge node as shown above, to control the texture strength, is more accurate to how Iray works as defined it its MDL file. Instead of using translucency weight to drive SSS directly, a more accurate setup is modulating the translucency texture to simulate the multiplication of light values inside the volume and feeding that into subsurface color.
This is an autoconvert process to replace the current one. There is no need for inputs in Daz Studio. Load a figure with default materials, export, and reproduce the node network below. I recommend using an iSourceTextures character since they seem to benefit the most.
I’ve deleted the specular and bump maps for clarity and raised the specular amount to 0.66 to compensate.
The subsurface amount should be at 0.2 - 0.3. This is the appropriate amount for human skin. Putting a value of 0.1 is not accurate and produces much bluer results than Daz Studio (for iSourceTextures characters, mainly).
In Daz Studio, put any value into the translucency weight. Then put the same amount into the value node labeled translucent weight in the upper left corner. Compare the results. Aside from the missing translucency effect, the skin tones should match accurately.
-
reporter
This is an iSourceTextures character with the SSS turned as low as it can go (it’s bypassed if set to 0). The SSS Reflectance Tint overpowers the skin tone just as in the current Blender principled setup. The SSS amount is controlled by these parameters, not the translucency weight. Translucency weight affects the texture maps only.
-
As I understand it that setup can’t convert the daz skins in general. For one the skin is not granted to be pink and/or have a reddish sss/radius. It could be a fantasy figure with a green skin for example. That said, may be Thomas can implement the setup as an option so at least we can compare some skins with the actual setup.
edit. note. I want to stress that, though my vision can differ, personally I am very interested and grateful for your comments and insights, the passion you put in them, and your will to try to improve things.
edit. technical note for Midnight. I do understand what you say on translucency, but it’s not true. That is, we use sss as a mixer for the diffuse/translucency textures that’s the same iray does with translucency, then we compensate on the radius. For example with radius = 0 you get no sss but just a texture mixer. It’s not sss that gives the sss intensity, it’s sss * radius. This is also more realistic than using a small sss as you do, with sss = 1 you can use real word misures for the radius. The radius is the distance the light scatters.
https://docs.blender.org/manual/en/latest/render/shader_nodes/shader/principled.html
Subsurface
Mix between diffuse and subsurface scattering. Rather than being a simple mix between Diffuse and Subsurface Scattering, it acts as a multiplier for the Subsurface Radius.
Subsurface Radius
Average distance that light scatters below the surface.
-
reporter
@Thomas
Cycles is capable of (mostly) implementing the Uber shader features. I’m doing that in my own implementation. It would be no problem to create node groups for every “weighted” part of the Uber shader and daisy chain them as needed.
-
reporter
@ Alessandro
It’s a proof of concept for diffuse/translucent textures only, but it gives superior results for matching the translucency weight in Daz Studio for every figure I’ve tried it on. Though there’s room for improvement still, clearly.
-
repo owner
There is an experimental implementation in the last commit. The global setting Improved SSS (Experimental) decides whether this or the old method is used. It is only for the principled method, but I suppose that the same change can be made to the bsdf method as well.
Here are some comparisons, old method to the left, new to the right.
G8F
Victoria 8
Chiquita (iSourceTextures) -
Thank you Thomas for implementing the new setup so we can do comparisons and see what happens.
As a start I did a quick test with Evangeliya who’s a isource figure. The skin settings are odd since she uses a very low translucency and a “out of scale” transmission to compensate. An average human skin transmission is around 1 mm, so this skin is 20 times more transmissive, that means it is extremely sensitive to backlights. In these conditions the sss tint is left to the radius that in my setup is approximated and can’t handle all the cases.
But in my setup it is expected that the user may have to fix the subsurface value to fine tune the skin, as I also noted above. Because the principled skin is always an approximation, can’t be precise as the volumetric skin. And in this case just tuning the sss from 0.1 to 0.35 gives a good tint, so I believe it’s not bad and within the expected results.
note. This is not a comparison with the skin by Midnight, but just an explanation of the current setup, what limits to expect, and how to use it.
note. Thomas I noticed that both you and Midnight make comparisons as new vs old, without iray. Please note that a comparison without iray is meaningless since you can’t tell what’s the original skin tone.
-
reporter
@ Alessando
You’re incorrect. Transmitted measurement distance is the depth the light penetrates to. If you set it to 5cm the translucent color will glow through 5cm of skin (like an earlobe or nose). Past that distance, the absorption volume consumes the rest of the light according to an exponential decay curve to simulate light petering out as it loses energy.
Scattering distance is the depth of skin itself. Since it depends on the amount of light passed through the translucency color, it should probably be higher than normal human skin to compensate.
MDL’s volume struct takes a -1.0 to 1.0 direction and two colors for the absorption and scattering coefficients per meter of world space. The Uber shader uses distance as a scalar for the two color values (or the color value and the SSS amount in mono mode). Due to all the RGB multiplication required for the effect (including SSS reflectance tint and the translucency layer itself) I don’t think the distance will be “correct” unless you massively change the other parameters. It’s a delicate, convoluted system.
@ Thomas
As mentioned above, the SSS amount is a scalar for the depth in meters. So while it does control the SSS amount, it can’t be simply translated from meters in world space to a mix value on the Principled shader. I imported Modesta by iSourceTextures (who uses the same skin settings as Evangeliya) and she came in with 0.48. This is accurate to the Daz value, but results are too orange.
The SSS amount should properly be a scalar for the radius since it depends on size in world space. But due to Eevee limitations and in the absence of further testing, I found that remapping the SSS amount to 0.5 results in a “good enough” result for Modesta.
An Iray and Eevee comparison, SSS Amount 0.0 and 1.0.
Incidentally, the 0.0 Iray result demonstrates my earlier comment about transmission distance. The transmission distance is the point the skin turns the transmission color (blue). The purpose of that is to “nullify” the translucency color inside the volume, everywhere except the translucent parts. When the result is blended with the scattering it creates the SSS glow.
Here is a comparison test with Angharad 8 at the preset translucency levels, 0.6, 0.75, and 0.9. I disabled specular, bump, and top coat for both and remapped the subsurface value as I demonstrated above. Ignore the difference in the lips, I forgot to select the surface in Daz Studio.
Although the colors at 0.6 are largely accurate to Iray, they start to lose color as they approach 1.0. While this can’t be “fixed” since the principled option has no translucency, it may be that more color nodes are required to boost the translucent texture at very high weights.
The system also cannot handle total translucency. This isn’t a problem for skin, but for other materials it may be necessary to do conditional checks to disable SSS at 1.0 translucency and fake it with transmission/roughness instead.
-
@Midnight said
You’re incorrect. Transmitted measurement distance is the depth the light penetrates to. If you set it to 5cm the translucent color will glow through 5cm of skin (like an earlobe or nose). Past that distance, the absorption volume consumes the rest of the light according to an exponential decay curve to simulate light petering out as it loses energy.
Yes of course I know what transmission is. If you’re arguing that 5 cm or 2 cm transmission is good for the human skin then we simply don’t agree. As you very well explain and I agree: “transmitted measurement distance is the depth the light penetrates .. past that distance the absorption volume consumes the rest of the light according to an exponential decay“. Then in the human skin the light penetrates max 1 mm without any absorption, and that’s for the red rays that penetrate more.
Using a 5 cm transmission means the skin is completely “translucent“ up to 5 cm that would be a sort of “very transparent jelly“, not a human skin. You need infrareds to pass 1 mm transmission, and those wouldn’t cause any rendering effect because they’re invisible.
https://www.lightwavetherapy.com/learn/lightwave-therapy-principles/
Red light (wavelength 630nm-640nm) penetrates human tissue superficially, with approximately 80% of the energy being absorbed in the first 2cm.
-
repo owner
In the last commits I implemented the improved sss for the bsdf method as well. The SSS Fix group also reduces the sss amount, but clearly there is room for improvements. Perhaps the group should also depend on the sss color.
Midnight’s comment that iray skin is a leaf filled with fog made things fall into place for me. If iray does this, one can argue that the material should be a leaf filled with fog in Blender too. However, that is an awkward way to implement skin in cycles, so from that point of view it is better to convert skin to a solid with sss.
Another advantage is that we can finally get rid of the double links safely. There was always the risk that the fog would leak out of the leaf in eevee, which resulted in very obvious artefacts if people used the bsdf method with eevee.
Here are some examples with Victoria 8. Old method left, new right.
-
@Thomas, there is nothing new in what Midnight explains.
The “leaf” is translucency and the “fog“ is volumetrics. This is already implemented with the volumetric skin in bsdf mode, that does what iray does with “the leaf and the fog“. As for using the sss setup by Midnight in the bsdf option, or any sss setup for what matters, this way you’re getting rid of the volumetric skin that’s very bad because sss alone can’t do what iray does. This may be good as an option but can’t replace the volumetric skin aka “the leaf and the fog“.
What Midnight explains above, and I agree, is not that we can replace volume with sss, but that it makes no sense to use the bsdf option with eevee. Thus the dual output is not needed because you use bsdf for cycles and principled for eevee, That we discussed for a long time and finally you impemented the eevee bsdf options in the global settings to allow removing the dual output.
@Midnight said (first post)
Based on my preliminary results I think Eevee can be removed from the BSDF option entirely and the principled shader mode made to be its default.
note. I have yet to compare the sss by Midnight but judging from the images above seems very good so far. Will do some tests with different skins to understand where the limits are and in what they differ from the old sss.
-
repo owner
The volumetric skin isn't going anywhere. It is still an option (even the default although that may change), and is needed to reproduce iray. OTOH, it is not the way that skin shaders are usually made in Blender. If it can be approximated with sss, one gets a shader that is much more conventional. And it seems to reduce render time, although I haven't made extensive tests.
Eevee is not limited to the principled method. I don't see why one cannot render a bsdf tree with eevee, provided that it doesn't contain translucency and volumetrics. In fact, I have done so and am quite pleased with the result.
-
Because eevee has limits with the mix shaders the screen effects only work with the mix 0 channel as we already had to deal with. In general making extensive use of bsdf nodes is not good for eevee that’s rather designed to work with the principled shader. Unless you give up to the screen effects and use eevee in “opengl“ mode.
But it’s good for me to have options, this is just to explain things since you asked.
I agree the volumetric skin is not a good way to do skins and it is expensive. But it’s what iray does so we do the same it’s not possible in general to replace volume with sss.
-
reporter
@Alessando
“Using a 5 cm transmission means the skin is completely “translucent“ up to 5 cm that would be a sort of “very transparent jelly“, not a human skin.”
That is exactly how Iray handles subsurface scattering. It turns the nose and ears (about 2-3cm thick) into “translucent jelly” and layers the scattering effect over that to simulate light passing through skin. The transmission distance is (roughly) how thick bits like the nose and ears should be.
Again, see the Iray render of Modesta with the scattering set to 0 to see what I mean. Totally blue skin, the transmission color, except for the bits less than 2cm thick, which glow with the translucent color.
It’s totally backwards but that’s how it works.
@Thomas
“If iray does this, one can argue that the material should be a leaf filled with fog in Blender too. However, that is an awkward way to implement skin in cycles, so from that point of view it is better to convert skin to a solid with sss.”
I successfully implemented the volumetric method in Cycles, so it can be done. Though you’re right, it is very awkward, but it’s faithful to Iray and I agree it should stay that way for the Cycles BSDF method.
This SSS Fix isn’t necessary for the Cycles BSDF. This is just for Eevee and the principled method, one of which can’t do volumes and the other can’t do translucency, so trying to preserve the effect halfway is not optimal.
I outlined already the actual method the Uber shader uses to mix diffuse and translucent textures in the other post. I’m still waiting for a response to Alessando’s post on the Daz forums to share my actual implementation.
-
reporter
@ Thomas
Though I agree Eevee is better suited for the principled method, I’m not against it having a BSDF option either. I’m just against combining the Cycles and Eevee node networks and doing all sorts of confused routing because Eevee can’t handle half the things required. They should be split apart for clarity and the Eevee node network optimized for things Eevee can successfully do.
-
@Midnight
It’s not that I’m going on forever with this so this will be my last. In iray you can model things right or wrong. You can do a 1 mm transmission that’s the human skin, then scatter above. Modesta is not a reference the PA obviously doesn’t know what he's doing and uses a “out of scale“ transmission to compensate for the small translucency. Other daz figures luckily don’t, as Victoria 8 for example which uses more realistic values for the human skin.
-
repo owner
The double paths have been eliminated, and the materials either use translucency + volume or sss fix + subsurface scattering depending on the settings. This means that if people can render volumetric skin in eevee, and that fog will leak out. We shall see how many compaints we will get about that.
The last commits have been rather massive, so there is a risk that I have introduced new bugs, but I have tested with quite a few files and things seem to be rather stable.
I will be away on vacation the next week, so will only check in tomorrow morning.
-
Thomas have a nice week and good holidays. Thank you for your hard work and I hope I was not too much of a pita with all my comments.
Thank you too @Midnight for your insights it’s so cool to have you here. It would be amazing to have a conversion from mdl. Personally I don’t think we have to worry about a permission from daz to do that. Then Daniel Bui is going to ask for us but honestly I have not much hope in a reply.
-
note for @Thomas. Since we eliminated the dual output it is better to clarify the material options, to avoid a ton of complaints.
material method:
- BSDF (cycles) - tooltip: “Best iray materials, slow rendering, use bsdf nodes, works with cycles only.“
- Extended Principled (cycles eevee) - tooltip: “Limited iray materials, fast rendering, use principled plus bsdf nodes for extra features, works with cycles and eevee.“
- Principled (cycles eevee) - tooltip: “Extremely limited iray materials, very fast rendering, use only the principled node, works with cycles and eevee and helps exporting to game engines.“
As a side note, for the bsdf option we may keep the daz translucent group with the sss inputs. This way the user can turn on sss to make the bsdf option compatible with eevee, without the dual output. This could also be useful as an optimization to use cycles with fast skins. There could be a global setting for this.
global settings:
- BSDF SSS Skin - tooltip: “Use sss for skin materials, limited iray conversion but fast rendering, affects the BSDF option and also makes it compatible with eevee, though some screen effects may not work.“
-
repo owner
I changed the tooltips and rearranged the options a little. With the bsdf method there is an option Volumetric Skin, which selects either translucency + volume or Midnight’s SSS fix + SSS. With the extended and single principled the option Improved SSS selects between the SSS fix and a gamma node. Both options are available at load time when the material method is.
The old translucent group is now replaced by two groups: a new translucent group with the tranlucent node only, and an SSS group. It is controlled by the Volumetric Skin option.
-
Thomas welcome back I hope you had nice holidays. Here in Italy it’s just hot these days.
As for the new options I have a couple notes.
- I see no reason why the “volumetric skin” and “improved sss” are both in the global settings and on load. I mean the global settings are unuseful if you always have to specify it on load.
- The bsdf sss is always an “improved sss”, even if “improved sss“ is off. For bsdf we can use both the new sss and the old sss with the same settings as principled, using the gamma.
- For clarity we may want to use the same names, actually it is “improved sss“ for the option and “sss fix“ for the group. I would rather use the name “experimental sss” for both. See the note below.
- The “volumetric skin” tooltip doesn’t mention that the eevee screen effects may not work with the sss skin in bsdf mode. And indeed the eevee sss effect doesn’t actually work for the bsdf setup. That’s also why I suggested the “BSDF SSS Skin“ option instead with its tooltip.
note. The “improved sss“ is not extensively tested yet. I wanted to test first the mdl setups for translucency and volume, that didn’t work fine as expected and we’re working on it. The old sss is extensively tested and I know that if a skin tone doesn’t match it is enough to fix the sss amount. This is also what most daz users have learnt to do and there are tutorials and videos about this, and works fine. The “improved sss” is yet to be tested and “tamed“ in case of mismatch.
As a start the “improved sss“ uses the old sss radius that was not designed for the new values and thus doesn’t work with the new sss. A bad radius means a bad sss effect since it’s the sss amount + radius that gives the sss effect. The sss color or tint is another thing from the sss effect itself. The new sss focus on the tint but not on the sss effect. So see how well we tested it .. Please revert to experimental that’s what it is, and possibly change the name to “experimental sss”. Hope to get time soon to look at it.
-
Commit 1db4edf works fine for the “sss fix“ option.
But it doesn’t quite “understand“ the skin conversion. I prepared a simple test scene sss-skin.duf with three materials: skin, volume and translucency. Only the skin should be converted to sss, while volume should be volume and translucency should be translucency as usual.
Also the tooltip is not correct, it’s not translucency that’s replaced with sss but it’s the volumetric skin (translucency + volume) that’s replaced with sss.
Finally I really would use a global setting rather then another material method. Because another material method will make the user believe that this is, well, another material method. While this is not, it’s just an option to replace the volumetric skin with sss.
global settings:
- BSDF SSS Skin - tooltip: “Use sss for skin materials, limited iray conversion but fast rendering, affects the BSDF option and also makes it compatible with eevee, though some screen effects may not work.“
# use sss instead of the volumetric skin if bsdf sss skin == on if translucency weight > 0 and thin walled == off use sss instead of translucency + volume
edit. note. important. The above check for volume is a simplification. That is, iray makes no volume if distance is zero or color is black/white or there’s some transparency. If there’s no volume then it’s not a skin. Then a skin needs both scattering and transmission otherwise it’s a volume and not a skin.
# check for skin (uber version) skin = true if translucency weight == 0 or translucency color == black skin = false if cutout opacity < 1 or cutout opacity map != null volume = false if thin walled == on volume = false if volume == false skin = false if trasmitted distance == 0 or transmitted color == black/white transmit = false if scattering distance == 0 or sss color == black/white or sss amount == 0 scatter = false if transmit == false or scatter == false skin = falseedit. note. Then the volume conversion has to be improved but this is another issue we’re working on it in
#1075. -
- attached sss-skin.duf
Test scene for the sss skin. Includes skin, volume and translucency materials.
-
note. important.
I also see that the “extended principled“ method doesn’t import the volume in the test scene above. This is a bug, the bsdf volume nodes should be used same as for the other extra features. Then eevee will render the volume as a bounding box but his is a eevee limitation.
The “single principled“ option is fine to don’t import volumes since the principled shader alone doesn’t support them. So it’s within the intended limits for this option that’s mainly intended to export to games.
-
repo owner
The test for skin materials has been introduced, and volumetrics is used for non-skin.
There is a different way to test for skin that is used for setting the viewport color. It uses the material names if the mesh is one of the recognized genesis meshes, or it is a geograft material. That way also works well and may be preferable.
-
Commit e2434f8 doesn’t work.
The translucent cylinder is converted as sss. It has thin walled == on so skin = false as per the test above. It has to be converted as translucency.
As for the skin test by material name I don’t agree. The material conversion must be based on material attributes, not on material names.
As for having the sss skin as another material method I don’t agree as explained above. But if you want to keep it this way at least correct the tooltip. It’s not translucency that’s replaced with sss, it’s the volumetric skin.
“Uses BSDF nodes but the volumetric skin is replaced with sss“
-
repo owner
Fixed in last commit.
-
Commit ef979e6 works great. Thank you.
-
update. SSS DOESN’T WORK FOR PBRSKIN
As for commit a84ce55 the sss skin only works for uber and doesn’t work for pbrskin. We should do the same for pbrskin and replace translucency + volume with sss. The skin test is the same as above apart opacity that’s not supported by pbrskin. Please note that pbrskin can also be used without translucency and volume, so it’s not always a skin and we have to check. Please note that pbrskin can’t do volumes since it doesn’t support refraction, so it can only do diffuse/specular or skin or translucency.
Test scene included pbrskin-test.duf.
# check for skin (pbrskin version) skin = true if translucency enable == off or translucency weight == 0 or translucency color == black skin = false if transmission enable == off or trasmitted distance == 0 or transmitted color == black/white transmit = false if sss enable == off or scattering distance == 0 or sss color == black/white or sss amount == 0 scatter = false if transmit == false or scatter == false skin = false
steps:
- import pbrskin-test.duf with the sss option
note. Thomas, some users at the daz forum already got “confused” by the sss skin as a material method, it should better be a material option as suggested above. You may replace the button with a checkbox.
-
- attached pbrskin-test.duf
sss test for pbrskin
-
repo owner
The pbrskin should be handled correctly now.
-
repo owner
And now the BSDF Skin method is replaced by a global option.
-
As for commit ee3ee6c there’s a minor issue.
For the uber shader the single principled option converts translucency as sss, that may be viable since the translucent shader can’t be used with single principled. For the pbrskin shader the single principled option doesn’t convert translucency at all, that is, it is ignored and converted as diffuse, that may be viable as well as a limit of single principled since the principled shader doesn’t support translucency.
So it’s better to either convert both as sss or ignore both. Personally I’d ignore both since single principled doesn’t support translucency. But converting to sss to try to get something is also an option.
steps:
- import sss-skin.duf (uber material test) as single principled and check the translucent material
- import pbrskin-test.duf (pbrskin material test) as single principled and check the translucent material
-
repo owner
The single principled method now ignores translucency, except for volumetric skins.
-
Commit cc24949 works fine for translucency, but there's a minor issue.
For the pbrskin shader, if specular is off then it is converted as specular = 1 for the single principled option.
steps:
- import pbrskin-test.duf as single principled and check the specular channel
-
repo owner
Fixed in last commit. I notice that the pbrskin shader only has dual lobe specularity but not ordinary specular. Therefore the specular input is set to the dual lobe specular strength for the single method. For the extended method a separate dual lobe group is generated and principled specular = 0.
-
Commit 295b693 doesn’t work fine.
It only checks if specular weight is zero. But it may be that specular is off and the specular weight is one for example. If specular is off then the specular values have no meaning. We must check for specular on/off before checking the specular values. Same for the other channels in the pbrskin shader that get a on/off enable switch.
# pbrskin specular check if dual lobe specular enable == off or dual lobe specular weight == 0 there's no specular
-
repo owner
The plugin now check if dual lobe and top coat are enabled. I didn’t find any other unchecked channels.
-
Commit 8f96dbe works fine.
-
- changed status to resolved
This is implemented and there are no news.
- Log in to comment
A simpler way to use the specular map actually is just add 1.0 to the color output and put that into the fresnel node’s IOR value.