<<Make UDIM Materials>> changes color of Geografts

[Rob Inters]

Hello, Thomas and Alessandro. I went through the following articles:

https://diffeomorphic.blogspot.com/p/finishing-section-version-16.html

http://diffeomorphic.blogspot.com/2019/12/udim-support.html

Since these articles were published, Diffeomorphic has undergone some changes. I tried to follow the instructions in the articles and I also tried a lot of different approaches, but it always leads to color changes on the <<NGV8>> and also the <<Golden Palace>> Geografts. I'll outline my procedure below and hopefully you can point out the errors I make.

Blender 3.3.2

Diffeomorphic 1.7.0.1308

Workflow in Daz Studio:

1- Load Basic 8.1 Female

2- Apply the <<NGV8>> Geograft

3- <<export_to_blender>>

Workflow in Blender:

1- Import Character with <<Import Daz>>, Material Method <<BSDF (Cycles Only)>>

2- <<Merge Rigs>>

3- <<Save Local Textures>>

4- <<Set UDIM Tile>>

5- <<Merge Geografts>>

6- <<Make UDIM Materials>>

7- <<Merge Materials>>

‌

When I used my custom characters in earlier tests, only the Geograft color was altered; however, in the case of the Base Female 8.1, even the legs turn white.

‌

[Thomas Larsson]

This doesn’t have anything to do with geografts. The problem is that the G8.1F arms and legs textures are misnamed. The legs are on tile 1004 but the diffuse texture is called g8fbaselegsmapd_1003, and the arms are on tile 1005 but the diffuse texture is called g8fbasearmsmapd_1004. The plugin can only make udim materials if the textures are named correctly.

When G8.1F was released they added a new head material on tile 1002, and moved other materials one tile up. The textures for the torso materials was remade and named correctly (ends with 1003), but the G8F arms and legs textures were reused and kept their old names. Here are the udim materials for G81F and G8F. The arm and leg tiles are missing which causes strange things.

‌

[Thomas Larsson]

At the bottom of the advanced materials panel there is a button called UDIMs from Textures which I had forgotten about, but it apparently moves the UVs based on texture names. What we would need here is the opposite operation, a tool that renames textures to reflect the tiles they are on, so g8fbaselegsmapd_1003 => g8fbaselegsmapd_1004 etc. That should not be difficult to implement, but not tonight.

[Thomas Larsson]

Fixed in last commit. Make UDIM Textures now copies the wrongly name textures to the right folder and renames them.

[Rob Inters]

Thomas, I just tested it out, and while your most recent commit greatly improved the situation in my case, the Geograft still changes color. I now tried various workflows, and the following is one of them:

‌

Workflow in Daz Studio:

1- Load Basic 8.1 Female

2- Apply the <<NGV8>> Geograft

3- <<export_to_blender>>

Workflow in Blender:

1- Import Character with <<Import Daz>>, Material Method <<BSDF (Cycles Only)>>

2- <<Merge Rigs>>

3- <<Save Local Textures>>

4- <<Set UDIM Tile>>

5- <<Merge Geografts>>

6- <<Make UDIM Materials>>

Result:

‌

[Thomas Larsson]

I don’t see any problems in rendered view. However, there are problems in textured view. I got rid of those by merging the uv layers Base 8.1 Female and Base Female.

[Rob Inters]

Thomas, I completed it now with the addition of <<Merge UV Layers>>. I also tried it with and without <<Allow Overlap>>.

Although it has significantly improved, some areas are still white.

Workflow in Blender:

1- Import Character with <<Import Daz>>, Material Method <<BSDF (Cycles Only)>>

2- <<Merge Rigs>>

3- <<Save Local Textures>>

4- <<Set UDIM Tile>> to <<1003>>

5- <<Merge Geografts>>

6- <<Make UDIM Materials>>

Render Result:

‌

[Thomas Larsson]

I cannot reproduce this behaviour. However, the affected areas seem to be those covered by the geograft shell. Does the problem disappear if you turn down the influence of the shell node group to zero?

‌

[Rob Inters]

Thomas, I may have an idea why you are unable to replicate my problem. Before exporting, I make the following two changes to the NGV8 Geograft's Shell in Daz Studio:

1- Make the by default inactive <<New Genitalia For Victoria 8 - Color Layer>> visible.

2- Changing the <<glossy reflectivity>>, which is set to <<1>> by default, to <<0.3>>

Maybe if you make these two steps, your outcomes will be the same as mine.

And this is the result when I turn the influence of the shell node group to zero:

Except for the Geograft, the entire body turns white.

[Thomas Larsson]

For some reason I don’t have problems with the genitals material, but the white render shows up for the anus. There seems to be a bug with the Set UV Tile tool, so one must move the uvs manually in the UV Editing window. And then the uv layers must be merged. Here is what I did:

1. Move the NGV8 uvs 2 units in the x direction.
2. Merge Geografts.
3. Merge UV Layers: Base 8.1 Female and Base Female.

‌

[Alessandro Padovani]

Also be aware that blender ignores the face groups visibility of the shell, so be sure that it works with surfaces in daz studio before exporting. In most cases surfaces do fine but for some shells you may need to fix them.

note. In general it is not necessary to convert to udim, the daz figures work fine without, unless you have specific needs.

‌

[Thomas Larsson]

Now the Set UV Tile tool has been removed. Instead the Merge Rigs tool moves the geograft uvs to the right tile (based on texture names) before doing the merging. This means that all uvs should end up on the right tile automatically. Make UDIM Material now only has the option to copy and rename textures to fix the G8.1 bug.

Now the workflow is:

1. Save Local Textures.
2. Merge Geografts with Fix UV Tiles enabled.
3. Merge UV Layers: Base 8.1 Female and Base Female.
4. Make UDIM Materials with Fix Textures enabled.
5. Merge Materials with Ignore Bump Strength enabled.

‌

[Rob Inters]

Thomas, I just tested it on a few characters and everything works great now, except for one thing, and I should probably explain why I wanted to make <<UDIM Material>> and <<Merge Materials>> at this point.

An issue exists in Blender versions above 3.2.2, <<3.3 has skin map bleeding>> (Link: https://bitbucket.org/Diffeomorphic/import_daz/issues/1168/)

And Alessandro mentioned a possible solution in the <<issue 1168>>: “So you may be able to fix this by using udims and merging the body materials.”

And now, Thomas, with your most recent commit, Alessandro's solution to the <<skin map bleeding>> works great on the entire character except for the Geograft (see screenshot below)

To solve the <<skin map bleeding>> on the Geograft, I tried to <<Merge Materials>> in the <<Make UDIM Materials>> menu, I noticed the warning that says “some info may be lost” and indeed, the Geograft Materials lost all their details afterwards (see screenshots below)

‌

My question now is, Thomas and Alessandro, is it possible to <<Merge Materials>> of the Geograft and the Character so that the details of the Genitalia are preserved?

[Alessandro Padovani]

To avoid the volume bleeding a single skin material must be used for the whole figure. This essentially means driving the material with textures so udims can help. Unfortunately most geografts use a shell to blend the geograft material with the figure skin, in this case to get a single material you can extend the shell to the whole body.

long story short. It is a lot of work to fix the volume bleeding bug. Personally I don’t render 4K and I can easily fix the volume bleeding just by using the denoiser. For hi-res rendering the easy solution is to use blender 3.2 for the volumetric skin, or use the sss skin.

edit. note. Or another way could be baking the materials to a single uv map, that doesn’t need udims and should work for shells too, apart also optimizing the materials as a side effect.

[Rob Inters]

Alessandro, your suggestion: “in this case to get a single material you can extend the shell to whole body.”

Could you please look over what I did and let me know if this is what you meant?

1- Save Local Textures.

2- Merge Geografts with Fix UV Tiles enabled

3-Merge UV Layers: Base 8.1 Female and Base Female.

4- Make UDIM Materials with Fix Textures enabled.

‌

‌

5- So, next, I added both NGV8 shells to the <<Merged Material>> (in this case, <<Body-3>>), then connected them to a UV Map>> and added an <<Mix Shader>> at the end (see screenshot below)

‌

‌

I was very surprised that it works so well for the NGV8 Geograft, no more <<skin map bleeding>> and all the details are preserved (see screenshot below)

‌

‌

The issue is that I tested this <<Shader Setup Approach>> next on the <<Futalicious Geograft>> and it no longer works. (see screenshot below)

‌

‌

[Alessandro Padovani]

Yes that is what I mean. Since you have the body material as active when merging, then the shell is lost so you need to get it back. You may also try to set the geograft material as active that should do fine since the the geograft uses the body material. As for futalicious it looks like “fix textures“ doesn’t work for it, may be a bug for Thomas.

I’m not sure this method works for multiple geografts though, unless merge udims also does shells.

[Rob Inters]

Thank you for your suggestions and tips Alessandro. For characters with the NGV8 Geograft, I believe the <<Shader approach>> that extends the shell to the entire body from above works very well.

Thomas, if you think it’s worthwhile and you can make the <<fix textures>> feature more streamlined, so that it works well also for other Geografts like <<Futalicious>>, <<Dicktator>>, etc, I think it would provide a quick and simple solution to the <<skin map bleeding>> issue.

‌

‌

‌

[Thomas Larsson]

I tested G8F with futa and it seems to work here. Merge Geografts moves the UVs to the second tile, and Make UDIM Materials replaces textures with appropriately named ones. Could you specify exactly what the problem is.

[Alessandro Padovani]

daz studio 4.21.0.5, blender 3.3.2, diffeomorphic 1.7.0.1312

I can confirm that it works fine here. I can get a single material with the g8f skin and futalicious and the shell renders fine.

steps:

1. import g8f with futalicious, and merge rigs
2. save the scene and save local textures
3. merge geografts with fix uv + merge uv + overlap
4. make udims with merge materials and “shaft” as active, so you preserve the geograft shell

‌

note for @Rob. Please note that this way you get a single material driven by textures, so for example the lips and nails colors will be lost and replaced by the texture. Also in iray the bump strength depends on the texture density, so you will get different bumps for the face and torso for example. Apart these details merging the figure skin with the geograft works fine and can be a workaround for the volume bleeding.

note for @Rob. To make this work with multiple geografts you will have to merge materials by hand and add the shells, since make udims only allows for one active material.

“STACK SHELLS SUGGESTION“ FOR @THOMAS. You could make an option for merge materials to “stack the shells”, this way we could merge multiple geografts having the same base material but different shells, as it is the case using futalicious + headlights for example. Otherwise this has to be done by hand to merge the materials for multiple geografts.

[Alessandro Padovani]

“BLENDER 3.4 BUG” FOR @THOMAS.

If I try the same steps above with blender 3.4.0 then I get an error on step 4 when I make udims. While blender 3.3.2 works fine.

‌

[Rob Inters]

Alessandro, I just tested your approach from above on an <<Basic g8f>> with with <<Futalicious>> and it works.

However, I always use the <<Pumping Pole Palette>> on <<Futalicious>> and <<Dicktator>>

And after I apply the <<Pumping Pole Palette>> on the <<Futalicious>> Shell, your approach from above no longer works on my end; it seems the entire shell is applied to the entire body rather than just the Geograft (see screenshot below)

Thomas, My previous posts' problems were most likely caused by the <<Pumping Pole Palette>>.

[Alessandro Padovani]

note for @Rob. Not that I personally care but you may want to moderate your images since the tracker is not age restricted. There may be children around.

“MERGE GEOGRAFTS UV BUG” FOR @THOMAS.

Ok I see what's the issue here, looks like a bug when we merge the geograft.

That is, when we merge the geograft for some reason the whole figure is assigned to the shell uv map, and vertices that were not assigned get the zero location. This way the alpha map of the shell can't work fine because all the figure polygons are assigned to the zero pixel that could be any color depending on the alpha texture, in this case it's white so the alpha is solid on the figure.

The solution is to don't assign the figure polygons to the shell uv map when we merge the geograft. Only the geograft polygons have to be assigned to the shell uv map.

Or as a workaround the user can manually drag the zero points in a black area to make the alpha texture work. It seems until now we were just lucky that most alpha maps have a black pixel at zero.

‌

[Rob Inters]

“you may want to moderate your images” Oh, sorry, Alessandro, I hadn't considered it; I'll be more cautious in the future. And I also deleted or censored the images from previous posts.

[Thomas Larsson]

Things seem to work fine here. Problems only happen if I set the futa uvs as the active render uv layer, but that doesn’t make sense since the futa materials have a texture coordinate node that should pick up the default uvs layer. No crash in Blender 3.4, but I get lots of warnings in the terminal window about python context internal state bugs.

[Alessandro Padovani]

@THOMAS, things work fine until you merge udim materials. With normal materials the geograft has his own materials so the shell uv map works fine. With udim materials there’s a single material for the whole skin, including the body and the geograft, so the shell uv map may not work fine as explained above in “merge geografts uv bug“.

You have to follow the steps above to reproduce the bug. I’m including a test scene futa.duf that uses g8f + futalicious + pumping pole. But if you don’t have pumping pole you can just paint white the zero coordinates in the regular alpha map of the futalicious shell to get the bug.

https://www.renderotica.com/store/sku/57453_Futalicious-For-Genesis-8-Female

https://www.renderotica.com/store/sku/65521_Pumping-Pole-Palette-for-G8F-Futalicious

steps:

1. import g8f with futalicious, and merge rigs
2. save the scene and save local textures
3. merge geografts with fix uv + merge uv + overlap
4. make udims with merge materials and “shaft” as active, so you preserve the geograft shell (see the picture above for detailed settings)

edit. I can also confirm the “blender 3.4 bug“ as reported above. Again you have to follow the steps.

edit. Also please let us know what you think of the “stack shells suggestion“ as reported above that could be a solution for multiple geografts.

[Alessandro Padovani]

test scene for merge udim materials

[Alessandro Padovani]

UPDATE FOR @THOMAS. “BLENDER UV LIMITS AND WORKAROUND”.

It seems it is not possible to have some faces not uv mapped in blender. That is, when we make a uv map all the faces in the object must be uv mapped, and it is not possible to remove some faces from the uv map. This is why “merge geografts“ creates the zero uvs for the figure in the geograft uv map.

So, since we can’t delete the zero uvs, a workaround is to get them out of the uv map space and set the texture as “clip” instead of “repeat”. This way the zero uvs aren’t mapped on the texture.

note. This is to be done only when we use udim, since for normal textures the “repeat“ is needed to map the textures on the uv tiles, unless we “collapse udims“.

note. possible simplification. It is to be noted that shells are not affected when we use udiims, that is, even with udims shells still use the regular textures. Thus, we could always use the texture clip below only for shells, that should be fine both for udims and regular textures. This resolves the bug with a relative simple fix for shells.

‌

[Thomas Larsson]

OK, now I see the shell issue. The user could eliminate the shell for zero uvs with some extra nodes, like this. The node could be embedded in the shell group, I guess.

‌

I still cannot reproduce the crash in Blender 3.4.

[Rob Inters]

Thomas, If I follow Alessandro's steps, I can also confirm the "blender 3.4 bug," which occurs on step 4: “make udims with merge materials and “shaft” as active, so you preserve the geograft shell”

Python: Traceback (most recent call last):
  File "C:\Users\max\AppData\Roaming\Blender Foundation\Blender\3.4\scripts\addons\Diffeomorphic-import_daz-75ca627a2641\error.py", line 213, in execute
    self.run(context)
  File "C:\Users\max\AppData\Roaming\Blender Foundation\Blender\3.4\scripts\addons\Diffeomorphic-import_daz-75ca627a2641\udim.py", line 277, in run
    self.updateImage(img, basename, mat.DazUDim)
  File "C:\Users\max\AppData\Roaming\Blender Foundation\Blender\3.4\scripts\addons\Diffeomorphic-import_daz-75ca627a2641\udim.py", line 367, in updateImage
    copyfile(src, trg)
  File "C:\Program Files\Blender Foundation\Blender 3.4\3.4\python\lib\shutil.py", line 254, in copyfile
    with open(src, 'rb') as fsrc:
OSError: [Errno 22] Invalid argument: 'C:\\Users\\max\\Desktop\\Blender\\Daz Models\\Test\\Base8Futa\\textures\\original\\daz\\characters\\genesis8\\femalebase\\<_1002.jpg'

‌

‌

‌

[Alessandro Padovani]

Technically the nodes solution above is incorrect but practically it may work in most cases I guess.

That is, the zero uvs are generated by “merge geografts“ because in blender the uv maps must map all the polygons. So the shell uv map, that originally maps only the geograft, gets all the figure polygons mapped at zero. A zero uv is not a zero coordinate, it is a polygon with zero area and zero coordinates. So the correct workaround would be to select those polygons in the uv map and place them outside the uv map as explained above. Or we could also copy the shell uv map before merging to spot the added uvs.

If we mask out all the zero coordinates then there may be some polygons with some zero coordinates but a non-zero area that still need to be mapped. Though may be this approximation could work for most practical cases. I mean if implementing the correct workaround is too complex.

note. As for the “blender 3.4 bug”, if it’s only me I don’t care since I don’t use 3.4. We’ll see if someone else comes out with the crash.

note. Let us know about the “stack shell suggestion“.

@THOMAS EDIT. SOLUTION. IMPORTANT PLEASE READ.

Uh .. I didn’t consider that you actually move the shell uv map to the 1002 tile with “fix uv tiles“, so yes your node solution above should work and it’s quite brilliant, since moving the shell to 1002 we’re sure there are no zero uvs involved. But the fix should only be applied if we “fix uv tiles“, that will also add the relevant nodes to the shells.

note. In my opinion it should be made clear that “fix uv tiles” + “merge uv layers“ + “allow overlap“ are only needed for udims though, since normal textures work fine without.

note. In the nodes setup personally I would go with “greater than zero”, rather than 0.01, since we’re sure that zero uvs are at zero anyway. Not that it matters if the uv map is at 1002.

‌

[Thomas Larsson]

The Blender 3.4 bug should be fixed now. I tried on my work computer that runs proper 3.4 and not the Win7 version by nalexandru, and then it appeared. I don’t understand why it didn’t show up on my other computer, because it was a real bug that doesn’t seem os dependent.

That the shell uv map is moved is not something that I intended. It was a byproduct of moving the base layer and something that I thought of as a minor bug. The trick doesn’t work if the geograft is located on the first layer, i.e. a face geograft.

A node group that removes the zero uvs is added automatically in the last commit.

[Alessandro Padovani]

Commit 30f0564 works great here, both the “blender 3.4 bug” and the “merge geografts uv bug“ are fixed.

Please let us know of the “stack shells suggestion“ as reported below. Basically materials with same base layer but different shells could be merged with “merge materials“ by stacking the shells. This way multiple geografts could work with udims, that is now to be done by hand. Let me know if something is not clear I’ll try to explain better.

“STACK SHELLS SUGGESTION“ FOR @THOMAS. You could make an option for merge materials to “stack the shells”, this way we could merge multiple geografts having the same base material but different shells, as it is the case using futalicious + headlights for example. Otherwise this has to be done by hand to merge the materials for multiple geografts.

‌

[Thomas Larsson]

A stack shells option implemented in last commit. It seems to work rather well, but not always. E.g., for futa with PPP you have to exclude the glans material, but that should be ok since the glans is very different from the rest of the skin.

[Rob Inters]

Thomas, I tested it on a few characters, and it works well for the <<Base 8.0 F>> and <<Base 8.1 F>>, but I also tested it on a few custom characters, such as https://www.daz3d.com/araminta-hd-for-genesis-81-female and some issues arise.

My workflow:

1- import <<Custom Character>> + <<Futalicious>> + <<Pumping Pole Palette>>, and merge rigs

2- save the scene and save local textures

3- merge geografts with fix uv + merge uv + overlap

4- make udims with merge materials

Result:

‌

[Alessandro Padovani]

@Rob Stack shells is only needed for multiple shells aka multiple geografts, though it should consider the case with a single shell I guess. I tried Amarinta without stack shells and seems to work fine here. I merged materials before making udims to simplify the list, but should be the same.

Will test stack shells better though.

note. Also for G81 figures the futalicious shell needs to be fixed as explained above. The shell visibility must work with surfaces. This both if you use udims or normal textures.

‌

[Thomas Larsson]

Amarinta is a G81F character using G8F uvs and textures named for the G8F tiles. The Base 8.1 Female UV map is apparently not used anywhere, so if you delete it things should work.

‌

[Rob Inters]

The suggestion from Thomas worked very well, I removed the <<Base 8.1 Female>> UV map and everything seems to work now.

And Alessandro, I was thinking about what you mentioned earlier: “Please note that this way you get a single material driven by textures, so for example the lips and nails colors will be lost and replaced by the texture. Also in iray the bump strength depends on the texture density, so you will get different bumps for the face and torso for example.”

To avoid this, I simply do not merge the Lips, Nails, EyeSocket, and other parts that do not have the <<volume bleeding>> issue.

And, regarding the <<Bump Strength>>, did I understand correctly that you mean that before the material merge, the face and torso have different <<Bump Strengths>>, and after the merge, there is only one <<Bump Strength>> for all merged materials?

[Alessandro Padovani]

Yes, in iray the bump depends on the pixel density, no idea why daz did so in the uber shader this is total nonsense if you ask me. In cycles or any other engine/shader that I know of, the bump only depends on the bump parameters, as it makes sense to. So when you merge materials ignoring the bump you get the same bump parameters, thus different bump heights than iray. See #433.

As for keeping out lips and nails from the merge, this doesn’t avoid the volume bleeding if lips and nails use volume. But volume bleeding on the edge of lips and nails may be acceptable.

[Alessandro Padovani]

@THOMAS As for Araminta or similar figures, I wonder if the plugin could set the right uv map. Since in daz studio we have all the materials using the “base female” uv map as you noted, so this information should be available in the duf and the “base female“ uv map should be active in blender, instead of “base 8.1 female“ that is available but not used.

Let us know what you think.

‌

[Thomas Larsson]

This is done by the Purge UVs button, which is also invoked automatically when a file is imported. However, there were some bugs which prevented that this uv map was removed. Those are now fixed.

[Rob Inters]

Alessandro, thank you for your detailed explanations.

Thomas, I think I started encountering an error if I <<Merge Geografts>> after your latest commit.

My Workflow:

Character: https://www.daz3d.com/marybelle-hd-for-genesis-81-female

1- import <<Custom Character>> + <<NGV8>>

2- <<Merge Rigs>>

3- <<Merge Geografts>>

Error:

‌

[Alessandro Padovani]

note for @Rob. When providing a test scene or steps for a bug, you should try to stay as simple as possible. Use the standard G8F first, then use a custom figure only if the bug is related to that particular figure. Same for geografts try to stay with one, and switch only if the issue is related to a particular geograft.

Otherwise you make it harder than necessary to trace the bug, also we may not have some figures or geograft extensions.

[Rob Inters]

I got it Alessandro, I should have mentioned that I tested the <<Basic 8.0 + NGV8>>, <<Basic 8.1 + NGV8>> and they work well in the new Diffeo version 1.7.0.1319, Blender 3.3.2.

However, when I tried it on the custom character <<Marybelle + NGV8>>, I received the Error, Diffeo version 1.7.0.1319, Blender 3.3.2

I also tested <<Marybelle + NGV8>> in Diffeo 1.7.0.1314, Blender 3.2.2, and everything works fine there.

So I'm guessing it has something to do with the most recent commit.

[Thomas Larsson]

Which UV sets exist in your character? Since your have G81F lashes and tears, I assumed that Marybelle is a G81F character. Are they different from the UV sets for basic 8.1 and NGV8?

‌

[Alessandro Padovani]

Ok so it’s something in 1319 since 1314 worked fine. Thank you this will help @Thomas better. Does the error produce any artifact or is it just a warning ?

[Rob Inters]

Thomas, on the left I imported the <<Basic 8.1 + NGV8>>, on the right <<Marybelle + NGV8>> and opened the <<Object Data Properties>> panel (see screenshot below)

‌

[Rob Inters]

Alessandro, “Does the error produce any artifact or is it just a warning ?” Because the Geograft is being merged, and on the first glance, there are no Material/Color changes, so I assume this is just a warning.

[Rob Inters]

And Alessandro, I just tested it on <<Araminta>> + <<NGV8>> and she gets the same error; I believe you have this Character as well.

[Thomas Larsson]

OK, I can reproduce the problem.

[Thomas Larsson]

Should work for all cases now.

[Alessandro Padovani]

@Rob please don’t close this one as I want to test better the stacking shells.

[Rob Inters]

Just tested <<Merge Geografts>> and everything works great again.

‌

Regarding <<Stacking Shells>>, Thomas and Alessandro, I noticed that, for example, if I apply a different <<Labia Minora Color>> to the <<NGV8>> in Daz Studio (see screenshot below)

‌

After running <<Make UDIM Materials>> + <<Stack Shells>>, this new color/shell (e.g. “022 Pink”) won't be injected into the newly created <<Merged Material Shader>>. The Geograft will essentially only have its default color/shell (“023 (Default)Pink - Pigmentation”) applied to it.

[Alessandro Padovani]

I had a look at NGV8.

The reason why we lose the labia color layer is because stack shells has limits. That is, if the shell gets multiple materials then we have to choose one, because it’s not possible to have multiple shell materials with stack shells. This usually is not a big issue because a single material per shell is doable for most geografts.

As for NGV8 we see that it gets two materials with the same opacity map, so if we stack both materials then the last one will cover. In this case the plugin chooses the first material for the shell that’s the anus material, so we lose the labia color layer.

‌

One way to avoid this is to choose the material we want for the shell. That is, we have to merge the shell materials before stacking shells. For NGV8 we can merge the labia material to the whole geograft, this can be done in edit mode as explained in #1316: enter edit mode, then select the anus material, then apply the labia material.

If there’s nothing to add we may mark this one as resolved, since I have #1316 for further improvements.

note. important. For stack shells to work we need to choose one material per shell, this can be done by merging materials first. See the whole explanation above.

[Rob Inters]

Hello Thomas and Alessandro,

I've been using the "Make UDIM Materials" feature a lot recently, but it seems like it stopped working after the last changes made for the #1587 thread.

The Base 8.1 F + NGV8 is still working fine, but unfortunately, many of the custom characters that used to work before are no longer functioning properly.

To reproduce: 

Diffeo: 1.7.1.1636

Blender: 3.5.1

Link for custom Character: https://www.daz3d.com/marybelle-hd-for-genesis-81-female

Daz Studio Workflow:

1-Load Marybelle Character

2-Load NGV8 Geograft

Blender Workflow:

1-Merge Geograft

‌

‌

2-Make UDIM Materials

‌

‌

3-Result

‌

‌

[Thomas Larsson]

This actually never worked properly, but a recent commit made it more obvious. The character has two uv layers, Base 8.1 Female and Base Female. The former is the active uv layer but only the latter is used by the materials.

‌

NGV8 also has a uv layer called Base Female. That used to be merged automatically to the Base Female of the character since it has the same name. However, recently the geograft uv layers were renamed, to avoid that the Default UVs layers of NGV8 and headlights got merged. Then the plugin has to explicitly merge the geograft Base Female, and it merged it with the active UV layer which is Base 8.1 Female.

‌

The problem should now be fixed, like this. If the active uv layer is not used by any material, which is the case in this case, the Merge Geograft tool changes the active uv layer to the layer actually used. The uv map nodes are removed because they are no longer needed.

‌

The udim materials now look fine, as long as Base Female is active. The Base 8.1 Female uv layer can be removed.

[Rob Inters]

Thanks Thomas, Marybelle Character works again, although I tested a few other characters and there seems often to be a problem after "Make UDMI Materials", either the Geograft changes color or other body parts. It looks like there is not really a one in all solution which can be applied for all characters.

Here are the additional problematic characters I tested:

‌

Sharon + NGV8

Product Link: https://www.daz3d.com/sharon-hd-for-genesis-8-and-81-female

‌

Leona + NGV8

Product Link: https://www.daz3d.com/leona-for-genesis-81-female

‌

(NGV8 Geograft appear detached after "Make UDMI Materials")

‌

[Thomas Larsson]

Unfortunately I don’t have access to these assets, so I cannot test. But I can guess. There are two ways that you could have made Marybelle work even before the latest fix. This must be done before merging geografts.

1. Set Base Female as the active render uv layer (the camera icon is the important thing).

‌

2. Explicitly merge the uv layers with the Merge UV Layers tool. Allow Overlap must be enabled. This overwrites the active uvs with the Base Female uvs.

‌

[Thomas Larsson]

Let me explain what happens with the Marybelle character. Before merging geografts, we have the following uv layers:

Marybelle:
Unused: Base 8.1 Female
Base: Base Female

NGV8:
Geograft: Default UVs
Base: Base Female

The first uv layer is the active one, and we want to merge the base uv layers.

In version 1.7.0, the two base layers are automatically merged by Blender because they have the same name. Then we merge the geograft base layer (Base Female) to the active layer (Base 8.1 Female), and overwrite the original uvs. So we end up with two uv layers for the merged character:

Base: Base 8.1 Female with Base Female UVs
Geograft: Default UVs

In recent versions the plugin renames the geograft uv layers to make sure that all layers have unique names. After renaming, we have

Marybelle:
Unused: Base 8.1 Female
Base: Base Female

NGV8:
Geograft: Default UVs:NGV8
Base: Base Female:NGV8

Now Blender doesn’t merge anything by itself. After merging geografts, we end up with

Active: Base 8.1 Female + Base Female:NGV8
Base: Base Female
Geograft: Default UVs:NGV8

which is a mess. However, if we set Base Female as the active layer before merging, the result is

Unused: Base 8.1 Female
Active: Base Female + Base Female:NGV8
Geograft: Default UVs:NGV8

The last commit does that change automatically, but only if the active layer is indeed unused. In the terminal window, you should see a line like

New active UV layer: "Base Female"

‌

[Alessandro Padovani]

@Thomas Larsson , we discussed this some time ago. In my opinion the plugin should check for unused uv maps and delete them, then change the active uv map to the first material in the list. I mean just after loading, as a first step before generating materials. This is important also for material optimization, because in blender the active uv map is the default for textures and for the material preview.

As for geografts we have to always make as active the geograft uv map, not the shell uv maps. So if the shell uv map is default in the duf file then we have to change it. This is because the geograft will then be merged with the figure so the shell uv maps can’t be active.

# load scene

# uv optimization
check for unused uv maps and delete them
if there's no active uvmap for the object
    assign as active the uv map of the first material in the list

# geografts have to be merged, so keep the shells apart
if the object is a geograft
    if the active uv map is a shell uv map
        change the active uv map to the geograft uv map

# process materials

‌

[Thomas Larsson]

Yes, that is essentially what happens now, except that the unused uv map is not deleted, only deactivated. With your geograft uvs = my base uvs. However, I suppose that the main mesh can have several used uv maps, that are used by different materials. Then it is too difficult for the plugin to figure out what to do.

Renaming the uv maps before merging is essential, though. Consider the case of G8F + NGV8 + headlights, which makes total sense since the geografts don’t overlap. Then we have the following uv maps:

G8F:
Base: Base Female

NGV8:
Shell: Default UVs
Base: Base Female

Headlights:
Base: Default UVs
Shell: Headlights 

If we don’t rename uv layers, Blender merges G8F + NGV8 Base Female, as well as NGV8 + Headlights Default UVs. The latter is bad, because shell uvs are merged with base uvs. If we rename the uv layers, Blender itself doesn’t merge anything because the names are unique, and after the plugin has merged the resulting layers are

Base: Base Female + Base Female:NGV8 + Default UVs:Headlights
Shell 1: Default UVs:NGV8
Shell 2: Headlights:Headlights

The two shell layers can then be merged manually if we so desire.

[Alessandro Padovani]

As for daz objects using different uv maps for different materials, we can set as base uv the first material in the list.

Then yes for merging uvs in blender it is necessary to have the same name, thus it is also necessary to pay attention to names of uv maps we don’t want to merge. For this it comes handy to use prefixes for the geograft uv maps, since different geografts may use the same name for different uv maps, especially “default uvs“ since it is the default name in daz studio. Then we rename those uv maps we want to merge.

For geografts it is the bases that we want to merge, no matter the names, as final name we may use the figure base name.

If you already do all of this then any figure should work. Will test Sharon and Leona and let you know what’s the situation there and why they don’t work.

‌

[Rob Inters]

Thanks for the detailed explanation, Thomas. So, If I understood correctly, when importing characters with 2 UV maps, “Base 8.1 Female”, “Base Female”, we need to manually merge the UVs before moving on to anything else.

[Alessandro Padovani]

daz studio 4.21.0.5, blender 3.5.1, diffeomorphic 1.7.1.1639

Ok there are various issues.

1. bug. wrong active uv for geografts.

When we load ngv8 the active uv should be "base female" since this is the geograft uv map in daz studio. Instead the active uv is "default uvs" that's the shell uv map in daz studio. Also this way the materials are not optimized correctly since a uv map node is used for “base female“.

steps:

1. import ngv8

‌

2. possible bug. fix uv tiles doesn't work without udim suffixes.

Unfortunately for this you need Sharon, because it works fine with G81F. I suspect this happens because Sharon doesn't use udim suffixes for the texture names, so fix uv tiles can't work if it relies on them.

To fix this you may use the udims in the G81F base figure. I mean any figure based on G81 will have the same material names and udims, so we can get the udims from the base figure instead of the custom figure. We could store a udim map per base figure, instead of reading the suffixes from the texture names, that would probably be easier also for the code. If I'm wrong and this can't be implemented then we have to fix the uv tiles by hand in this case. Let us know.

Since this is a issue with uvs, I'm including the test scene. Even if you don't have Sharon may be you can reproduce the issue anyway, I mean you'll have missing morphs and textures but the uvs should not be affected and you can also see the missing texture names.

steps:

1. import the test scene sharon.duf as bsdf and merge rigs
2. merge geografts with fix uv tiles

‌

3. possible bug. fix textures doesn't work without udim suffixes.

Same as above, Sharon doesn't have udim suffixes so fix textures can't work when we make udims. Again the possible fix is to use udim maps per base figure. That means udims are identified by the material names instead of reading them from the texture names. Since all figures based on G81 have the same material names and udims. Same for other generations. Unless I miss something.

If this is not possible to implement then we have to fix textures by hand in this case.

steps:

1. import the test scene sharon.duf as bsdf and merge rigs
2. merge geografts with fix uv tiles
3. make udim materials with fix textures

‌

[Alessandro Padovani]

test scene for Sharon, textures don't have udim suffixes

[Thomas Larsson]

The first issue is fixed in last commit. When the G8F layer is set as active, the unused G8.1 layer isn’t even created anymore. I’m not sure why that happens.

Using a list of known materials should be doable if the tile is not implied by texture names. I need to think a little about that.

‌

[Alessandro Padovani]

Commit db12be3 works fine for the active uv, also materials are correctly optimized.

Or may be we can compute the udim tiles just by texture coordinates, without using material names nor texture names. That is, for example for the body material, we select the mesh by material then check the uvs. I can do it easily with the uv editor but don't know if it's doable by script.

‌

[Thomas Larsson]

Issue 2 should be fixed, perhaps also issue 3 but I didn’t find a good (or rather bad) character to test with.

To fix textures (issue 3) yes, we compute the udim tiles from the uv coords and use that to change the texture name.

Fixing uv tiles (issue 2) goes in the opposite direction. We use the texture names (and now also material names) to change the uv locations. In particular to move geograft uvs from tile 1001 to 1002.

Then a few assets have bad uvs, where the difference between the min and max values exceeds 1. The plugin writes a warning in the terminal in that case.

[Thomas Larsson]

Some more bugs have been ironed out.

[Alessandro Padovani]

Commit edfcec5 works great here, thank you Thomas for your excellent work as always.

Tested both Sharon and G81F with ngv8, now everything seems to work fine. Below there’s a couple notes you may want to consider, but they’re minor. Then if @Rob has nothing to add we can close as resolved.

1. stack shells. As noted in #1316 stack shells has limits it only works fine if we have one material per geograft. So we may want to have stack shell disabled by default and a warning about this in the tooltip.

‌

2. merge geografts. When we merge geografts we also have to merge the uv layers, this is mandatory otherwise we can’t merge materials. I know there’s a error message already but I’m wondering why we want to keep this as an option. When we merge geografts we should always merge uvs. Also allow overlap is mandatory for merge uvs to work as I understand it, should at least be checked by default.

‌

[Thomas Larsson]

2. Overlaps should not appear at all now, at least not when merging geografts (it can still happen if you merge uv layers explicitly). Overlaps used to happen because the meshes are joined using Blender’s built-in join operator, and that has the side effect that uv layers with the same name are automatically merged. But since all uv layers now have unique names, Blender no longer merges uv layers by itself. Every uv layer now have non-zero uv coordinates only for vertices that comes from a single mesh, and zero uvs for all other vertices.

[Rob Inters]

‌

Alessandro, I just tested Sharon and it works great now. However, Leona still has changes on the Geograft and Body after "Make UDMI Material"

‌

My steps:

‌

1-Merge Geografts

‌

2-Make UDIM Materials

‌

Result:

‌

‌

‌

‌

[Alessandro Padovani]

As explained above, it is not always possible to stack shells. And anyway stack shells makes sense only with multiple geografts. You may want to try without stack shells and selecting genitalia as active material.

I’ll check Leona and let you know what I find anyway.

[Thomas Larsson]

The previous commit broke Marybelle, this is now fixed. To determine the right tile, we must look at texture names first, and only if that fails use material names. The previous commit did the opposite. Since Marybelle has a material called Body, the plugin assumed that it has G8.1F uvs, and moved the genitals to the third tile rather than the second. This could be the problem with Sharon.

[Thomas Larsson]

The Leona situation is probably because the NGV8 uvs have ended up in the wrong tile, like what happened to Maribelle before the last commit. The plugin might not be smart enough to handle all cases correctly, but you can edit the uv coordinates by hand later.

‌

For Maribelle the body uvs are on the second tile, but the genitals were on the third. Select the genitals uvs (you can select vertices based on materials in the materials context) and translate them -1 step in the X direction. The shortcut with the Blender 2.79 keymap is G X -1.

‌

The genitals are now on the same tile as the body, and are no longer white.

[Alessandro Padovani]

I don't follow. As I understand it we don't have to "guess" to fix uv tiles, it is exactly known where we have to move the uvs to. We don't even need to look at material names or texture names for this, just at the graft uvs. Or let me know if I miss something.

# fix uv tiles
select the graft vertices on the body
look at the uvs to get the udim tile

‌

[Thomas Larsson]

No, the original geograft uv’s are located in the first tile. This is not a problem unless we make udim materials, since the texture extension is set to repeat. Have a look at the geograft uvs before merging them.

‌

[Thomas Larsson]

Ah, now I get what you are saying. We can look at the tile of the body verts that are masked by the geograft rather than the geograft tile itself. Yes, that should work.

[Alessandro Padovani]

Yes I know that. But we can look at the graft vertices to fix uv tiles when merging geografts as shown above. No need to guess with texture names or material names.

As for it not being a problem if we don’t use udims, that’s not entirely correct. It will be a problem if we want to merge materials or stack shells as explained in #1316. That’s why in my opinion when we merge geografts we should always merge uvs too. And why we added a error message if the user doesn’t.

[Thomas Larsson]

Implemented in last commit. Seems to work fine, at least G8F geografts end up on tile 1002 and G8.1F geografts on tile 1003. In principle we will run into problems for geografts which cover several materials and tiles, but that must be a very rare case.

[Rob Inters]

Thank you very much, Thomas, for explaining why the Geograft became white in the first place and how to fix it manually afterwards. Now, I think I understand how to fix it myself if it happens next time.

‌

[Alessandro Padovani]

Commit 7a32701 works fine to fix uv tiles.

bug. make udim. Something strange happens when we make udim with Leona. Other figures work fine. Again I guess this may be due to the texture names that in this case have the udim number but no underlines. What happens is that strange names are generated for the udim textures, for example “T_LeonaTorsoN 1001_1002.jpg.jpg”, but this is minor. The real bug is that in this case the color space is not preserved, so nomal/bump maps and specular maps are srgb instead of non-color, thus causing unexpected and unpleasant results in rendering especially for specularity.

Again I’m including the test scene hoping it can be useful to resolve the issue, even if you don’t have Leona. Let me know if it helps otherwise I’ll try to create a new asset from scratch to reproduce the issue.

steps:

1. import leona.duf as bsdf and merge rigs
2. make udim with merge materials

‌

[Alessandro Padovani]

test scene for Leona

[Thomas2]

Now texture names are normalized on import. If the last four characters indicate a tile (>1000 and < 1100), and the fifth last character is either “ “ or “-”, it is replaced by “_”. I cannot check that this fixes the issue since I don’t have the texture files, but the labels of the texture nodes now have names that should work for udim.

[Alessandro Padovani]

Nope, commit a9e7c1f doesn’t change a thing it’s everything as before. I managed to create a scene for you to test. It’s G8F wearing the Leona materials, the textures are resized to thumbnail versions so we don’t redistribute the Leona figure nor the 4K textures here, but that’s enough for test purposes.

You have to unzip and install as usual. It should work let me know.

[Alessandro Padovani]

test scene for Leona materials (now deleted)

[Thomas Larsson]

Leona should be fixed now.

[Alessandro Padovani]

Commit f24feab works great thank you for the fix. I have no other bugs to report here that I can see. I’m also removing the Leona test since it’s no more useful.

[Rob Inters]

Just tested Sharon, Leona, and a few other characters, and everything works great now. Thank you very much, Thomas and Alessandro.