Transfer shapekeys to clothing is not selective like in 1.7.1

[jeroen b]

Unlike stable version 1.7.1., using the “nearest face” option for transfer of shapekeys to clothing, results in copying all shapekeys of the sourcemesh to every clothing item, instead of only the relevant ones.

In order to realize that this is no trivial issue, some statistics;

Working on a blendfile of 436MB, transfering shapekeys to clothing with version 1.7.1 takes 50 seconds and increases filesize to 560MB. Doing the same transfer with latest version 1.7.2 takes 190 seconds and increases filesize to 1038MB with serious performance degradation as result.

‌

‌

[Thomas Larsson]

No, I cannot reproduce this. I loaded some facs and jcms to G8F and transferred to clothes and eyelashes. Only the relevant ones were transferred.

‌

[Alessandro Padovani]

I too noticed that transferring is extremely slow but didn’t do any comparison. Perhaps 1.7.1 uses a different/faster method to transfer ? I mean 50 seconds vs 190 is a lot.

@jeroen Does this happen only with HD ? Can you provide exact steps and details on your side ?

[jeroen b]

Herewith a link to a testfile; https://drive.google.com/file/d/1_LFOMRCtlyNVVd3Z7u0xaFo1XyVMt2q9/view?usp=drive_link

Try transfer shapekeys from the character to the clothing with the dev-1.7.2 and stable-1.7.1, a picture of the settings I use;

For whatever reason, the bug is not as dramatic in this case but will demonstrate the issue. It seems to me that the transfer error that I encounter with the dev version is inconsistent. Sometimes it is really bad, copying literally every shapekey of the sourcemesh to all clothing items and after some time working with the blendfile the results sometimes changes.

Pictures of console after transfer;

‌

‌

‌

Pictures of SockL shapekeys in both cases;

‌

‌

‌

[Alessandro Padovani]

Your shared file gives an access denial error, you may want to make it public. Or upload the duf file here, of course we also need the list of the used assets in your scene.

The socks getting tongue and eyelashes morphs may reveal the culprit.

The transfer tool in 1.7.2 works with proximity, that is, every close mesh gets the transfer. So it may also depend on the figure pose, though it should use the rest pose unless you import a dbz posed figure. For better transfers we may do them by hand selecting the source and target and the morphs to transfer, but this may not be doable for lots of morphs.

[jeroen b]

The link should work now, forgot to make it public, sorry about that. I cannot upload to Bitbucket, max filesize is 100MB and the file is about 125.

About a list of items; this is a basic G2F & girl6 morph rigged with a G8F armature, no duf available. Clothing is the basic G2F stuff and some quick items made as gloves, socks & haircap.

[Alessandro Padovani]

blender 3.6.4, diffeomorphic 1.7.2.1846

Yes I can confirm the issue. It seems eyelashes and tongue morphs are transferred to the socks, but they show no influence with “visualize shapekey“.

steps:

1. load the test scene
2. select all the clothing items then the body as active and transfer shapekeys

‌

p.s. Your test file is about 15 MB once you remove the materials, which are not needed to test shapekeys. Next time you may want to do it.

[jeroen b]

I am curious Alessandro about your remark about removing materials in order to reduce filesize, as far as I am aware, there are no meaningful materials present. Perhaps you meant something else?

[Alessandro Padovani]

Nope, I just removed the materials and saved as compressed as usual and the size is 15 MB. Already deleted your version so can’t tell, may be you forgot to compress the blend ?

[jeroen b]

Would you believe Alessandro that it never crossed my mind to zip blendfiles, did not even know that it is possible.

I have 7z on my computer, but what file format do you use in order to compress to just 15MB? If I use the standard settings in .zip format, the filesize is still 98MB

[Thomas Larsson]

Weird. When I load a fresh G8F with basic wear, the facs_bs_TongueIn shapekey doesn’t transfer to the clothes, but in your file it does. I don’t see what the difference is.

[Alessandro Padovani]

Jeroen, I didn’t use zip, just compress in the save options it’s the gear on the right. Scene included so you can compare with yours.

steps:

1. delete materials
2. save as compressed

‌

[Alessandro Padovani]

compressed scene without materials

[Alessandro Padovani]

Thomas, on my system the test scene by Jeroen does 135 seconds for 1.7.1 and 170 seconds for 1.7.2, so there’s some difference but not exceptional. Anyway 1.7.1 doesn’t transfer eyelashes and tongue to the socks. You may want to compare the transfer code with 1.7.1 to understand what’s the difference.

p.s. Jeroen, I assume you made the scene with 1.7.2. Otherwise if you made the scene with 1.7.1 then transfer morphs with 1.7.2 may be this is the culprit, if some internal properties are different and 1.7.2 gets confused. Let us know.

[Thomas Larsson]

The plugin keeps a transferred shapekey if the maximum translation is at least 0.1 mm, which is 0.0001 m if the figure is imported with the global unit scale = 0.01. Each imported object keeps its unit scale in the DazScale property, which is displayed in the Utilities panel, and we see that it is indeed 0.01. But when the transfer tool is executed, the scale is suddenly changed to 0 in Jeroen's file. Then the threshold also becomes 0, and all shapekeys are accepted, even facs_bs_TongueIn where the max translation is around 1e-11. I have never seen anything similar before, and it doesn’t happen in other files, so something in your file must be corrupt.

Anyway, the plugin now uses the global unit scale setting instead. Since that doesn’t mysteriously change when the transfer tool is executed, the threshold is now 0.0001 and zero shapekeys are not accepted. It is probably a bad idea to keep the unit as an object property.

[Alessandro Padovani]

Commit 9e4f0c1 works fine, thank you for the fix.

possible bug. speed. Here the new commit takes 295 seconds for the test scene, vs 170 of the previous commit and 135 of 1.7.1. Please let us know if this is necessary. As for the bug, since 1.7.1 works fine it is unlikely to be a corrupted file, it must be something in the code. Perhaps 1.7.1 already used the global units ?

[Thomas Larsson]

The performace loss is due to a change in the threshold (eps): it use to be a local variable, now I made it into a class member. The calculation of the bounding box at line 562 of transfer.py seems to be the culprit. In the last commit I replaced it with a local variable on line 561:

    eps = self.eps

That led to a great performance gain. Here are the times take to transfer to top, shorts and haircap:

Last week: 51.4 seconds

Yesterday: 77.7 seconds

Today: 41.0 seconds

[Thomas Larsson]

I wasn’t aware that using class members in loops is much more expensive than local variables. It is probably done in other places as well, will check the code for this.

[jeroen b]

Thank you Thomas & Alessandro for digging into this issue. The testfile is created with a dev version from a couple of weeks ago, since it rely's heavily on the “by number” option to transfer shapekeys. The latest commit works even better than 1.7.1. since it leaves out a number of shapekeys that have no bussiness on the mesh, for instance on the top clothing item.

There is however a performance penalty, on my pc the transfer with 1.7.1 takes 50sec, the transfer with latest commit takes 128sec (but with better selectivity) For me no big deal, but faster is always welcome.

And thank you Alessandro for reminding me to save as compressed, won’t forget that anymore LOL!

Edit;

Correction, missed the latest commit. Now the transfer takes just 50sec and with thesame result, brilliant!

If you gentlemen are also happy with the result, you con close as resolved and thanks again.

[Alessandro Padovani]

Commit d300fbd works great, thank you Thomas for the fix.

Jeroen, here for your test scene the speed is the same as 1.7.1, I get 135 seconds for both, you may want to double check. Let us know.