The requirement is that the source and target meshes have “compatible” UV maps. That is, source and target UV maps should show the same texture in the same way over the surfaces.
Actually, one doesn’t even need a texture for the add-on to work, but an actual texture would help for visual debug.
I performed a couple of tests between two spheres and between two monkey heads.
The two UVspheres were created using a different number of divisions.
The source monkey head is default “Suzanne”. The target monkey was scaled and the surface subdivided; then all modifiers and transforms were applied to the vertices.
As I am not a graphic artist, I improvised a few simple blend shapes. More tests are needed on real cases.
I would be happy to receive suggestions and test material.
For example, 3D models of human heads (sharing the same texture), where I can test the reliability of the transfer procedure.
The source code will be public as soon as code stability is proven.
Maybe it would be more convenient if it won’t involve UVs (since they are pain to transfer between different topologies)? Like, if you could recoird the shapekey as vertex groups, you could then put them on another mesh using Transfer Weights or Data Transfer. “Nearest Face Interpolated” mode works the best with mismatching topologies. Then, another script would decode those groups back to shapekey
Years ago, I tried something like that myself. I generated 3 vertex groups per shapekey, for each coordinate axis. To avoid the limitation of no negative values in VGs, I recorded minimum and maximum values of each coordinate (put them into VG’s name), and recorded a value of each vertex as ratio between real coordinate value and min/max range. Then, I manually ran Weight Transfer and reconstructed shape keys with another script. The code began throwing errors when there were other VGs on the mesh (not properly code-named), so I gave up on the project. Maybe you can realize this idea better
In fact, as I have no experience as modeller, I can’t imagine how difficult it is to adapt an UV to another model, but I thought that this is the best way to give full control to the artist on the way the ShapeKey is transferred.
My use case requires to transfer 300+ ShapeKeys, so probably it is worth the effort.
From a quick search, looks like TransferWeights is specialised on transferring information for armature rigging, while Data Transfer can transfer many vertex information, but nothing about ShapeKeys.
I think I understood the idea behind your attempt, but it would require source and destination objects to be positioned over to each other, as the transfer relies likely on ray castings to find corresponding points. In such case, the mapping might miserably fail in complicated areas, like ears and nostrils, if the two heads are too dissimilar.
Anyway, I will think of it for further versions.
In any case, my experience is that, while writing an operator, it is better to avoid invoking other operators and directly manipulate low-level data, in order to avoid context-related issues.