New Diffeo Version deforms NGV8 Geograft
Issue #1587
resolved
Hello Thomas and Alessandro,
I believe I have found a bug in the new Diffeo Version. When the "hand.ik.L" is moved in "Pose Mode," it causes deformation in the NGV8 Geograft.
Tested with the following versions:
Blender 3.6.0 + Deffeo 1.7.0.1314 (everything works fine)
Blender 3.6.0 + Deffeo 1.7.1.1617 (NGV8 deforms)
Steps to reproduce:
-import Daz: Base 8.1 F + NGV8
-Merge Rigs
-Select Character Mesh and import Standard Morphs
-Select NGV8 Geograft and import Custom Morphs
-Select Character Mesh and import Custom Morphs for NGV8
-Transfer Shapekeys from Character Mesh to NGV8
-Merge Geografts
-Convert Rig to MHX
-Now if the “hand.ik.L” is moved in “Pose Mode” the NGV8 Geograft deforms.
Comments (49)
-
-
- changed status to open
-
reporter
Just tested out Blender 3.5.1, and yes, Alessandro, the problem remains the same.
Blender 3.5.1 + Diffeo 1.7.0.1314 (everything works fine)
Blender 3.5.1 + Diffeo 1.7.1.1617 (NGV8 deforms)
-
This sounds related to
#1530.As for custom morphs it is quite easy to make a mess though, you have to know exactly what to import and what not otherwise there may be issues, see the notes in the wiki. It may be that Thomas did some changes and now errors are more visible, not that they weren’t errors before. Anyway we can wait for Thomas to look at this and
#1530.Meanwhile I’d suggest to use easy import with baked correctives and daz favorites, that’s the new easy way to deal with custom morphs.
https://bitbucket.org/Diffeomorphic/import_daz/wiki/Import/Easy Import DAZ
-
reporter
Alessandro, regarding your workaround, as you mentioned in
#1530, the "anus open" morph doesn't get imported with DAZ Favorites.
I also tested the morphs from the "ZExpansion Morphs For 3feetwolf's New Gens V8," specifically "Anus Gape Height" and "Anus Gape Width," which I thought could serve as an alternative. However, they also are no longer functioning correctly. Here is the Renderotica product link: https://www.renderotica.com/store/sku/60323_ZExpansion-Morphs-For-3feetwolf-s-New-Gens-V8
Thomas, if you should find a bit of time, could you please look into this issue, because right now the NGV8 Geograft is not really usable anymore.
-
repo owner
It appears that there is some problem in the merging step if there are non-zero shapekeys. I could trigger the behaviour by converting to mhx and posing the left hand before merging geografts.
By default the morph 0000-InitialGenitaliaShape = 1. Merging the geograft in this case deforms the mesh.
If we instead turn off the morph, merge the geograft, and then turn it back on again, everything seems to work fine. The plugin should do that automatically, but I don’t have time to check that today.
-
I’m not sure to follow .. aren’t non-zero morphs imported as baked ? In this case it is a user error to import them as custom since they’re already in the dbz. That’s why using baked correctives and daz favorites is much easier because it avoids these complications.
Unfortunately daz favorites don’t seem to work either with NGV8, see
#1530. -
repo owner
The morph loader doesn’t check if the morph is baked, but it should. As you can see in the top picture above, the vagina is deformed already before merging geografts, presumably because the shapekey is duplicated, both baked and loaded. But I am not sure that we can just skip the baked morphs, since you might e.g. want to use it with negative values to undo the baked shape. Anyway, baked morph should be set to zero when loaded.
-
I agree. As I understand it custom morphs is intended as an advanced tool that allows to do anything and it is the user responsibility to use it properly. Otherwise there may be issues as in this case. For “common“ users not so technically inclined there’s baked correctives and daz favorites.
-
repo owner
The bug should be fixed now. When reimporting an already baked morph, its value is set to zero irrespective of the value in the daz file. However, this didn’t turn off the double NGV8 morphs, so I also added a list of morphs that is always treated as baked; currently the only item in this list “CTRLInitialGensShape01”. Not very elegant, but we can easily change the morph value if we want to. With that morph set to zero, there doesn’t seem to be any problems when merging the geograft.
Note that the associated G8F morphs only work correctly if you import morphs with Use Suffix = “None”. If we use the default “Geograft” the geograft properties that drive the G8F morphs don’t have the right names.
-
Commit 67d4a0b.
Still “anus open” doesn’t work with daz favorites, please let me know if this is an intended limitation so I can add a note to the wiki. Test scene included ngv8.duf.
steps:
- easy import ngv8.duf with daz favorites and merge geografts, use suffix = none or whatever
- check the morphs, “anus open“ doesn’t get loaded, not even if we set “make hidden sliders“ in the global settings
-
- attached ngv8.duf
test scene with "anus open" as daz favorite
-
repo owner
Hm. That is not easy to fix, unless we want to scan all NGV8 morphs. The plugin uses the file names to guess which files to load. This often works well but there is no guarantee that the file name reflects the content.
Here is what happened. The info in the duf files only consists of the line:
"favorites" : [ "0104%20-%20AnusOpen" ]The plugin therefore looks for a file with the name "0104 - AnusOpen", but no such file exists. Instead it would need to import at least two files:
- "alias_new_gens_V8_1840_0104- AnusOpen.dsf" defines a visible property with name "0104 - AnusOpen", label "0106 - AnusOpen", and target channel "PBMG8FAnusOpen".
- "PBMAnusOpen.dsf" defines the actual shapekey and a hidden property with name "PBMAnusOpen" and label "PBM AnusOpen". This property is driven by "PBMG8FAnusOpen".
- We should probably also import "PBMG8FAnusOpen.dsf" to the body mesh.
I don't see how the plugin could figure out these relations without scanning all files in the NGV8 directory. That could perhaps be acceptable in this case since this asset has rather few morphs, but it would increase loading time significantly for the base characters that have many morphs.
-
Ok thank you for the explanation.
I believe a note in the wiki will do then. We explain that in general some morphs may not be found if they have complex file relations, because the actual method to load morphs is simplified and relies on the morph name in the duf file. In this case we have to load custom morphs, eventually referring to the daz studio properties for help.
This also means that advanced users with technical experience have better chances to get “complex assets“ to work, while “base“ users may be happy with assets working out of the box. I believe this is fair enough.
request. better search and/or error reporting.
- You may want to try to improve the search only when some morphs are not found, for example in this case you may scan the ngv8 folders, since we know the missing favorite is for the ngv8 geograft.
- Also, when some favorites can’t be found, reporting a error message would help the user to understand the situation and eventually fix it with custom morphs. Actually there's no error for missing favorites.
Let us know what you think, if you're not interested we can close as won't fix.
p.s. When we load custom morphs for NGV8 the plugin opens in the ngv8 folder, this means somewhat the path is known. Please note that the PA name is right after the data folder and this is standard in daz studio, so we can search for missing morphs in the PA folders. We may also do a quick windows search for the PA name to be sure to get all the PA folders, but generally there's two folders one under data for the geograft, and one under the figure morphs the geograft is for.
PA = 3feetwolf
My Library\data\3feetwolf\
My Library\data\DAZ 3D\Genesis 8\Female\Morphs\3feetwolf\p.p.s. Or you may just make a custom fix for NGV8, as your list of “baked morphs“ is already going in this direction. Then the idea is the base implementation deals with most common situations then custom fixes are implemented for known “complex“ cases.
p.p.p.s. About missing morphs, doesn’t the morphs database help with this ? I mean I understood this is what it was implemented for.
-
repo owner
The plugin now imports the morphs in the test file.
The morph database is rather useless IMO, since it just takes too long to scan the daz files. Besides, it does not contain enough info in this case, since we need morphs for both the body mesh and the geograft. But I reused the code and made a special file for NGV8, which is bundled with the plugin in the data/scanned directory, and now it works. At least for the anus open morph.
-
-
Issue
#1530was marked as a duplicate of this issue. -
repo owner
It will take some time before this completely works as intended, e.g. I just discovered that morphs (those that go with a legs pose) are double counted.
-
reporter
Thomas and Alessandro, could you please take a look at the NGV8 Shader in the new Diffeo Version. Depending on the skin used, the Geograft may appear black.
Tested with:
Character Skin: https://www.renderosity.com/marketplace/products/152280
Blender 3.5.1 + Diffeo 1.7.0.1314 (everything works fine)
Blender 3.5.1 + Diffeo 1.7.1.1624 (NGV8 imports with no colors)
To reproduce:
1-Load Basic 8.1 F
2-Apply Louisa’s “!Louisa8.1 Iray PBR” skin
3-Attach NGV8 Geograft
4-Import with “Import DAZ + BSDF(Cycles)”
5-Results in a partially black Geograft (see screenshot below)
-
daz studio 4.21.0.5, blender 3.5.1, diffeomorphic 1.7.1.1625
Yes I can confirm that something is wrong with ngv8 on a g81 figure with pbrskin. I tried with Victoria 8.1 and got a error, in my case the scene doesn’t even load. Test scene included ngv81.duf, it’s ngv8 on Victoria 8.1.
note. As far as I know NGV8 doesn’t support pbrskin so we have to copy the materials by hand because the script doesn't work, that I did in my test scene. Apart this it should work fine.
note. The missing “default uvs“ is the shell uv map so it’s likely to be the black effect reported by Rob.
steps:
- import the test scene ngv81.duf with bsdf materials
-
- attached ngv81.duf
test scene for ngv8 on Victoria 8.1
-
repo owner
I don’t have any problems with missing UVs, but I can reproduce Rob’s bug with BSDF; with Principled the materials look fine. The blackness is caused by a black top coat node at the end of the shell node group.
-
repo owner
The plugin doesn’t generate black top coat nodes anymore, and the bsdf case should be fine too.
-
@Thomas Larsson Do you mean you can load my ngv81.duf scene without any error ? If so then it’s ok for me I don’t use ngv8 and it may be a glitch on my side. Let me know.
-
repo owner
Yes, I didn’t have any problems except for the black materials. Perhaps some difference in the global settings or the daz database.
-
reporter
I also had no problem loading your scene, Alessandro. And thank you, Thomas, the shader seems to be working great again.
-
commit 3c63a86.
possible bug. verbosity = 5. Ok I got what is crashing python on my side. It’s verbosity = 5, if I set verbosity = 2 then everything works fine. You may want to check it, or let me know if for some reason this is the intended behavior.
steps:
- set verbosity = 5 in the global settings
- import ngv81.duf
-
repo owner
Edited:
The error happens when making the uv map node for shells and seems to be harmless. Since the name of the uv set is "Default UVs" the plugin searches for a file with that name. The file that define the uv set is located in the "/data/3feetwolf/New Genitalia For Victoria 8/Base Layer/UV Sets/3feetwolf/Base/" directory, but it is called "default.dsf" it is not found.
In that case the plugin just creates a uv map node. When the mesh is built at a later stage the uv map with the right name is created. If you change the Shell Method to Mesh (Debug) you can see that the shells indeed don't have any uv sets, which shows up e.g. in the normal map nodes.
-
Here with verbosity = 5 I end up with a empty scene, that is, the addon loads nothing. So the error is not harmless, it prevents the scene from being loaded.
p.s. If it is difficult or not convenient to fix the code then we may just add a note in the wiki that verbosity 5 may generate “too much” errors and prevent some scenes from loading, even valid scenes. Then we may move the verbosity from general to debugging, meaning the user is not supposed to change the default, unless for debugging purposes if he knows what he’s doing.
-
repo owner
Verbosity = 5 is really only for myself, to trigger an error when something has gone wrong. Normal users should stick with verbosity <= 3. But there should at least be mentioned in the tooltip.
-
reporter
Thomas and Alessandro, I can't find it in the docs. I have two questions: First, why is there an asterisk (*) now before "AnusOpen" and on some other morphs? What does the asterisk mean? Second, why are the morphs with the asterisk not activated by default like the others?
-
-
reporter
Thanks Alessandro, so the asterisk (*) means: “that is protected from accidental change. The All button at the top will activate all non-protected morphs but leave protected ones deactivated.”
And checkbox not being activated means that it is not included when we clear or set morphs or keys.
Although I'm a bit confused about why some morphs, such as "Anus Gape Height" and "Anus Gape Width," which are very similar, are treated differently. One has an asterisk (*) while the other doesn't.
-
I am confused myself on this, personally I keep “protect multipliers“ in the global settings disabled. As I understand it we now have baked correctives and daz favorites so multipliers shouldn’t be needed anymore, that is, they should be hidden since the user is not supposed to change baked morphs. But Thomas seems to think otherwise so may be I miss something.
-
reporter
I also noticed that some morphs from the "ZExpansion" for NGV8 (Renderotica product link: https://www.renderotica.com/store/sku/60323_ZExpansion-Morphs-For-3feetwolf-s-New-Gens-V8)
If loaded with "Import Costume Morphs," they contain non-zero shape keys (see screenshot below). I assume this could lead to a similar problem as the "0000-InitialGenitaliaShape" that Thomas adjusted in the previous fix if not set to 0 before merging the Geograft.
-
https://bitbucket.org/Diffeomorphic/import_daz/wiki/Setup/Morphs/Import Custom Morphs
Again, “import custom morphs” is very technical and you do have to know exactly what you’re doing to fiddle with it. You may want to use daz favorites instead that’s much more safe and user friendly. Then if daz favorites doesn’t work it certainly means the specific morphs are “complex“ and you have to revert to custom morphs but in this case you’re alone wondering how to do it since Thomas can’t possibly build custom fixes for everything.
Just my opinion as I understand it.
-
reporter
These morphs do not work with "Daz Favorites" Alessandro, but I just wanted to mention these edge cases for future reference, and emphasize Thomas’s solution from above: “to set all the non-zero morphs to “0” before merging the Geograft”.
-
repo owner
The protect multipliers option didn’t work well, so I removed it in the last commit.
-
@Thomas Larsson A possible fix for most troubles would be to don’t import baked morphs, I mean never ever, not even if the user selects them with custom morphs. That is, if the user wants to use a morph in blender then it must not be baked in the dbz, that means it must be zero in daz studio when exporting. Then it is possible to show a error message when trying to import baked morphs. Or the user can import as morphed instead of dbz.
“error: the following morphs are not imported because baked in the dbz, they have to be zero in daz studio when exporting, or import as morphed instead of dbz.”
Again, unless for debug purposes, we should not expose baked morphs in the interface since the user is not supposed to change them. I believe adding too much options and morph mixing features is confusing both for the user and the plugin.
Likewise when daz favorites are not found a error could warn the user so he can revert to custom morphs. We may keep the custom fix for ngv8 since it is a extremely common asset.
“error: the following daz favorites are not imported because too complex, please use custom morphs instead.“
But I may miss something of course this is just a suggestion as I understand it.
-
repo owner
Now the global option “Baked Morphs” controls both if baked morphs can be imported, and if they are visible in the morphs panel. Since the option is disabled by default, novice users don’t need to worry about it, but if you really need to import an already baked morph (e.g. to undo it) that is possible too.
-
Thank you for the new option. The name and description are a little confusing since it may seem that baked morphs are not loaded without that’s not what it does. Below a possible alternative. But this is minor, also because it will be explained in the docs anyway.
option: edit baked morphs
tooltip: allows to import custom morphs that are baked in the dbz and to edit them in the baked morphs panel
Since the issue with NGV8 is fixed and improvements are made, if there’s nothing to add we may close as resolved ?
-
reporter
Thank you very much, Thomas and Alessandro. NGV8 Geograft is working great again on my end.
I have an additional request. Currently, the menu "Import Standard Morphs" defaults to "Use Suffix: Geograft," and the same applies to all other menus. Could we please revert it back to "Use Suffix: None"? It's very easy to forget to change it, and that can lead to complications for the models.
-
In general suffix to geografts should be safe and the better option, because different geografts may have morph names that are the same. Otherwise a morph will drive all meshes with the same morph name. For example this happens for the Headlight geografts by Meipe that are separated in left and right nipples with the same morph names.
As for NGV8 there’s morphs on the body and geograft, that have the same name because they are intended to be driven together, and they are in daz studio. So I guess there’s some properties linking the two morphs that is not considered by the importer. But Thomas did a custom fix for that.
So I’m not sure what you mean for “complications“. That is, if you use daz favorites there’s the custom fix. If you use custom morphs you’re looking for “complications” yourself and you’re aware of that so paying attention is required.
That said I’m not against suffix to none. It is rare that different geografts have the same morph names. But suffix to geografts is a better default for novice users.
-
reporter
Thanks, as always, for the detailed explanation, Alessandro. Okay, then I suppose everything works as intended now.
-
repo owner
I think I have a good solution: only add a suffix to duplicate meshes, i.e. if the rig has several meshes with the same topology. The left and right headlights have the same topology, hence they get suffixes, but NGV8 and GP have a unique topology and don’t need a suffix.
-
I disagree, topology is not relevant and it is by pure luck if left and right nipple have the same topology for headlights. Indeed left is a mirror of right in that case. The issue is a PA can make a different geograft with same morph names, and in that case the morph without suffix will drive both the geografts.
But again this is a rare case so we may as well set back “none“ as default as suggested by Rob, knowing that for some cases we need geograft suffixes. The important thing is for this to be clear in the docs.
-
repo owner
- attached ngv8-hl-favo.duf
There is a situation where it is necessary to handle morphs for different geografts differently. I have tested with G8F with both headlights and NGV8, and all four meshes have favorite morphs. Everything is now loaded correctly.
This turned out to be a challenge in another way. Both the headlights and NGV8 have uv sets called "Default UVs", but they are used differently and must not be merged.
-
Yes, that’s why using prefixes for geografts makes sense. In daz studio geografts are separate figures, and they keep separate even when merged. In blender we merge geografts to a single figure, so in general attributes may clash and using prefixes prevents it. At least this is how I understand it.
Commit ebd6379 seems to work fine here, thank you for looking into this.
-
- changed status to resolved
- Log in to comment
3.6.0 is beta and the issue could be gone when 3.6.0 gets released. Does it happen with 3.5.1 as well ?