The “Disable All Layers” button of the MHX Plugin is not working.

[Prenses Karolin]

I have attached the error as an attachment.

I use G9 Character and the latest versions of Blender and Add-On.

‌

Steps to create the problem:

1:Import any G9 character.

2:Convert Armature to MHX

3:Click on the “Disable All Layers” button.

‌

And

I discovered another problem,
For G9, face morphs (expressions etc.) are not transferred to the eyelash object. When I transfer them manually there is no problem, but not automatically.

‌

I want to ask a question.

Before the MHX plugin was updated, I imported and edited my characters.
Today I updated the MHX plugin and when I went into the layer section, I saw that something was wrong.

New layers have been added and old layers have been deleted, so I can't use the layers properly to check the armature I imported before the update.

My question is, how can I find the old version MHX plugin?

[Alessandro Padovani]

1.7.4.0120

I can confirm the issue with MHX. As for downloading old versions see #1809.

[Thomas Larsson]

The bug is fixed in the last commit. Now both enable and disable layers work in both Blender 3.6 an 4.1.

The main purpose of the layers panel was to assign names to layers. In Blender 4 we have named bone collections, so we can easily find the right bone collection directly in the armature context and toggle the visibility there. If you really need to have the old collections in the layers panel (I think it is just the two “Extra” collections that are gone), you could rename them to “IK Leg 2 Left” and “IK Leg 2 Right”.

‌

[Alessandro Padovani]

Commit e7663dd works fine here, thank you for the fix.

As for G9 I can’t reproduce the issue, the FACS are correctly transferred here. Unless there’s specific steps.

my steps:

1. easy import G9 with “FACS” and “transfer to face”.

‌

[Prenses Karolin]

According to the expressions, eyelashes used to be much more flawless. But now they don't quite fit the expression. In particular, the lower lash is very uneven.

I will share with you my import settings, maybe I am doing something wrong?

‌

‌

‌

‌

[Prenses Karolin]

I have the global settings and import options in the photo.
What I'm doing is just importing the G9 character with these settings.

[Thomas Larsson]

Shapekeys are now transferred to the lashes again.

This problem was introduced recently when I was dealing with G9 morphs. G9 consists of multiple submeshes: mouth, eyes, lashes, tear etc, and it didn’t make sense to transfer shapekeys to the mouth. I thought that there should be custom morphs for all the known submeshes, so it was unnecessary to transfer them. This assumption was clearly wrong. Instead of skipping transfer to all known meshes, the plugin now only skips meshes with rigidity groups, i.e. the G9 mouth and eyes. Lashes, tears, and unrecognized face meshes get shapekeys.

Edit: Shapekeys are now transferred automatically to geografts with rigidity, e.g. NGV8.

[Alessandro Padovani]

@Thomas, I’m not sure why you skip transfer for some. I mean conformed meshes (“fit to” in daz studio) should always get transferred morphs, indeed this is what conformed means that they get transferred morphs from the figure they conform to. Eventually loading vendor morphs if any, but this is already supported by the transfer tool. Of course rigidity will limit the morphs influence with the rigidity map. It’s non-conformed meshes (not fit to in daz studio) which don’t get transferred morphs.

All the face meshes in G9 are conformed in daz studio, so I’d go for transfer all, unless I miss something.

note. Then scale maps don’t work in blender, so if some morph is using scale maps it will not work properly, as it happens with some geografts. About this, the addon could also display a warning if scale maps are found, so the user is aware.

‌

[Thomas Larsson]

I agree in principle, but in practise transferring shapekeys to rigid meshes is usually a waste because the transfer process is imperfect. E.g., after transfer the facs_bs_MouthLipsSide-SideLower morph moves mouth vertices up to 4.5 mm, even though moving the lips shouldn’t move the gums or teeth. This may not be visible because the gums are hidden behind the lips, but is still a bad idea to add unnecessary shapekeys.

Morphs that change the character are a different things, and they should be transferred to all meshes in the figure. But you can always do manual transfer of those morphs afterwards, whereas it is not so straightforward to remove unwanted shapekeys and drivers.

[Alessandro Padovani]

1.7.4.2104

I certainly agree that the transfer is imperfect, we use a “nearest face“ algorithm but we never verified what daz studio really does, also because it’s not easy. That said, I tried to transfer by hand the “lips side-side“ morphs to the mouth with the rigidity option, and here nothing moves it works fine, because the mouth is 100% rigid so it is not affected by any transferred morph.

I also certainly agree that it is a good optimization to don’t transfer morphs to a 100% rigid mesh, it wouldn’t have any effect anyway.

note. rigidity speedup ? I noticed that you don’t use the influence map for transferred morphs, so I guess you take into account the rigidity into the morph value. Another possible way is to transfer the morph without taking into account the rigidity, then use the inverted rigidity as shapekey influence. Just in case this may be useful, perhaps to speed up transferring with rigidity, that seems to me much slower than without rigidity.

‌

[Thomas Larsson]

The reason you don’t see the deformation is that the plugin corrects for rigidity, using a suggestion by Suttisak Denduangchai, #749, #754. This can be turned on with the Ignore Rigidity option.

Using an inverted rigidity group seems to work well, and should lead to much faster transfer. Here is an early test:

‌

[Alessandro Padovani]

1.7.4.2104

Nope, I didn’t ignore rigidity and the transferred morphs seem to work fine here, in that they have no effect. Anyway again I agree that transferring to a 100% rigid mesh makes no sense. I’m glad that the “flexibility“ map works fine, hope it speeds up the transfer. I’d keep the name “rigidity“ though as in daz studio so it’s more clear. I mean we don’t need the original rigidity so we could just invert and keep the name.

‌

[Thomas Larsson]

Filtering shapekeys with a vertex groups does unfortunately not work in general, but only when the shapekey does not involve a rigid translation. So it works for FACS morphs but not for most character morphs. So we are stuck with the slow code that corrects for rigidity. I may try to speed it up, but since I didn’t wrote it myself I’m not comfortable with changing it.

However, it is wasteful to transfer the FACS shapekeys to the eyes and mouth. The Ignore Rigidity Groups option has been replace with an option with three values:

1. None. Rigidity groups are ignored.
2. Partial. Rigidity groups are handled, but morphs are not transferred to fully rigid meshes, e.g. the G9 eyes and mouth.
3. Full. Rigidity groups are handled as before.

“Full” is the default for manual transfer, and “Partial” for easy import. That can be changed with a global setting.

‌

‌

[Thomas Larsson]

I found a better solution. The code that corrects for rigidity computes the shapekey and mesh base centers. If they are equal and the mesh is fully rigid the shapekey is removed.

[Alessandro Padovani]

Thomas, as I understand it, the issue you are referring to only applies if we use morphing armatures, where the code by Suttisak comes into play. If we don’t use morphing armatures, that is, the option is disabled in the global settings, then we can use the optimized “inverted rigidity“ map to simplify the process and speedup the transfer.

Personally I don’t use morphing armatures and I strongly believe it is bad to use them in blender as Suttisak and others do. But I understand different people have different needs. Anyway, with the new “ERC by translation” plus “DBZ morphs“, we can work around the code by Suttisak so even in this case we can use the optimized rigidity.

The code by Suttisak is only used for “ERC by armature“, that is now somewhat obsolete and replaced by the new method. Unless I miss something, that’s entirely possible since it is difficult for me to understand the addon code in general. Let me know.

[Thomas Larsson]

No, the rigidity code is always used when shapekeys are auto-transferred, i.e. there is no vendor morph. It is done in the function correctForRigidity in transfer.py. If rigidity is ignored the lips side-side morph moves the teeth as in my picture above; I don’t understand why you don’t see the same thing.

The UI changes have been reverted, because correction for fully rigid meshes is now fast; shapekeys are removed if the center doesn’t move. This might not be the most general case, because Suttisak’s code seems to deal with global scalings as well, but I think that is a very rare case.

[Alessandro Padovani]

Thank you for the explanation. I do get the transferred morphs if rigidity is ignored. I did my tests always with rigidity on, perhaps I wasn’t clear enough on my side.

Then if there’s nothing to add we can close as resolved.

[Alessandro Padovani]

Thomas, I gave a look again at the articles by Suttisak you pointed above, and I don’t see how they are relevant without morphing armatures. All the issues addressed and resolved by Suttisak only apply to “ERC by armature”, they don’t apply if we don’t use morphing armatures aka export the baked dbz, they also don’t apply if we use “ERC by translation“ with “DBZ morphs“ because again the necessary information is already baked in the dbz.

The correctForRigidity() function could just use inverted rigidity maps if we don’t use “ERC by armature“.

Please double check, then if you are absolutely positive that I’m wrong I’ll trust you and close as resolved. Thank you.

[Thomas Larsson]

The correctForRigidity function changes every shapekey if the mesh has rigidity. That’s why Suttisak put it in transfer.py. I removed the morphing armature code at some point because it ruined the G9 eyes, and it was horribly slow anyway.

The morph for a rigid mesh is not zero, it is a rigid transformation of some reference verts. Hence it can be a rigid translation, scale or rotation (although the latter is not implemented). If the average translation (of the reference verts, not of the entire mesh) is zero, and the rigidity group ignores scale and rotation, we can simplify the shapekey: Remove it entirely if the rigidity group is the entire mesh, and add a vertex group to the shapekey otherwise.

NGV8 has two rigidity groups: Vagina and Rectum, which are affected by scale, unlike G9 mouth and eyes. The picture shows the Heavy morph. It is a difference between correcting for rigidity and adding a vertex group to the shapekey.

‌

[Alessandro Padovani]

Yes I understand that, but if we don’t use morphing armatures, that is, we bake the figure and geografts to dbz, then the rigidity correction is already baked in the dbz. Same if we use “ERC by translation“ with “DBZ morph“. So in those cases we only need the rigidity map for shapekeys, because the “rigid translation“ is already baked in the dbz. That’s my point, sorry if I was not clear enough. Let me know.

[Thomas Larsson]

Rigidity is always baked into shapekeys in Blender, I think.

1. If we load dbz morphs, it is baked.
2. If we auto-transfer a shapekey, correct for rigidity bakes it into the shapekey. Or removes the shapekey entirely if possible.
3. If we transfer with a vendor morph, the vendor has hopefully taken rigidity into account.

So we really only needs the rigidity group when we transfer shapekeys. Once that is done, it has no use.

‌

[Alessandro Padovani]

I am not sure that we understand each other on this matter, but the actual implementation works fine enough anyway so I'm closing as resolved. Thank you for your time and explanations.