Realistic Tears geometry shell is broken

[Viktor Vošček]

Hello,

I’ve recently wanted to use the Realistic Tears geoshell after some time, and it looks like there have been some updates to the Geometry Shell importing logic because this particular geoshell doesn’t transfer over correctly. Ultimate Skin Moisture imports as expected for example. (atleast to my eye)

I’m on the newest importer commit, Blender 3.0. I made sure to update the DAZ Importer scripts.

‌

‌

[Alessandro Padovani]

Works fine here on a standard G8F but not on your test scene, will look at it and let you know what I find.

[Thomas Larsson]

I have some similar files from last year, which still come in correctly. A difference compared to your file is that the alpha textures were inverted in the old files. Will investigate.

‌

[Thomas Larsson]

Alessandro, can you make something out of this. The only difference between Tears2 and Tears3 is that I removed the texture from Refraction Weight and put it to zero.

‌

[Alessandro Padovani]

Yes I will look at it and let you know. I can reproduce the issue but need to refresh my mind about the setup and understand why it happens. Eventually also comparing 1.7 and 1.6 to see if there’s any difference could be a recently introduced bug.

Reference is #558.

[Thomas Larsson]

The problem has something to do with how shells are mixed with the background material. The shell material in itself looks ok. We can inspect the material by setting Shell Method = Mesh (Debug) and then making a palette from the shell mesh.

[Thomas Larsson]

This is related to the special treatment of refractive shells, which I don’t understand. Opaque shells are straightforward: the shell is a new shader which is mixed with the incoming shader with a factor = influence * cutout opacity. Why can’t we use the same for refractive shells? It makes the problem in this issue go away.

[Alessandro Padovani]

I remember very little but for refractive shells we use the add shader so pbr rules don’t apply. Today I was away for christmas presents but should be able to look at it tomorrow. I agree that factor = influence * cutout opacity sounds reasonable unless there’s exceptions for some reason.

I checked the last version that works somehow is 1.6.1, while 1.6.2 was already buggy.

[Thomas Larsson]

I added a new global option for using the special refractive shells. If off, the group for opaque shells is always used. Unless we encounter problems with other shells, the special refractive shells can probably be removed in the future.

Here is the result of importing tears2.duf. Shell method = geometry nodes, shell method = material with refractive shells off and on.

‌

[Alessandro Padovani]

daz studio 4.21.0.5, blender 3.4.0, diffeomorphic 1.7.0.1323

Ok below it is what I was able to find, there are quite a number of unexpected issues so this took some more time.

1. REFRACTIVE SHELL BUG. Ignoring the refractive shells doesn’t work in the general case. As explained in #558 it can work fine enough only with bsdf if the underlying material is volumetric, otherwise it fails. Try ref-shell.duf and skin-shell.duf in #558 to see the difference, both with bsdf and principled. Thus the option for refractive shells off is not much useful in my opinion.

Below there’s an example with ultimate skin moisture imported as principled with refractive shells off.

‌

As for the refraction bug, it seems there are some modifications from the #558 setup. I suspect that happened for some reason when we removed the dual output.

1. There's a subtract node that must be removed, the influence is to be multiplied by the alpha and used as fac, I have no idea what the subtract node is for.
2. The transparent mix must be switched to channel zero, so that the alpha drives the refraction.

‌

note. If the subtract node is necessary for some reason, then we can switch the the glossy mix instead of the transparent mix, this will get the same final result.

edit. note. I see the subtract node is used for the generic shell, so that’s probably why it’s extended to the refractive shell. But we don’t need the subtract node, it is enough to switch the output mix instead to get the same result. Anyway, if it’s easier for the code, we can keep the subtract node both for the generic and refractive shell as explained above.

‌

2. LIE BUG. Another bug seems to be in the LIE. To compute the images we use srgb, then convert to linear with a gamma node when required as output. It turns out this produces different results than daz studio. It seems the images in the LIE are computed as linear, so we need to convert to srgb with a gamma node when required as output, rather than the opposite.

1. Set the color space for the images in the LIE as linear.
2. If srgb is required as output then convert with a gamma 2.2 node.

‌

3. DISPLACEMENT BUG. Another bug seems to be the displacement subdivision. It is odd that we never noticed it before, unless it's a glitch in my workstation.

For performance reasons we use a simple subdivision for the displacement. But it seems that blender doesn't smooth the normals for simple subdivision, so if the catmull subdivision of the figure is low then the displacement may reveal the base geometry. Below an example in blender with suzanne.

The solution is to avoid the simple subdivision and add up the displacement subdivision to catmull. Again if this isn't a glitch in my system that could also be the case, since we never noticed this before.

note. I guess the reason why we didn’t notice this before is because the issue only appears if the displacement covers small areas as in the tears case. If the displacement covers the whole surface then the base geometry is unlikely to be noticed.

‌

4. FINAL RESULT. Test scene included tears.duf, it's G8F with realistic tears. Below the comparison first iray then cycles. Please note that the fix for refractive shells works, but the makeup intensity is not the same. If we fix the LIE then we get the same makeup as iray. Then we also need to fix the displacement subdivision.

‌

[Alessandro Padovani]

test scene for refractive shells

[Thomas Larsson]

I will be away tomorrow, will check this on Wednesday.

[Alessandro Padovani]

5. PRINCIPLED SKIN BUG.

daz studio 4.21.0.5, blender 3.4.0, diffeomorphic 1.7.0.1323

There’s another bug. It we import the test scene tears.duf with the extended principled option, then some materials are imported as skin and some as volumes. The extended principled should import skin materials as sss and volumes as volumetric. The difference is that skins have both volume and translucency, as explained in #1082.

# skin test
if there's volume and there's translucency
    it's a skin

We see below that only the arms are imported as sss, while the torso and face are imported as volumetric. This doesn’t happen if we import G8F without the refractive shell, in this case the skin is correctly imported as sss.

steps:

1. import tears.duf as extended principled

‌

[Thomas Larsson]

The first two points have been addressed. The color space is set to Non-Color rather than Linear. This is a remnant from Blender 2.79 were the only color spaces where color and non-color, but if the difference to linear matters I could fix that.

‌

[Alessandro Padovani]

Commit 8e510d5 works great as for points 1 and 2. Thank you for the fast fix.

[Thomas Larsson]

The difference between the materials is that the torso and legs are thin walled but the arms are not. I assumed that a thin walled material is not a skin and therefore volumetrics was used for the torso and legs. Sort of backward. The new logic is that thin walled is unrelated to skin. So torso and legs don’t use volume because they are thin walled, and arms don’t use volume because they are skin.

However, the problem comes back with the bsdf method. Now the arms use volume, but the torso and legs don’t because they are thin walled. It doesn’t generate any visible difference as far as I can see, and the difference is obviously a mistake anyway.

‌

[Thomas Larsson]

The simple subsurf modifiers are gone now, added render levels to catmull-clark instead.

[Alessandro Padovani]

Commit 1d593ca works fine for the displacement subdivision.

As for materials there’s some confusion. The thin walled thing was by accident and have no idea how that happened, but we’re lucky it revealed a bug because thin walled must not be converted as volume. However thin walled is related to skin in that thin walled decides if there’s volume and volume decides if there’s skin.

All of this is covered in details in #1082 toward the end of the discussion where you can find pseudo code and two test scenes for the uber and pbrskin shaders, sss-skin.duf and pbrskin-test.duf. Please use them as test the actual commit doesn’t work fine.

[Alessandro Padovani]

note. REGRESSION.

I tested commit 8e510d5 (previous to the skin fix) with the sss-skin.duf test scene for materials in #1082 and it seems we lost the mono mode. The skin material in the test scene doesn’t look right because the mono sss mode is not converted. See #1125 for the conversion.

[Alessandro Padovani]

Issue #1312 was marked as a duplicate of this issue.

[Thomas Larsson]

In sss-skin.duf the sss amount = 1 which becomes a pure white scatter color. But both for absorption and scattering there is a condition that says that pure white = black. It must have been you who suggested it, because I never understood the logic behind it. If this condition is removed for scattering the sss-skin is skin-colored rather than grey.

[Alessandro Padovani]

Nope, “pure white” refers to the iray color for the chromatic mode. That is, both white and black in iray means no volume. This is also taken into account in #1125 that distinguishes the equations between chromatic and mono.

# iray volume
if transmitted color == white/black
    there's no transmission

# chromatic mode
if sss mode == chromatic
    if sss color == white/black
        there's no scattering

# mono mode
if sss mode == mono
    scatter color = sss amount

‌

edit. note. important.

It turns out that using the color log for the chromatic mode takes care of “pure white“, since log(1) = 0 so white is turned into black as we did before the color log. So there’s no more need of this condition, though it would be an optimization since we could avoid the color log in this case. Thus commit 7c2d2b0 works fine.

If nobody has anything to add we can mark as resolved.

[Thomas Larsson]

OK, I treated mono mode as the chromatic mode with grey color. In the last commit the scatter color = white if sss amount = 1.

[Alessandro Padovani]

As I can test it commit 3074e90 works fine, and also takes care of the “white/black“ optimization.

[Viktor Vošček]

Once again, thank you for the work and responsiveness, I’m currently away from my workstation so I can’t properly test it, I’ll get to it after new years.

My question would be, how would I increase the ‘intensity’ of the shell? (make it darker). From the screenshots it looks like the Blender interpretation is a bit lighter than IRAY, I’d like it to be a bit more dramatic in the final render.

[Alessandro Padovani]

The shell group has a influence channel that you can set to your preference, being 1 the normal value.

[Viktor Vošček]

Finally got to test it myself, and so far everything is working as intended, thanks for the help.