weird geograft issue

[Alessandro Padovani]

tested with daz studio 4.12.0.86, blender 2.82a, plugin commit e66c482

This is related to #62 but I'm reporting it here for better handling. It seems the plugin can't import fine the realistic nipples geograft by DragiHadzitosic. Scene included.

https://www.renderotica.com/store/sku/61849_Realistic-Nipples

This asset gets a couple of specific features that we can see in the image below. First the shell uv map is named "Default UVs" that shouldn't be a problem anyway. Second the shell surface uses a diffuse overlay.

‌

Now when we import the asset in blender the shell uv map is imported fine with the name "default", that's a little odd since the daz name should be expected but it works fine anyway. But there's an issue with the shell material where the textures are not connected so they can't render.

‌

Plus, once we merge the geograft with G8F, the shell uv is lost.

‌

[Alessandro Padovani]

As for the daz “Default UVs” name, I see it is always imported as “default” in blender and this doesn’t generate issues. Below an example where I imported a scene with a couple of primitives. They both have a “default” uv map that works fine.

‌

[Thomas Larsson]

When the diffuse overlay weight = 1, it is mixed with a factor 1**4 = 1 with diffuse+translucent. When the mix factor = 1, the mix node is skipped and the second node (diffuse overlay) is linked directly to the next node. Is this not the desired behaviour?

The nodes that end in nothing should be pruned and not appear in the final material. Have to see why this does not happen.

[Thomas Larsson]

Daz assets usually have both a name and a label, which can be different. For the uv set, the name is default and the label is Default UVs. Changed to use the label instead. Some quick tests with multiple uv sets seem to work.

[Thomas Larsson]

Now I see that the diffuse overlay weight has a texture. This was ignored up til now.

[Alessandro Padovani]

Thank you Thomas for the fast reply. As for commit 008969c it's better but there are a number of issues.

issue 1. shell uv

The shell uv map in now named "Default UVs" the same as the daz label. This is not updated in the uv map node though that keeps the old name "default" thus the uv map is not found. I can change the uv node by hand to "Default UVs" that works fine.

‌

Also, when the geograft is merged to G8F the shell uv map is lost. That is, there is no more the shell "Default UVs" uv map that gets deleted, I can only see the G8F "Base Female" uv map in the uv list.

‌

Then if I look at "Base Female" uv map I see that the shell "Default UVs" was merged to "Base Female", the same as using the merge uv layers command that's normally used for eyelashes. So something goes wrong when merging the geograft.

‌

In this case I can fix the issue by hand by connecting the main texture coordinate node to the shell, thus bypassing the uv map node. But since the shells are intended to preserve their own uv maps I can't see any reason why this one should be an exception.

‌

‌

issue 2. shell diffuse overlay

Here there are a number of issues. Below the material in daz for reference.

‌

First in this case the overlay weight in daz is a jpg so it doesn't get an alpha channel. The plugin does some mess and uses the jpg alpha (that's black) as overlay weight, and the jpg color as texture for the overlay color. Plus the squared factor is ignored.

‌

The jpg color should be used for the overlay weight, and the overlay color has no textures in daz so it only gets the color. Below the fix.

‌

‌

issue 3. max bump strenght

I didn't notice before that the plugin limits the max bump strenght in the materials settings. I guess this may be useful in some cases but should be disabled by default. For example the realistic nipples have a 8.67 bump strenght and we need it for the bump to work fine.

‌

To limit the bump strenght in iray doesn't make sense since iray uses it to decide the bump value, having no mix max values as 3delight has.

Then it is true that in some cases we need to fix the bump by hand. This is because the bump distance that we fix to 0.5 mm in blender, really depends on the texture size as explained in the uber shader documentation. I didn't find a good equation yet so 0.5 mm works fine enough.

http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/interface/panes/surfaces/shaders/iray_uber_shader/shader_general_concepts/start

"Base Bump - The Base bump is set using a typical bump map. It works the same way as bump in 3Delight, but is dependent on the image map as there is no min/max value. When converting materials from 3Delight to Iray, the bump will need a higher value in Iray than the original material used. For this reason, the value slider has a range of 0 to 50.

The bump is fairly sensitive to both the pixel density of the mesh and the resolution of the image map. A typical example is the Genesis 2 Figure. The face is more dense than the head in number of pixels. If the head and face are set to the same bump strength, the figure will have seam lines where these two maps meet."

‌

final result

Below there's the realistic nipples in iray, then in cycles before and after the fixes above. Please note that there's still some difference in the nipple tint that I can't figure out where it come from. But overall it's good enough.

‌

‌

‌

[Thomas Larsson]

This was quite tricky, but I think I got it right now. Also tested with Olympia with green tranlucency and makeup, and that seems ok too.

Before the alpha channel of the diffuse overlay color that controlled the mixing. That was wrong, but it did not show for Olympia because both the weight and color channels had the same texture. Now there are two texture nodes for the same texture, with srgb and linear color space. Could the double power arise from using srgb when linear colors should have been used?

‌

‌

[Alessandro Padovani]

@Thomas I don’t think the double power can be replaced by the linear color but I’ll check it as I get home. Thank you for the fast fix.

[Alessandro Padovani]

As for commit d328a84 practically it works fine. There a couple of minor issues but they don't harm the rendering I'm reporting them here for completeness.

First the uv map of the nipples shell is lost after merging the geograft the same as before. But this time the plugin correctly connects the "Base Female" uv map to the shell so the rendering is ok. It doesn’t make much sense to use a uv map node since this way we have no extra uv maps but it works fine anyway.

I checked the roasty geograft and there the shells uv maps are preserved fine, so it seems this is an issue only with this realistic nipples asset.

‌

Second in the shell material it is generetaed a non-color texture for "Realistic Nipples Tex" that's not used and not pruned. Again this doesn't harm rendering. Again this doesn't seem to happen in other assets I tested.

‌

Please Thomas let me know if you want to investigate further otherwise I'll mark as resolved since the commit works fine anyway. As for the double power I can confirm it is necessary, the non-color data can't fix it.

[Alessandro Padovani]

Ok I believe I got it.

The geografts by Meipe always use two uv maps. For example in golden palace there's a "Default UVs" for the geograft geometry, and a "Golden Palace UVs" for the geograft shell. This is needed for the shell to blend-in with the character texture.

‌

Now when we merge geografts the plugin always merge the geometry uv map "Default UVs" with the uv map of the target geometry, and only lets the shell uv map "Golden Palace UVs" as extra uv map.

With the realistic nipples two uv maps are not needed because the shell uv map is "adapted" to fit the geometry uv map. So one single uv map is used both for the geometry and the shell of the geograft. That's "Default UVs".

So we may have two choices here.

(1) I believe merging the uv map of the geograft geometry may be a reasonable choice since we are really interested in the shell uv map. Plus the geograft geometry uses the textures from the base character so merging makes sense. But in the case where the same uv map is used both for the geometry and the shell then it should be merged for the geometry and preserved for the shell.

(2) As a better match to daz studio it would be more correct to preserve all the extra uv maps. So both the uv map of the geograft geometry and the geograft shell should be preserved. In this case for the material of the geograft geometry we can use the uv map node instead of the texture coordinate node.

‌

Personally I like more (1) because it makes things clean. But I have to admit that (2) would be more formally correct.

‌

edit. It seems using the uv map node instead of the texture coordinates disables the material preview. It works fine for rendering though. I don’t know if this is a bug in blender or it’s me missing something. This makes option (2) tricky though.

‌

edit. From a little search it looks more as a bug in blender. There’s nothing in the docs suggesting that it shouldn’t work in preview.

https://blender.stackexchange.com/questions/92546/uv-map-node-not-working-in-preview

https://docs.blender.org/manual/en/latest/render/shader_nodes/input/uv_map.html

[Alessandro Padovani]

edit. Of course option (3) is to leave everything as is and when there’s a single uv map it gets merged. Not too “polite” but it works anyway.

Again Thomas please let me know what you plan to do, I can mark as resolved as it is.

[Thomas Larsson]

The last commit removes uvmap nodes whenever possible, and link from the texture coordinate node instead.

A long time ago, before the uvmap node existed, the plugin used an attribute node for all uvmaps. That was discarded because of problems with material preview. I think it was you who pointed that out.

I don’t understand why the extra texture node is not pruned, but I do understand why it was created, and it isn’t anymore.

[Alessandro Padovani]

I see commit f692e23 goes for option (3) that’s fine for me. The extra texture node stills there but it doesn’t harm.

Marking as resolved.

[Alessandro Padovani]

Tested with commit 959cd39.

As for the diffuse overlay the plugin is back using the alpha channel for a jpg image. That doesn't exist. I don't know if this is a regression but it seems to me that we both checked last time. The G8 makeups use a png and there the alpha is fine.

‌

‌

[Thomas Larsson]

The problem is that I haven’t found a good way to determine whether an image has an alpha channel or not, cf the documentation at https://docs.blender.org/api/2.82a/bpy.types.Image.html. The plug-in used to check alpha_mode, but could evidently go wrong. Now I check the file format; if file_format = ‘PNG’ the alpha socket is used, otherwise the color socket. This may solve the problem in this case, but does not feel like a good solution, since there are png files both with and without a separate alpha channel.

[Alessandro Padovani]

Commit 10721c7 works fine both for jpg and png with alpha. I guess we need to check png without alpha but marking as resolved for now, since both the G8 makeups and the realistic nipples work fine.