G9 white eyes

Issue #1820 resolved
Alessandro Padovani created an issue

commit 0833999, blender 3.6.5

It seems the recent commits introduced some bugs with materials. The G9 eyes are white when we reload the scene, plus there’s something wrong with the bsdf eyemoisture.

Commit 2e01cc8 works fine so this is limited to the new commits.

steps:

  1. in daz studio export the test scene g9-eyes.duf as HD
  2. import in blender as dbz
  3. save and reload the scene then render, the eyes are white

This seems due to some duplicated images that are discarded by blender after closing since they have no owner, also this way the LIE influence is set to zero when we reload the scene, it seems the influence driver gets confused by the duplicated images.

workaround: until this is fixed we can get commit 2e01cc8 that works fine.

https://bitbucket.org/Diffeomorphic/import_daz/get/2e01cc86f13720ac3c6df65656bcb6ee914ba452.zip

Comments (14)

  1. Alessandro Padovani reporter

    update.

    Nope, it seems commit 2e01cc8 still resets the LIE influence to zero, though it doesn’t have the bug with duplicate images and the bsdf eyemoisture works fine. So we need to set back the LIE influence to one when we reopen the scene.

    This bug is reported at the daz forum by goodwinds.

    https://www.daz3d.com/forums/discussion/657506/

    p.s. Please note that there’s no need to duplicate images whatsoever because we get srgb or linear from a gamma correction. Also duplicating images is not good because it takes double the memory, and that’s why we introduced the gamma correction instead.

  2. Thomas Larsson repo owner

    Images are occasionally duplicated in the pruning step, because pruning is done material by material but the color space belongs to the image and affects textures in other materials. Specifically I ran into the following situation.

    1. In the leg material, the leg specularity texture was used both as srgb and non-color. Therefore the texture remained srgb and the gamma nodes were kept.
    2. In the toenails material, the same texture was used only as non-color. Therefore the color space was changed to non-color and the gamma node was removed.
    3. But now the texture in the leg material was retroactively changed too, because the color space belongs to the image. So the non-color textures go were srgb is expected.

    If the toenails material comes before the leg material, the leg texture is changed to non-color even before the plugin considers it at all.

    Because of this, the boundary between the torso and leg became very visible. Duplicating the texture comes with a cost, but it rarely needed (this was the first time I encountered the problem), so I think it is acceptable. The alternative is that pruning cannot be done for a single material, but all materials have to be considered at once.

  3. Alessandro Padovani reporter

    Yes I understand the issue.

    A possible solution is to always load every image as srgb and eventually add the gamma correction for non-color if needed. This avoids duplicating images and it’s simple to design. The drawback is that non-color will always have the gamma node, but considering textures always srgb from source may make sense since image formats as jpg tga etc. are srgb.

  4. Thomas Larsson repo owner

    To be able to turn off layered images is a rather obscure feature. In the last commit it is controlled by a global option which is disabled by default. The influence slider is still present if this option is disabled, but it has no effect because the mix node inside the node group is not generated.

  5. Alessandro Padovani reporter

    commit 11ba53e, blender 3.6.5

    lie influence bug. Doesn’t seem to fix anything it’s the same as before, unless you mean we have to turn off the influence in the global setting as a workaround, but that has little sense we already have the workaround to set the influence to one by hand when this happens. I’m also not sure why we need to drive the influence, is it controlled by some settings in the material panel ? The culprit is probably the variable x that is set to zero when we reload the scene, the addon may check the x value at startup.

    bsdf eyemoisture bug. The bsdf eyemoisture is also bad and not fixed. This works fine in commit 2e01cc8.

    duplicated images bug. This is also not fixed, there are duplicate images that don’t need to be there and waste memory, especially for 4K textures. This works fine in commit 2e01cc8. A possible solution is to use a “daz image“ group providing the two outputs srgb and non-color with gamma, this way there’s no duplicates and pruning doesn’t need to change the color space. Also a “daz image“ group makes sense since the image editor in daz studio has various possible settings that we ignore by now but could be implemented in future.

    Let us know.

  6. Thomas Larsson repo owner

    The influence was driven by a property of the base mesh. When a HD figure is imported the base mesh is deleted by default, but the driver still worked because the mesh remained in the database. However, when the file is saved and loaded, deleted meshes no longer exist and the driver is bad. The fix is that the influence is driven by the HD mesh instead. This is not perfect, because if you import both base and HD and then delete the HD mesh, the driver is gone for the base mesh materials. But at least you have to do something active to trigger the problem.

    The normal textures were duplicated because the eye normal group was pruned twice, both for the left and right eye. Now the plugin keeps track of the node groups that have been pruned to make sure that they are only pruned once, and no new textures are created. Double textures are created in the case I described above, but that should be a very unusual situation.

  7. Alessandro Padovani reporter

    Commit b384db1 works great thank you for the fast fix.

    q. influence. It is not clear to me what the influence is driven for, can you explain please. I mean usually we want to change the influence by hand to adjust the effect, why is a driver necessary, what is it for ? Thank you.

  8. Thomas Larsson repo owner

    The primary reason is file linking. You cannot change material settings in a library override, but you can change custom properties, provided that they are declared to be overridable. Another reason is that the same property can drive the influence of several node groups, so you only have to change once. Although that could also be considered as a drawback.

    But one could make the driver optional. In the last commit there are two possibilities:

    1. The influence is driven.
    2. The influence cannot be changed but is always one. Or the influence slider is still there, but an mix node inside the group is not generated, so the influence is always one.

    To that one could add a third option:

    3. Keep the influence and the mix node, but don’t add drivers.

  9. Alessandro Padovani reporter

    bug. material overrides. Oh I see, this is a trick to make the material properties overridable, thank you for the explanation. But it doesn’t seem this works fine, that is, we can edit the material properties, but they are reset to the original value as soon as we save the scene.

    steps:

    1. link the object to a new scene and make it overridable
    2. change some material properties, eventually including the LIE influence
    3. save the scene, all the edited values are reset

    Personally I’m content with no overridable materials, that is, when I modify the original I expect all the links to update, but I don’t need to make local changes to the linked materials, also because if it was possible then the materials wouldn’t update with the original so this defies the purpose for link.

    Unless I miss something, please let us know.

  10. Thomas Larsson repo owner

    Material properties in a linked scene are greyed out and cannot be edited, but you can change the custom properties in the Visibility panel. Although the panel didn’t show up unless the mesh also had shells until the last commit.

  11. Alessandro Padovani reporter

    Yes that was what I couldn't understand, if we have a runtime control then it makes sense thank you for the explanation and the fix.

    Commit 2f52691 works fine.

  12. Log in to comment