Shapekeys/vertex issue with Breastacular for G8F and G9

Issue #1940 resolved
Jasper29 created an issue

Breastacular (possibly other upper torso geografts) no longer works corrrectly with transfer shapekeys and merge geografts. I only

tested with Breastacular and G8F,G9 but other figuers as well as other geografts (upper body it seems--Golden palace is still fine)

could also have the same issue. NOTE: I also only tried the manual setup (Easy Import with only transfer to face meshes enabled).

Steps to recreacte:

1: Import G8F or G9 with Breastacular (transfer to face meshes only selected)

2: Select Breastacular and then select main mesh. Transfer shapekeys.

3: Select Breastacular and look at shapekey menu in Object Data Properties--zero shapekeys were transfered.

4: After merging Geografts, select DAZ rig shoulder bone and rotate up on Global Y or Local X axis--notice weird mesh bulge/vertex merging

issue.

NOTE: Even though this issue is apparent with G9 as well, in my testing it didn’t seem AS bad as it is with G8F, but it is still there.

Can anyone else confirm?

Comments (31)

  1. Jasper29 reporter

    Also wanted to note that this issue is persistent even after rig generation (only tested with Rigify but I assume with MHX as well).

  2. Jasper29 reporter

    EDIT: After even further testing with G9, I noticed that shapekeys DO transfer, but after doing the transfer and merging, the breast bones do not move the whole

    breast mesh like they are suppose to, whether it be with the original DAZ skeleton, or Rigify rig. However, the weird armpit/shoulder mesh bulge is still present with G9 as well. Also note that this movement issue (besides the armpit bulge) is not present with G8F--with G8F even though shapekeys aren’t transfered, you can still move the breast mesh pretty normally using the DAZ bones or a generated rig, just moving the shoulders up causes the armpit bulging.

    This is a G9 figure:

  3. Alessandro Padovani

    importer 1.7.4.2029, blender 4.0.2

    bug. skip rigid meshes. I can reproduce the issue with G8. The culprit is “skip rigid meshes“ when we transfer, this also affects easy import so I suspect this option should be off by default. But better wait for an explanation by Thomas, since this is a new option I never used myself so I’m not sure if it is an optimization or more.

    bug. custom bones. As for G9 the culprit is that custom bones are hidden by default, so you need to unhide them in the bone collections. There you can access the breastacular custom bones, since the G9 pectoral bones don’t affect breastacular much. This is the same in daz studio so not a bug, the bug is that custom bones are hidden.

  4. Jasper29 reporter

    Thanks for the input Alessandro, I forgot about the custom bones layer. As for the ‘skip rigid meshes’ option, we will wait for Thomas to come back from vacation, thank you.

  5. Thomas Larsson repo owner

    The skip rigid meshes option was introduced because some shapekeys were transferred to the G9 eyes that shouldn’t be, like FACS. But some shapekeys should be transferred, e.g. FHMs, so it might be better to disable the option by default.

    Some rigid objects like buttons should not have shapekeys, or just the same translation for all vertices, whereas partially rigid objects like some geografts should receive the shapekeys. Perhaps that best thing is to always transfer shapekeys, and add an extra button that lets you remove unwanted shapekeys, including their drivers afterwards.

  6. Alessandro Padovani

    If this can help. In daz studio there’s the property of “conforming“ and “not conforming“, where only conforming objects autofit, that is, they should get transferred shapekeys in blender. Then rigid maps allow to mask the transfer, so full rigid objects only translate but don’t deform. As I understand it there’s no need to guess anything, to get the correct behavior it is enough to uncheck “ignore rigidity group“. That is, the new “skip rigid meshes“ could be a optimization for “ignore rigidity group“ where if the mesh is full rigid then the transfer is not done.

    The G9 eyes are conforming and get a full rigid map aka all vertices are 100% rigid, so they translate aka follow the armature, but don’t deform aka receive shapekeys.

    Breastacular is conforming and gets a partial rigid map, so it both translates and deforms.

  7. Thomas Larsson repo owner

    OK, I think I have a good solution now.

    First, the option to skip rigid meshes is removed, and replaced by a new option to use non-conforming meshes. The conforming property is set when the mesh is imported. Morphs are transferred to non-conforming meshes by default ATM, so it works for old meshes that don’t have the conforming property, but that will be changed later.

    Finally, a tool that deletes shapekeys and their drivers is added, to quickly remove shapekey that were transferred by mistake. It differs from the standard tool that doesn’t clear drivers.

  8. Alessandro Padovani

    Commit 28842e6.

    Works for breastacular but doesn’t work for the G9 eyes. I don’t see why you want to transfer to non-conforming meshes this is not to be done ever, or at least in daz studio it is not. Again, in my opinion it is enough to check for the rigid map, if it is 100% rigid then no transfer is to be done.

    # transfer shapekeys
    check the rigid map
    if all vertices are 100% rigid
        don't transfer
    

    steps:

    1. easy import G9 with “FACS” and “transfer to face”
    2. the FACS are transferred to the eyes, that should not since they’re 100% rigid

  9. Thomas Larsson repo owner

    But we do want to transfer shapekeys to 100% rigid meshes, e.g. FHMs. The transferred shapekey should be rigid translation. The Transfer Shapekeys does that, I think, but I did not write the code and am not sure how it works, cf #749, #754. It can increase transfer time a lot, however, and that’s why there is

    The idea with the Remove Shapekeys tool is that the user can quickly remove shapekeys that were transferred by mistake.

  10. Alessandro Padovani

    update. possible solution.

    I deleted my previous post because it was mostly confused, and partially wrong.

    I explored some more the G9 eyes. As I understand it the rigid translations are simply due to the eye bone translations when we fit the eyes to the figure, for example with the base feminine FHM. Each eye gets a 100% weight map on the relative left/right bone so it moves with the bone. Then there’s the rigid map preventing deformations.

    That is, rigid translations should be performed by the ERC aka morphing armature code, which moves the figure eyes bones, thus once merged the eyes themselves.

    Then transfer shapekeys should ignore 100% rigid meshes as noted above, thus FACS don’t get transferred.

    Let me know what you think.

  11. Thomas Larsson repo owner

    No, FHMs (or head_bs morphs in G9) involve shapekeys too. Here is G9 with Victoria 9 head morph. To the left the body and head morphs have been transferred to all meshes except the eyes, to the right the eyes are included too. Note that the eye bones are still misplaced in the right picture because ERC morphs are not enabled.

  12. Alessandro Padovani

    update.

    Again I deleted my previous post because I believe it was confused. This ERC complexity doesn’t affect me because I always bake to dbz and don’t use morphing armatures. Thus I’ll trust your decisions, thank you Thomas for looking into this and considering my comments.

    So if there’s nothing to add we can mark as resolved, in that we can use the new tool to delete unwanted shapekeys.

  13. Jasper29 reporter

    Awesome, thanks Thomas and Alessandro--Just so I understand the new changes correctly for geografts like Breastacular and Golden Palace (which are conforming meshes, correct?), we would want to deselect ‘non-conforming meshes’ when transferring shapekeys? Because I just tested G9 with Breastacular and no matter which option I choose ‘non-conforming meshes' ‘ignore rigidity groups’ or not selecting either still gives an incorrect result (mesh bulge). Do we have to use the new ‘remove shapekey’ tool to find and delete uneeded shapekeys that are the possible culprit to fix it? For G8F it seems fine (for Breastacular).

    G9 after any option for tshapekey transferring:

  14. Jasper29 reporter

    Just turning off shapekeys in Object Data Properties after transferring morphs, I found that for G9, 'body_cbs_shoulder_z55p_(l) and (r) seem to be at least partly the culprits. It looks better after turning them off or deleting them, but still looks a little weird and retains a weird, albiet smoother bulge:

  15. Jasper29 reporter

    EDIT: I just remembered I have limits/rotations off (for when I use Rigify) and that deformation seems pretty normal after turning off that shapekey--I just have the shoulder translated further up than it should--if someone can clarify if this is the correct procedure for G9 (and possibly G8F) geografts going forward, that will help make it clear for me and others.

  16. Jasper29 reporter

    After setting up with Rigify and checking even more shapekeys, ‘body_cbs_upperarm_z90n_(l) and (r)’ seems to be the other culprit that when deleting/turning off with the shoulder one mentioned, fully fixes the problem:

  17. Alessandro Padovani

    importer 1.7.4.2038

    Nope, G9 seems to works fine here, both with easy import and manual transfer. I tried the Kat figure coming with the G9 package, with breastacular. Both cbs_shoulder and cbs_upperarm are fine. May it be you forgot to update ? In your pictures I can’t see the addon version, nor it is reported in your description.

    steps (works fine):

    1. easy import with jcms, transfer to geografts, merge geografts

    steps (works fine):

    1. easy import with jcms
    2. transfer to geograft with default options (non conforming off, ignore rigidity off)
    3. merge geograft

    p.s. For custom figures you also need to import the custom jcms if there’s any, that’s done with “baked correctives“ in easy import. This is not needed with Kat since she works with the base jcms.

  18. Jasper29 reporter

    I’m using Diffeo 1.7.4.2038 as well-- Blender 4.0.2, Windows 10

    So I also noticed that even after transferring shapekeys and ‘fixing’ the deformation issue, my G9 characters' breasts using Breastacular have a deadzone at the nipple unless I parent the base Breastacular bone to the DAZ skeleton pectoral bones. Is this normal as well? This doesnt happen to G8 (I believe because there are no bones for G8 Breastacular). Here I have parented the Breastacular base bone to the pectoral bone on the character’s left side--the right is left to default
    (after transferring shapekeys and merging geografts):

    both sets of breast bones have influence ove the mesh

  19. Jasper29 reporter

    As for the original issue, It is still apparent for me--but I can fix it just like I did with the G9 eye issue I still have. I have tried with a fresh G9 install so it’s not on the DAZ side, it must be some addon or line of code in my Blender (although using Clean Panels Pro gives me an option to delay all addons with an exception list, but putting Diffeo on the exception list so it is active while no other addons are still doesn’t fix it, but I think it still could be code from another addon affecting it). Anyway we can close this now, the issue seems to be confirmed on my side only. Thanks again to the both of you. The remove shapekey tool is much appreciated as well.

  20. Alessandro Padovani

    For Kat the breastacular nipple moves a little with the shoulder bone, same as daz studio, so everything seems to work fine. You may want to test Kat with my steps above to see if the issue only arises for your particular figure. Then again be sure to import the custom jcms if any.

  21. Jasper29 reporter

    Ok the results are the same with Kat as well. I always use Baked Correctives but the issue still remains for me.

  22. Alessandro Padovani

    Well, if Kat doesn’t work for you following my steps then it may be something in the global settings, but no idea what it may be. Below mine if it can help. I tend to use minimal features for rigging and morphs.

  23. Jasper29 reporter

    Well following those settings and using Kat with breastacular again, the problem is solved (G9 eyes still have that weird pivot point unless I get rid of or deactivate the shapekeys ‘facs_bs_EyeLookIn(Left) (Right)’ and ‘facs_bs_EyeLookOut(Left) (Right)’ on the eye mesh, but thats a seperate issue I think). However, I need to narrow down which setting exactly is causing this, plus I did not modify the Breastacular breasts at all, it is at default (modifying the actual geograft might cause the issue too). I also will test other figures too to make sure it isn’t happening on certain figures. Thanks again Alessandro.

  24. Jasper29 reporter

    Very strange-- so I went back into DAZ and edited the breastacular breasts using both breastacular morphs and other vendor’s morphs as well and then reimported with Alessandro’s settings above. Everything seems to still be fine, so then I went back to Global settings and changed them back to my original settings for setting up with Rigify, reimported/transferred, and everything is still fine. Maybe it is just the character itself--if anyone has Cleona from DAZ:

    JS Cleona HD for Genesis 9 Feminine | Daz 3D and can test with Breastacular that would be great, but I think we can assume it’s just a figure issue at this point.

  25. Alessandro Padovani

    Nope, Cleona works fine here with breastacular, tried both base and HD export. For HD don’t forget to enter the geometry editor. Looking at the currently used morphs in daz studio it seems Cleona doesn’t have custom jcms she works with the base jcms.

    p.s. You may try to update the addon, then re-export and re-import, since I understand it worked with Kat.

  26. Jasper29 reporter

    Came back here to say that after trying several figures with Breastacular and having no issues, I went back to setup and reimport a new Cleona and have zero issues now as well. Don’t know what it could have been, maybe its a morph I had used at the time that did it, but can’t find it right now. I will do more testing, I’m sure it will come up again. Hopefully I’ll be able to isolate it. I think we can finally just close this as user error. Thank you.

  27. Log in to comment