- edited description
Legacy/Nearest Vertex morph transfer results differ from old versions
Hi,
some change in the morph transfer give quite odd results for me, my workflow is to transfer morphs from imported daz character to a higher resolution mesh which has subdivision applied
edit: this seems to affect legacy and nearest vertex transfer
the screenshot shows how the morph looks after transfer
left side: current master
right side: commit 4bdfa12c973bc1ffb004e57f0055e28cd462dbfc
Comments (11)
-
reporter -
The legacy method is just a slower version of the Nearest Face method. Have you tried that one?
-
reporter yea, have tried every method with the current master. (haven’t tried the other methods with the old build so i can’t tell if they would give a good result there, as i went with general/legacy usually)
-
Have you checked that the “Ignore Rigidity Groups” option is the same in both cases?
-
reporter yes
-
Ok, I checked it, morph transfer seems to be buggy in general, it’s not related to the Legacy method itself. In the old version you use, both Nearest Face and Legacy work fine. In the newer versions, both break at the same time. Nowadays, there is no reason to use the Legacy method, so you should use the Nearest Face method once it’s fixed since it does the exact same but faster.
It’s probably a silly bug Thomas has to fix since he was rewriting part of the morph transfer code in general. It’s not a problem with any particular method.
-
reporter - edited description
- changed title to Legacy/Nearest Vertex morph transfer results differ from old versions
-
repo owner Should work now. Morph transfer uses a custom morph if the vendor has provided one, and otherwise does auto transfer. However, both the base mesh and the HD mesh refer to the same directory, and therefore the morph for the base mesh was loaded, which left the subdivided vertices unmorphed. The fix consists of checking that the morph involves the right number of vertices.
You can see the difference if you start Blender from a terminal window.The tool prints an asterisk in front of the morph name if it finds a morph, and a plus sign if it does auto transfer.
-
I actually hope you return the old option which only try to “auto-transfer” without import and overwrite morphs when there is same name morph for target mesh. if Thomas forgive to change UI of tarnsfer option.
Of course auto serch the morph (vendor offered for the target mesh) and import it is really useful , but sometimes we may hope to transfer even though vendor offered it.
-
reporter Thank you Thomas, that was a quick fix and i’ve tested it and it works fine as expected
I’m marking this as solved, @engetudouiti i think you should make another issue if you feel like there’s something missing to keep stuff sorted.
-
reporter - changed status to resolved
fixed by commit 2b2bffe4956f0bf77c0806f8575050a42536f190
- Log in to comment