Realistic Tears geometry shell is broken
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.
Comments (28)
-
-
repo owner 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.
-
repo owner - attached tears2.duf
- attached tears3.duf
-
repo owner 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.
-
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. -
repo owner 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.
-
repo owner 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.
-
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.
-
repo owner 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.
-
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
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#558to see the difference, both with bsdf and principled. Thus the option for refractive shells off is not much useful in my opinion.#558Below 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
setup. I suspect that happened for some reason when we removed the dual output.#558- 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.
- 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.
- Set the color space for the images in the LIE as linear.
- 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.
-
- attached tears.duf
test scene for refractive shells
-
repo owner I will be away tomorrow, will check this on Wednesday.
-
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:
- import tears.duf as extended principled
-
repo owner 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.
-
Commit 8e510d5 works great as for points 1 and 2. Thank you for the fast fix.
-
repo owner 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.
-
repo owner The simple subsurf modifiers are gone now, added render levels to catmull-clark instead.
-
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
#1082toward 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. -
-
Issue
#1312was marked as a duplicate of this issue. -
repo owner 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.
-
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
that distinguishes the equations between chromatic and mono.#1125# 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.
-
repo owner OK, I treated mono mode as the chromatic mode with grey color. In the last commit the scatter color = white if sss amount = 1.
-
As I can test it commit 3074e90 works fine, and also takes care of the “white/black“ optimization.
-
reporter 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.
-
The shell group has a influence channel that you can set to your preference, being 1 the normal value.
-
- changed status to resolved
-
reporter Finally got to test it myself, and so far everything is working as intended, thanks for the help.
- Log in to comment
Works fine here on a standard G8F but not on your test scene, will look at it and let you know what I find.