better sss (experimental) and backgrounds

[Alessandro Padovani]

This is related to #17 and follows the same equations. The changes below include translucency effects from strong backlights that are not taken into account in #17. This is an improvement but still needs a lot of work to better match iray, so it has to be considered experimental and a work in progress. It is also possible to include the sss translucency as an option, possibly with a translucency factor so the user can decide to use it or not.

As for eevee the sss translucency must be enabled in the material settings and a better shadow precision than the default settings is required to avoid artifatcs. Below the required settings.

‌

‌

‌

‌

# same as no.17
# for principled sss
blender sss color = translucency color
blender sss scale = translucency weight

# same as no.17
# for bsdf sss
# here the mix factor is used instead of the scale to match the principled shader
blender sss color = translucency color
blender sss scale = 1
blender sss mix = translucency weight

# compared to no.17 this adds skin translucency effects
# for eevee sss translucency must be anabled and better shadow precision is required
# the transmitted color is responsible for translucency so it is added to the sss color
# an average 0.02 translucency factor is used because I'm not able yet to compute it from the iray volume density

# white or black colors disables transmission as well as scattering and sss radius goes to zero
if transmitted color == white then transmitted color = black
if sss color == white then sss color = black
if iray chromatic mode
    blender sss radius = (sss color + transmitted color) * 0.02
else if iray mono mode
    blender sss radius = (sss amount + transmitted color) * 0.02  # sss amount can be greater than 1
endif

Then below a comparison between the old sss and the new sss. The subject is Victoria 8 so it's a case where sss doesn't match. Nevertheless it's not too bad. Please note that the volumetric option always matches fine, we have issues with the sss option because it's generally not possible to translate volumes to plain sss.

First iray, then the old sss, then the new sss. Scene included.

‌

‌

‌

‌

[Thomas Larsson]

A first attempt has been committed. It is a bit sketch, because I’m off to our summer house and haven’t had time to check this properly.

1. The sss color/amount is multiplied with the scattering measurement distance. I add the transmitted color first, so (sss + transmitted)*distance
2. The transmitted color texture is ignored.
3. The new lamp settings are ignored so far. It is straightforward to implement them for lamps that are included in the duf file, but often the lamp and camera are already present in the scene.

‌

[Alessandro Padovani]

As for commit e0b7d12 below it's how it goes with the included test scene. You can see the artifacts due to the low precision for shadows. Basically eevee spreads the translucency around quite randomly and also has issues with shading since the translucency normals can’t be computed right.

I guess we could at least import the daz lights with the increased precision. Then may be warn the user for minimun eevee requirements if possible.

‌

Then once we fix the shadow precision the sss radius is way too short to produce any effect. I don’t have a good equation yet for the color and radius, but to work for the average character it should be in the 0.05 range that’s why I used 0.02 as multiplier since two maxed color components get 1 + 1 = 2 then 2 * 0.02 = 0.04 that may work fine enough for the average skin. Otherwise we get nothing as in the image below where I only fixed the lights.

‌

‌

edit. Of course the sss radius with eevee is compared with the results I get in cycles that I use as reference. That’s how I know a skin setting to be right or wrong. That is, first the skin has to be good in cycles, then I have to get the same result in eevee that’s how I found that the increased shadow precision is required.

As a side note to import the included test scene it is necessary to manually fix the background since the test scene uses scene only lights and the plugin doesn’t import the daz background color. Then it is also necessary to set the background ray visibility to camera only, since in daz studio the background color doesn’t light the scene, while in blender it does.

May be it could be a nice improvement to import the daz background as well if there’s not a hdri environment. This could be mainly useful for the scene only environment mode in daz studio where the hdri is not used.

‌

‌

[Alessandro Padovani]

there’s also an error in line 728 where the radius is computed it’s my fault I’m fixing the equations in the first post as well

radius = (sss + transcolor*0.02) * dist

should be

radius = (sss + transcolor) * 0.02 * dist

but I’d crop dist for the reason explained above

‌

[Thomas Larsson]

Last commit does most of these things, I think.

New lights get the suggested bias settings. There is also a bias setting in DS, but I ignore it since it typically is way too high. At the end, all existing lights are checked and a warning is issued if bias is too high. This behaviour can be changed in the Settings > Materials section.

Question: Does the bias depend on the units chosen. I suppose that all your numbers are for meters.

The SSS radius should also depend on units. Does 0.02 mean 0.02 m = 2 cm, or 0.02 cm = 0.2 mm, or something else? The current implementation assumes that it is 2 cm, but my renders look different from yours so probably that is wrong.

[Alessandro Padovani]

Thank you Thomas for the update. As I know it the default blender unit is meters and I should have it in my settings since I didn’t change that. So yes bias are affected and a 0.02 radius should be 2 cm that may seem a lot but that’s what I get working in my tests. We also have to consider that the uber shader works with volumes while the principled shader works with the subsurface so I guess there may be a different way to consider the radius effect.

I’ll share my default settings just in case so you could check them. Also if you could share yours I’ll be glad to check them as well. It’s odd that you get a different rendering result if you can show what you get may be it can be useful.

It may also depend on different import options. I use principled solid + principled refractive + sss volume with no automaterial so to get easy materials for eevee. And I import the scene with the cycles render engine active. Then once imported I first check with cycles to see what I get and work on the surface settings to do tests. Then I compare the results with eevee to check that they are similar.

I’ll check the commit as I get home and let you know what I find.

I’m using blender 2.83.2 lts and daz studio 4.12.0.86 until they fix the new release since 4.12.1.118 has serious issues with animation.

[Thomas Larsson]

Should work in all units now. Internally the plug-in uses cm which is the Daz default scale, and multiplies with a scale factor before setting Blender sockets.

[Alessandro Padovani]

As for commit 29a2604 it works better but there are issues.

issue 1) The daz background color is not imported if there’s no hdri as suggested above. So the user has to set it up himself. That's not a real issue but just a suggestion to improve the environment option for scene lights only. Please Thomas let me know if you plan to improve this otherwise I'll mark as resolved anyway.

issue 2) The shadow precision in eevee is fixed only for the bias while we also have to fix the distance and clip start as shown above. These values affect the shadow precision as well. Below the test scene first cycles then eevee. We can see artifatcs due to the low precision. May be this is the different result you were referring to.

‌

‌

Once we fix the clip start and distance as shown above and copied below, we get in eevee a similar result as in cycles. The global light threshold, size and bitdepth are also important for the eevee shadow precision. The plugin doesn’t seem to affect or check these values neither. As a very minimum the 0.001 threshold is required. Then the high bitdepth and the 1024, 2048 expanded sizes would be good to have but are less urgent, so feel free to include them in the minimum requirements or not. Personally I do use these settings as minimum requirements for my scenes when I work with eevee.

Of course these settings are useful for better shadows in general, not only for the eevee translucency.

‌

‌

Below eevee with the fixed precision.

‌

Also below my import settings for the included test scene if it may help.

‌

issue 3) I get a warning for the sun light even if I have no sun light in my scene.

‌

[Alessandro Padovani]

my blender preferences attached just in case if they may help for testing

[Alessandro Padovani]

As for commit 2638c05 issue 1 above is not implemented correctly. As explained above we have to set the ray visibility to camera only when importing the background color. Because in blender the background lights the scene while in daz studio it doesn’t. Please see the reference pictures in issue 1 above. Of course importing the hdri is different and we need the full ray visibility.

Also I see the plugin uses a rgb node to import the background color, that’s unnecessary since the color can be specified directly in the background node.

‌

Below an example with the included test scene using a green background, first iray then cycles. Also the imported background color is wrong. In my green example below it’s 0,255,64 in daz studio and 0,255,137 in blender. Please note that the background color in daz studio is gamma corrected so it needs to be imported as hex value in blender as shown in the image above.

‌

‌

‌

Then as for commit 2638c05 issue 2 and issue 3 are not fixed yet.

[Alessandro Padovani]

UPDATE. As for issue 1 I see commit 2638c05 also imports the background image if there’s one. That’s good but in this case we have to use the window texture coordinate so to fit the image to the rendering window the same as daz studio does.

‌

‌

Below the green example where I fixed the texture coordinates and the background color as explained above. First iray then cycles. Please note that both in daz studio and blender the rendered background is subject to tone mapping so there’s anyway some difference depending on the tone mapping settings.

‌

‌

[Thomas Larsson]

There was a lot of information to digest in this thread. The latest commit should address most of them, I think.

As for the sun light, it must be already present in your BLender scene when you import the Daz file. Lights in the duf file are updated silently, but the plugin warns about lights already in Blender that are insufficient.

Background images seem to be handled differently in Cycles and Eevee. If only the camera rays are visible, and there are no other lights in the scene, all objects are black in Cycles but colored in Eevee.

[Alessandro Padovani]

As for commit ca9baae it works almost fine. There are a copule of issues left.

issue 1. The background color is not gamma corrected. Again I have 0,255,64 in daz and 0,255,137 in blender. Please see above for the fix it has to be imported as hex value that's 00FF40 in my example.

‌

issue 3. I still have the warning for sunlight with no sunlight in the scene. I checked again and I have no sunlight in my scene it's empty when I import the daz scene. This is very minor though I guess we can live with it if it can't be fixed.

‌

issue 1.1. As you reported eevee doesn't get the ray visibility options so we have to do them ourselves for it to work fine. Below the eevee setup that uses the light path node. This is equivalent to what cycles does and also works with cycles so there's no harm using the same setup both for cycles and eevee, though in cycles there's no need because we have the ray visibility options.

Another option in blender is to add background pictures to the cameras but this doesn't seem to allow to multiply with colors. Plus it’s camera specific it’s not global so I guess using the background node mimics daz studio better.

‌

And below it is how it works, that's eevee with the background not lighting the scene. Here I also gamma corrected the background color. Of course when we import the hdri we need the full ray visibility so this is only required to import background images and colors.

‌

[Thomas Larsson]

Should be fixed now, except for the report about the sun light which I don’t understand. In my test file with the same (I think) green color it comes in as 00FF3E, which I guess that is close enough.

[Alessandro Padovani]

I know why it’s 00FF3E instead of 00FF40, it has to do with cycles vs iray linear conversions. Essentially for srgb colors defined in the duf file we should use the cycles function instead of the iray function. But I don’t like to complicate things unless necessary and I believe in this case we’re good enough.

Marking as resolved thank you Thomas for the fix.

[Alessandro Padovani]

changed title so I can find it better if needed