Problems Transferring Shape Keys (one model to another)

Hi all,

I wasn’t quite sure what section to put this in, so I put it here.

Basically, I am using Blender 2.70 (actually trying to update an old project and bring it into 2.77). But the last thing I wanted to do was, I have a model all rigged, textured, everything. EXCEPT…somehow, a very early version had a couple facial shape keys that I lost in the version updates…no idea how it happened.

In any case, there were no clear tutorials referring to this subject in the 2.7 series, but the tool descriptions on the Blender site should have been sufficient that something I tried should have worked.

I KNOW the meshes need to have the same vertex count and topology. However…I suspect topology must include vertex indices as well?

I noted (and show below), that although both models (offset to show comparison) have the exact same vertex and face count, there is one small area where I altered the shape and added a taper to the legs. But, according to the object vertex count, both objects have the same number.

Yet the shape key transfer fails because they “do not contain same vertex count”… but they do. Is that Blender’s general way of saying that this subtle change in the look of the mesh changed the vertex indices and therefore the topology…even though otherwise they fit on top of each other indistinguishably?

Is there a way to solve this? Or do I just have to remake all of my facial blendshapes because I was stupid at some point?

Pic attached, and hopefully the .blend file too if anyone can take a look at it. I didn’t pack the textures, and there are probably a few that have additional geometry that effects file size, but the main visible layer shows the two models in question (Parrot: target) and (Parrotsmile: source).


P.S.: My .Blend file is not attaching. It is 11MB…I don’t know if there is a size limit and that is why…I cut 25MB off and didn’t pack the textures. Any advice on THAT too and I can post the blend for anyone kind enough to help a stuck learner.

-M

P.S.: My .Blend file is not attaching. It is 11MB…I don’t know if there is a size limit and that is why…I cut 25MB off and didn’t pack the textures. Any advice on THAT too and I can post the blend for anyone kind enough to help a stuck learner.
Ensure you used the ‘compress’ option when saving your blend file or just use another file host site (Dropbox, Google Drice, One Drive, http://www.pasteall.org/blend/)

You would try with the “LichtwerkMesh Transfer” add-on, which works way better than the internal one.

Here it is: blenderpython/mesh_lichtwerk_Transfer.py at master · meta-androcto/blenderpython · GitHub

Here is the BA thread: [Addon] MeshTransfer (update 10.02.12)

paolo

In my experience, if the vertex count does match, the shape key will transfer (using the internal tool), but I also found that under some circumstances, the vertex order affects the result of the transfer. Because my target model did not match exactly in topology as well, the transferred shape key affected different vertices than in the source model, causing it to fail in its purpose. I know this does not directly address your question, and I will look at your .blend when you make it available, but it may answer a question you meet farther down the road.

Here is the .blend at pasteall: http://www.pasteall.org/blend/43175 (Thanks, Richard.)

@sourvinos: I haven’t tried that add-on yet, but I will today.

@chipmasque: That does offer some insight. Perhaps if you have some time you could look at the blend and see if it works for you (and is just idiosyncratic or I did something wrong), or if it is a vertex index problem. I wouldn’t know how to spot check that because as far as I know the vertex network is internal…and I’m guessing it would be nigh on impossible to fix that, in any case. But…the topology is VERY similar (if not the same), and as the vertex count is the same…it seems I may have just scaled a couple things.

Anyhow, help would be MUCH appreciated. There are only a couple shape keys I want to transfer, but the face of the object is very touchy and so it was actually a lot of work to make those couple keys. Even if I have to just bite the bullet and redo them…knowing WHY this is happening can save a lot of headaches in the future.

Thanks all.

That add-on seems old so I hope it works…but from peeking at the code (the comments, really. Can’t flatter myself), it seems the way that it works would work great with my model because it’s not “arbitrary” topology, it’s virtually the same. Especially if the add-on is reindexing vertices based upon their relative locations in space, it’s almost certain to come up with (wishful thinking?) the right solution.

BUT, any non-add-on suggestions or explanations would be great for knowing WHY this is happening.

Also…the shoulders on the model should probably be attached one face row higher…I created a work around to just lift them in the rig…but (and this is for a different thread), a related question would be if it’s possible to transfer a rig between objects of almost the same topology (i.e. lifting the arms one polyrow) without having to reweight everything that wasn’t changed…

I get a 404 error (file not found) at that pasteall link.

With LichtwerkMesh Transfer it was a breeze, I hope i got what you need: PasteAll.org - Paste Blend Files

paolo

@Chipmasque: Are you still having that 404? I just had it work, and it seemed like it worked for sourvinos/paul down there? If you try again and it works, I would love your opinion because it seems like you have some insight into the “whys” surrounding the process.

@sourvinos: You got something to work? Great! I’m going to check it out. Wondering, what version of Blender did you have the add-on installed in? And, I am assuming the same answer, what version of Blender did you save this with? I just want to make sure it works with my version, or if it doesn’t, I can open it, see what you did, and then repeat it myself (and learn from it!). That’s just great though, thank you so much for putting in the time to see if it worked. Good people on this board.

-M

Got the file. The vertex count does not match. ParrotSmile = 4193 verts, Parrot = 4246 verts. Blender 2.76.

@arcarsenal,
I edited the file in blender 2.75, tough you can safely open it in blender 2.77 without problems, or in whatever version you used to create it. You don’t need the addon to read the file, it has already done its work.

All you have to do to reproduce the process yourself is to get the LichtwerkMesh add-on from the link I posted before, install it and then, on the desired (target) object, run the add-on from the object Data Panel.

This addon has been working since time immemorial in every version of blender until today.

paolo

@chipmasqe… ineresting, i checked the vert count over and over,

sourgrapes, thank you!

How’d you do that specifically? I’m also interested why the discrepancy.

you did it too, grrr !! LOL :evilgrin::evilgrin:

The discrepancy in vertex count should come from the added loops at the knees, if i remember correctly.

paolo

No doubt, but I do wonder why the vertex count comparison was not straightforward.

yeah sorry, i forgot this quite cryptic point:

(underscore are from me)

paolo

My vertex count came from the top number circled in red in the first picture I posted. I selected “Parrot” and “ParrotSmile” over and over, and the number remained the same.

Is there another place to check the vert count?

That’s what led me to believe the legs didn’t add a loop, but reorganized what was there. Guess I was wrong?

-M

It works just in Edit mode, otherwise it shows the total numbers per scene, weird but true.

AFAIK no

it depends on what you did to make modifications, if you added some edge loops of corse you added vertices.

sourgrapes

Yes, to get an accurate vertex count for an individual object, enter Edit Mode & Select All. In the top-of-the-screen readout the count will appear as 4126/4126, or some such, indicating all available vertices in the object are selected. Select a loop, or any subset of verts, and the first of these two number will be reduced, as in 18/4126.