G9 Eyes Materials Incorrect

[Maneki]

It seems that in one of the newest daz importer iterations, that G9 eyes textures don’t get exported correctly.
The same issue appeared in the past, got fixed and now it’s back.

I tried it with multiple characters, HD and non-HD and all had the same issue. One of the characters I used was non-HD Michael 9.

‌

[Alessandro Padovani]

daz studio 4.21.0.5, blender 3.4.1, diffeomorphic 1.7.0.1452

Works fine here with the standard G9F. You have to use BSDF as material method, otherwise with principled you may need to fix something this is expected.

p.s. If you haven’t, be sure to update your G9 pack since eyes got fixed in december.

http://docs.daz3d.com/doku.php/public/read_me/index/86958/start

‌

[Maneki]

@Alessandro Padovani I use BDSF with SSS and I updated all G9 files. Blender 3.4/3.4.1, Daz Importer 1.7.0.1452

Standard G9 doesn’t work for me either.

‌

‌

‌

‌

[Maneki]

It looks correct in Daz:

‌

[Alessandro Padovani]

I can’t reproduce the issue. Tried your material settings and works fine here.

Test scene included let me know if this works for you. You may want to describe the exact steps how do you import the figure. May be there are some settings that cause the issue. I just imported with the standard import and rendered.

Tried easy import with merge materials and works fine too.

[Maneki]

I don' think it works correctly for you either. You used bad lighting but they look desaturated and white on your example too. They are supposed to look like the example above I posted lastly.
Here’s how your test scene looks for me in Blender:

‌

‌

And here your test scene in Daz:

‌

[Alessandro Padovani]

Please explain what you mean by bad lighting. My test scene uses the standard daz studio hdri that should import fine with the figure. Your renderings don’t show any hdri so you changed something. If you don’t have a background then reflections will not work in blender.

If the issue arises from a particular light set then it’s another story. You can attach a test scene in duf format with your light settings. Please keep it as simple as possible.

[Maneki]

Here’s your test scene with a increased HDRI intensity compared between Daz and Blender:

Daz

‌

Blender

‌

As you can see, the color isn’t even anywhere close. I don’t know why I can’t attach files but here’s a link to the adjusted .duf file you gave me:
https://mega.nz/file/VIZEADyT#jTsRlbvchlbmtTNQOyYUPt6o6a5Cc2uw2dhIS0muEkY
You don’t even have to use my .duf file, just increase the intensity of the HDRI or add some light and you will clearly see that the eyes are brown in Daz but not at all in Blender.

‌

‌

[Alessandro Padovani]

Ok I can reproduce the issue now with high hdri intensity, I used 10 instead of the default 2. At the default intensity the bug is still there but less visible.

bug for Thomas. Inside the LIE groups there’s this modulo thing that I don’t know what it is intended for. In this case it displaces the texture badly so it doesn’t appear in the right place and renders white. If I remove the modulo thing then the eye looks good.

Perhaps you can tell me what you want to do with the modulo so I may be able to help.

‌

[Thomas Larsson]

The modulo node is necessary for layered images if the UV tile is not the first. E.g., belowI imported a file with a heart layered on top of the torso. In this case we certainly don’t want to repeat the heart.

‌

‌

[Thomas Larsson]

d

[Thomas Larsson]

Here is the duf file with the heart and how it looks in DS. You will need to edit the file so it finds the heart texture.

‌

[Thomas Larsson]

heart texture

[Alessandro Padovani]

Ok now I understand it.

The modulo is a brilliant idea, essentially it automatically identifies the udim tile by the uv coordinates. This also allows to seamless integrate udim and non-udim textures, for example a face makeup over a udim skin.

In this case though we have a complex situation with the iris textures. I'll think about it and let you know what I find.

[Alessandro Padovani]

Ok I believe I got it.

The modulo is fine there’s nothing wrong about it sorry for the misunderstand I didn’t get what it is for. The issue is with the “Eye Translucency” LIE. If we look at the LIE in daz studio we see that the iris texture is positioned at zero, that means the top left corner. So in blender we should have XY = (0,0.5) since the texture is not squared.

Please note that the “Eye Color” and “Eye Normal“ LIEs are computed correctly with XY = (0,0.5). For some reason there’s a bug only in the “Eye Translucency“ LIE that’s computed XY = (0,0).

note. As a minor note the daz name for the LIE is “Eye Translucency 2“ while in blender it is “#Eye Translucency-3“. Don’t know exactly why this happens, but if possible it would be nice to have the same name as daz, possibly with a LIE prefix to remark it’s a LIE, such as “LIE Eye Translucency 2“.

‌

‌

[Thomas Larsson]

The image names end with 2 in DS, but they end with 3 in the duf file, but I don’t see where the name change happened. If one digs through the dsf files one can probably figure it out.

I’m confused about why the offsets come in as they do. Only the iris has a mapping node, because the iris image is rectangular 4096 x 2048, whereas the normal and sclera are square 4096 x 4096. There is no horizontal offsets because for some reason the same node groups are used in both left and right materials, and the left materials are made first.

In the last commit I sort of fixed the issue. If the image is rectangular a texture with mapping is repeated, otherwise it is clipped. It is probably possible to find cases where this heuristics fails, but for now it works with all tested cases.

‌

‌

[Maneki]

The eye color is correct now but there seems to be a issue with the shader, the iris is extremely noisy when light shines directly on it and it doesn’t really clear up during rendering:

‌

[Alessandro Padovani]

@Thomas

bug. No, if you use the modulo there’s no need to repeat, the texture must be clipped to avoid artifacts in the LIE as you noted above. It doesn’t matter if it’s square or rectangle.

I don’t get your confusion with left/right. I mean the LIE is the same whether you start with left or right doesn’t matter. Plus the color and normal LIEs work fine it’s only the translucency that has the bug, thus it can’t be a left/right matter.

Let me know if something is not clear.

edit. note. Only reason to use repeat would be if the texture is tiled, but this can’t happen inside the LIE there’s no option to tile a texture.

edit. note. As for the names I believe in the interface is used the name in the duf file, the last digit is probably added at runtime for some reason the same as blender adds digits for duplicates. So you may take the name in duf file and add a prefix for LIE as “LIE Eye Color“ for example. Of course this is minor.

‌

@Maneki

Try full global illumination in the cycles settings. Also if you use sss you may need to adjust the sss intensity since it’s heuristic this is expected.

edit. As for your comment below, if you set IOR = 1 you will have no reflection at all in the moisture.

[Maneki]

The cause of this noise seems to be IOR on the eye moisture shader. When I put it on 1.0 the noise is completely gone.

‌

[Maneki]

@Alessandro Padovani Full Global Illumination doesn’t help at all, ignoring the fact that it’s extremely inefficient to render having everything on a 32 value. The EyeMoisture DOESN’T have a SSS node, changing SSS of the eye itself doesn’t change anything in terms of noise for obvious reasons, it’s a different material.

[Alessandro Padovani]

Yes full global illumination is to test you have good enough settings. And sss was a general comment. If you can upload a test scene, as simple as possible, then I may be able to help. Or describe the exact steps to reproduce the issue.

p.s. Also you may try to use the magic words "please" and "thank you", it doesn't harm.

[Thomas Larsson]

OK, I think I got it now. There is a mysterious bug that clears the location of all mapping nodes. This has been around for a long time, and it is fixed by setting the location again at the end. However, if a material contains several mapping nodes affecting the same texture (several texture nodes in layered images) only the first is corrected. When I make sure that all mapping nodes are corrected the location comes out right.

To avoid dangling references mapping nodes are no longer pruned. We had a related bug not long ago. That should be handled better, of course.

[Thomas Larsson]

The node group names are changed to “LIE something-without-#”. The digit at the end is kept, since we don’t want to identify different node groups that start with the same string.

[Thomas Larsson]

Mapping nodes are pruned again. After they have been fixed, so no risk of dangling references.

[Alessandro Padovani]

Commit 8ed5eaf works great, thank you Thomas for your efforts on this one. Tested booth the G9 eyes and non-square LIEs.

Will wait for Maneki if he wants to give steps to reproduce and fix the fireflies, otherwise we may mark as resolved.

[Maneki]

@Alessandro Padovani I think it can get marked as solved. The “noise” is just the iris normal map which is pretty strong at a 1.0 value. I set it to 0.25 and it looks good.