Problem with single Geoshell creating irregular white splotches, even after Merge Geografts

[Angel Eyes]

Hi guys.

First of all, many thanks to Thomas (Alessandro, engetudouiti, et al) for all your work in creating such an incredible program. I’d given up hope of Daz-to-Blender - after using official alternatives - until I discovered your project a couple of months ago. From my first import-and-render it was almost perfect.

Diffeo version: 1.6.0.0104 (but I’ve had the same issue with 1.5 and 1.51)

Blender: 2.92 (had same issue with earlier versions)

Included: basic .duf of a G8F with nothing changed/added except Breastacular Geograft/Shell.

‌

I’ve had a problem since I started using Diffeomorphic, that I’ve only recently become aware wasn’t down to oil effects applied to the body. Specifically I get white irregular splotches on the breasts when I use the Breastacular Geoshell, even after Merging.

This issue occurs even if I do no more than: create a brand new figure (default G8) and immediately apply Breastacular and it’s Shell (and apply a texture to the Shell); and then import into Blender and Merge Rigs/Geografts.

This Geoshell is using “Large Areolas” Addon, but something similar happens with the BA Geoshell “Headlights Textures”.

So it doesn’t seem related to mutiple Geoshells, etc. They happen in different parts of the breast depending on the model/breast sizing.

The above image is after import into Blender without Merged Geoshells. The discoloration around the areola is obviously expected, unmerged.

The below image is after Merged Rigs/Geografts. Most of the discoloration goes away, but the white splotch remains. It’s not a reflection (due to light source checks, etc)

Below is the same effect on another (more modified) model, this time at the top of the breast. The sharp, but jagged edges, illustrate it couldn’t really be the light source.

I’ve spent hours looking through the documentation, and searching the issues here, and I’m at a lose end as to how to solve it. I thought I could solve it with “Replace/Remove Shells”, but that seems to give an empty list these days; I don’t know if it’s deprecated. I’m sure I’m missing something obvious.

Any help would be greatly appreciated.

‌

‌

[Alessandro Padovani]

This was hard but I believe I got it. The test scene by Angel is not minimal and includes some assets that I don’t have so I made my own test scene btacular.duf including only G8F and breastacular and milkaiser. Where milkaiser is just extra textures that are needed to better show the issue since they use stronger bumps, and it’s also used in the test scene by Angel.

Recently we introduced a bump multiplier in the daz top coat group, to better mimic what the pbrskin shader does, see #349. Now it happens that the plugin uses the bump multiplier even for the uber shader, instead of the bump strength. Then honestly I don’t understand clearly why this is different, but it is. May be it has something to do with the texture conversion to displacement.

Below an example with the test scene btacular.duf. That’s the top coat inside the breastacular shell. The first example uses the bump multiplier, and strange reflections come out. Then the second example uses the bump strength, and everything works fine.

My understanding is that we have to use the bump multiplier only with the pbrskin shader, that’s what it’s for. While we have to use the regular bump strength with the uber shader.

‌

‌

‌

‌

That is, the pbrskin shader gets a bump texture + strength + multiplier, and here we use the bump multiplier in the daz top coat group. While the uber shader only gets a bump texture + strength.

‌

[Alessandro Padovani]

my test scene

[Alessandro Padovani]

I believe I got why the bump multiplier in the daz top coat group doesn’t work. It is because it multiplies normal + bump. That is, the result is not normal + (bump * factor), but it is (normal + bump) * factor.

So I’m afraid we can’t place the bump multiplier in the daz top coat group. We have to multiply the strength in the bump node instead. Below a simple test scene test.duf, it’s a plane with normal and bump maps. First iray, then cycles with the bump multiplier that’s a black image, then cycles with the multiplied strength that works fine.

Please note that unfortunately in iray the bump distance depends on the texture size, so it is different for 4K and 1K textures for example. This is a issue we never took care of. The actual 0.2 mm distance we use is good for 4K textures so G8 figures work fine. For the test scene I used a 2 mm distance since it seems good enough for 512x512 textures.

See the bump section below.

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

‌

‌

‌

[Alessandro Padovani]

test scene for the pbrskin bump factor

[Alessandro Padovani]

textures for the test scene

[Angel Eyes]

Alessandro, many thanks for the time you took to help me out on this. I really had no idea this was happening, and would have never solved it myself.

After reading your posts, removing the Top Coat Bump Weight for the BA Shell in Daz, before Blender import, worked perfectly. As I often import a model into Blender multiple times, it would seem the simplest, and best, solution (to alter it in Daz as above)?

‌

Incidentally, where do I find the Blender node group as shown in your first node picture (with Daz Top Coat->Bump set to 27.465)?

I’ve used your test file, and see that DTC->B of 27.465 setting in Daz, but I can’t find it anywhere after the import into Blender (when I don’t alter it). Not in any of the Torso-x groups (which Breastacular seem to use), or anywhere else I looked.

‌

Here’s one of the Torso node groups (the one with the BA UV Map), after importing your file, to illustrate. There’s a Bump setting of 0 in my Top Coat. And the Bump node seems unrelated.

‌

Finally, thanks so much for this. And sorry for being such a nuisance.

‌

[Alessandro Padovani]

The bump factor in my example is inside the breastacular shell, that’s the material cycles uses to render the shell. Just select the shell group and press tab to enter it.

Anyway this is a bug in the current material code and hope Thomas can fix it as explained above. Actually you helped to find the bug since I’d never look at it without someone reporting the issue. So thank you for your time.

[Angel Eyes]

Just select the shell group and press tab to enter it.

Awesome. Now I understand.

(I’d forgotten all about Tabbing into Nodes. )

Glad we could help each other.

[Alessandro Padovani]

Angel, this is not resolved since the code needs to be fixed. Please unmark.

[Thomas Larsson]

I put an extra bump node inside the top coat group, and linked the bump texture to it. I think that should be equivalent to what you wrote, at least in your test scene, and it keeps down the number of nodes in the main tree. Have to think about the uber shader, though. Perhaps the bump strength should be changed in that case.

[Alessandro Padovani]

The idea is good, but commit 56844af doesn’t seem to work fine. That is, the pbrskin gets a global bump that’s shared among different channels, then the top coat gets its own bump factor over the global bump. So the correct formula is:

top coat bump = base bump * top coat bump weight

While in the actual implementation the base bump factor seems not considered. In the example below the top coat bump must be 2.0 * 0.1 = 0.2, while now it is 0.1.

‌

[Thomas Larsson]

Implemented in last commit. Could you please check if it works in the uber case too. I have some test files, but I have forgotten how they were supposed to look.

The bump node inside the group will still be there even if the top coat bump strength is zero. Is this a problem? A normal map will pass right through it.

[engetudouiti]

Though I do not think all coversion may work about current mixing way of top coat, About bump , it is really good catch.

I actually did not notice the bump depend texture resolution. but actually daz iray bump take count texture resolution (pixel)

btw the strength ratio seems simply multiple with texture resolution.

I compare 600 pixel bump1 texture, and 2400 pixel bump2 texture.

To get same result, I need to set strength , multiple with 2400/600 for bump2 (2400) version. If current bump strength is best for 1K texture, when we use 2K texture, bump strength need to multiple with 2. if we use 4K texture it need to multiple with 4.

I expect, if Thomas auto adjust bump strength with current bump texture resolution when generate bump node. (Blender bump node get max bump difference as distance, so it seems not relate with texture resolution I suppose)

Or may better describe, about daz iray bump depend texure resoltuion. then for blender need to adjust it by user. at same time I may suggest, to get base strength value for 1k or 2k texture first to convert iray bump strength for blender bump node strength. (you may not test with weak skin bump but may better test with plane or cube etc,, it include pefect white and black pixel in image)

‌

[engetudouiti]

Then to convert iray strength, of course we need reverse circulation.

if current add on conversion do,

iray 1K bump = 1.0 >> add on convert it blender bump strength as 0.01 (I do not know how you circulate it though) work best to represent iray bump,

For material which set iray 4K bump = 1.0 in daz studio, >> add on need to convert blender bump strength as 0.01 * 1K/4K or we get more hard bump effect in blender than daz iray bump effect. (drastically change for detail bump too ^^;)

That seems reason, why we have different view, to convert bump map strength. (some times 0.02 work best or it should be 0.01 etc)

Add on have used same conversion formula to set blender bump strength, but it may need to change with bump map texure resolution

Then to get clear formula, I may expect, first get 1K map conversion formula. (or use current version conversion which you have used, then adjust it with bump map resolution which imported)

[Alessandro Padovani]

Thomas, as for the bump, commit e0dacbd seems to work fine both for uber and pbrskin.

Engetudouiti, I’d change the bump distance rather than the strength, the current distance seems to work fine for 4K. I’ll do some tests based on your idea to see if we can finally solve this issue.

Then for G1 G2 figures iray itself gives different results than 3delight, because iray can’t convert the 3dl min max, and this is why we had the bump tools in previous versions, that I suppose now are integrated in the material editor (never used it so far).

[engetudouiti]

I found one another thing we may need to consider .

blender bump node not change max normal height with geometry size.

so even though you change mesh scale,, it keep same max height as bump when we use same bump map. the max length only change with bump map node height and strength value.

But iray actually change with geometry scale. eg,, if you have plane, then change scale as 4. or simply generate new plane only change size as 4X. if we set same bump map, the max bump effect change with geometry size.

‌

‌

you can see the bump max height change with geometry size (1m to 4m) in iray then we may see same bump effect with geometry size ratio. (can keep clear bump) ,

but blender not change max bump height length. so when we scale the plane as 4X in blender , bump will blur (as ratio), but keep max height length of same bump. (so it not change with geometry scale) . it not change even though you apply scale. or simply apply same mateiral for new mesh (but geometry size change)

So I can not imagine we can get base strength to conversion. iray change bump max effect (height ) depend geometry size and resolution. but blender bump not change the max effect with geometry size. (nor resolution)

of course we can circulate it ,if we get base conversion formula only use for plane or simple cube with same UV map., (eg 1m plane with 1K map) but, I do not think we can get base strength value,, when we import different size meshes with different UV map.

it may change, with mesh boundary and how vendor make UV map ^^;

[Alessandro Padovani]

I may have a solution for the bump height, but it’s not easy and involves computing the surface area the same as we do for emission. I want to test it better before eventually publish a separate discussion for the implementation. It will take some time.

Meanwhile I believe we can mark this one as resolved.

‌