PBR Skin Causes Errors Together With Geografts

[Maneki]

I tested the headlights nipple geograft with 8.1 Female Base Skin and 8.1 Arcadia PBR Skin.
I can merge the nipple geografts with the body without problem using the base skin but as soon as I try it with PBR skins it causes this error:

‌

[Maneki]

Update: It seems to work with the more recent dev version 1.7.0.1354 where the changes to the material display didn’t happen yet so I assume that caused it.

[Maneki]

Update 2: It’s unrelated to the material display changes, it broke between 1.7.0.1360 and 1.7.0.1369 (.1360 still works for me).

[Alessandro Padovani]

daz studio 4.21.0.5, blender 3.4.1, diffeomorphic 1.7.0.1379

I can confirm the issue, specifically it is the “merge uv layers“ option crashing when we merge geografts, without works fine. I’m including a test scene with Victoria 8.1 and headlights.

note. It is to be noted that headlights is not updated to support G8.1 and the pbr skin, so we have to copy materials by hand in daz studio to make it work. But this has nothing to do with this specific issue.

note. important. for @Thomas, apart the crash, there’s also the bug #1343 that needs to be fixed. The geograft uv map is to be used if we don’t merge uvs, or we could always merge uvs when merging geografts. If possible please give this precedence together with #1343 #1337 so we have working materials. Personally I’d suggest to always merge and fix uvs when merging geografts, and group textures or at least have an option for that.

steps:

1. import the test scene v81-hl.duf and merge rigs
2. merge geografts with the “merge uv layers“ option

‌

[Alessandro Padovani]

test scene for headlights with pbr skin, it's Victoria 8.1 with headlights

[Alessandro Padovani]

fixed shell

[Alessandro Padovani]

update. Now commit cc6385c always crashes, even without “merge uv layers“.

[Thomas Larsson]

Crash fixed now. The problem had to do with mapping nodes, which V81 but not G8F has.

[Maneki]

Can confirm, it’s fixed now. By the way, is the diffeomorphic blog down?

[Thomas Larsson]

No, I can reach it right now. But that reminds me that I should make a new pdf copy of the posts.

[Maneki]

Alright, then it’s probably on my end, I’ll have to check that. Anyway, thanks again.

[Maneki]

Fixed

[Alessandro Padovani]

As for commit 8ad2d5b.

The crash is fixed, and works fine if we merge and fix uvs. But if we don’t then the “default uvs“ of headlights has to be used for the headlights materials because it’s no more the active uv when we merge. It’s the same issue that is fixed in #1343.

steps:

1. import the test scene v81-hl.duf and merge rigs
2. merge geografts without the “merge uv layers“ option
3. render

In general, after merging geografts, we have to check again what’s the active uv and eventually add uv map nodes to the geograft materials. Or, we can always merge uvs when we merge geografts. Or, we can leave it to the user and display a warning message if he doesn’t. As a matter of facts, the actual warning is unnecessary because the plugin is supposed to take care of it, the warning makes sense otherwise.

# after merge geografts check for uv maps
merge geografts
for every uv map
    if the uv map is the active uv map
        use texture coordinate to address it, no need for textures
    else
        use uv map to address it, including textures

‌

note. The easy option is to leave it to the user and display a warning, that’s the actual plugin behavior in commit 8ad2d5b. But in this case we have to reverse the fix in #1343, so the plugin behaves the same for G8F and V81.

[Thomas Larsson]

OK, another try. The problem was introduced after I decided to keep the texco node for mapping nodes. In that case it is replaced by a uvmap node, but that must also be linked to unconnected textures.

Does the mapping node also use the active uvs if the vector socket is unconnected? If so the texco node can always be removed.

[Alessandro Padovani]

This is not mentioned in the blender docs but yes, it seems a uv map node with no properties refers to the active uv and works with material preview. Please note that, if we specify the active uv as property for the uv map node, then the material preview doesn’t work anymore. So it must be with no properties.

So yes, we could use a uv map node with no properties instead of the uv output in texture coordinates. They both refer to the active uv and work with material preview.

note. Personally I believe texture coordinates is more clear to refer to the active uv, but I understand it is better to simplify the code when possible.

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

bug. As for commit 8b02b49 it works fine apart a minor bug. In headlights we have two geografts with displacement but for some reason only “headlight_r“ gets the displacement in the material properties, while “headlight_l“ gets bumps only.

note. important. Please note that displacement needs subdivision to work, so if we don’t check “subd displacement“ when we merge geografts then the displacement will not work even if we set it in the material settings. We could also remove the option and always do “subd displacement“ since the crash bug was fixed when we removed simple subdivision, see #1192. Or we could keep the “subd displacement“ option and make it effective. That is, when the user doesn’t check it he doesn’t want displacement for the geograft so we can prune the displacement map and use bump only. This also would help with eevee since it doesn’t support displacement.

‌

[Thomas Larsson]

The displacement setting was only set when the displacement node group was created, i.e. in the first material that used it. Fixed by setting it at the output node instead.

Question: Should the setting be Displacement Only or Displacement and Bump? Are the effect of any bump or normal map nodes lost if it is set to Only.

SubD Displacement is now turned on by default. I don’t want to remove this option because it can slow down rendering considerably, even if simplify is enabled and render subsurf levels is limited. I had two characters with similar skin (same vendor), but one had tears with subd displacement. The happy one rendered in 6 seconds and the sad one in 2.5 minutes, because the number of render subsurf levels went from 3 to 5. Simplify was enabled and max render subsurf was set to 2, but apparently it didn’t work.

[Alessandro Padovani]

Commit a0a546e works fine.

As for the displacement question, I find the blender documentation confusing myself. In my tests the bump map is displayed even if we set “displacement only“, and with “displacement and bump“ I get a longer render time and more memory usage without relevant improvements. So I’d stick with “displacement only“.

https://docs.blender.org/manual/en/latest/render/materials/components/displacement.html

‌

[Alessandro Padovani]

update. Ok now I understand what “displacement and bump“ does.

If we set “displacement only“ it works the same as iray, that is, the bump map is used for bump and the displacement map for displacement. If we set “displacement and bump“, then the bump map is used for bump as before, but the displacement map is used both as displacement and bump, this way more details come out even if the mesh is not subdivided enough.

So “displacement and bump“ sort of uses an extra bump map to display displacement information, that of course will be fake without actual displacement. This behavior is not what iray does but sort of “fakes“ displacement if we don’t have enough mesh resolution. But it costs extra memory and render time.

We may have a global option so the user can choose between “displacement only“ that’s what iray does, and “displacement and bump“ that fakes displacement with bump to compensate for a low resolution mesh. Or we may have a material tool to switch the two options.

note. Please note that, if the mesh is finely subdivided as is done in daz studio for HD figures for example, then “displacement and bump“ will not bring any benefit and will only cost extra memory and render time. This is also noted in the blender docs linked above.

@Thomas. Let me know what you think so I’ll close as resolved.

‌

[Alessandro Padovani]

@Thomas If you have nothing to add I’m closing as resolved.

As for commit a63d9e6 please note that blender can already copy and paste materials in edit mode, as also described in #1316. Unless you’re after something different.

‌

[Thomas Larsson]

The addition was prompted by the following problem. I had made quite a bit of work on a character when I realize that there were problems with the materials. I fixed it in DS and imported the character again. Instead of repeating the work, I just copied the materials to the old mesh and then deleted the new one.

[Alessandro Padovani]

This could be done with material palettes then, but it requires one more step so I guess this is a useful shortcut for the specific problem.

Marking as resolved.