I spoke a bit too loosely in referring to the "Set" method.  I was thinking of the SetX/Y/Z WorldVertex approach used in NoPoke and elsewhere.  The whole quandary I was trying to explain yesterday.  I can use the source geometry or the actor WorldVertices.  I can use vertex comparisons or vertex-to-polygon comparisons.  The vert-to-poly comparisons currently result in a memory leak, the cause of which is still uncertain.  Using the NoPoke approach may remedy that.  Maybe not.  

I have some Big Questions right now which keep getting lost in discussions of theory concerning the details of comparing meshes with incompatible shapes.  I'm not surprised my questions are the least interesting in the thread.  :-P  Unfortunately, they're also the questions most pertinent to the actual script, until and unless someone else takes over.  :(  If I can't resolve some of these questions, I can't move the project forward to the point where details of mesh comparison will even be an active consideration.

Right now the two biggest questions are: why does this RAM leak occur, and what can done about it?  And: is there a way to calculate vertex weights using vertex-to-vertex comparisons, so as to avoid the RAM leak which accompanies the vert-to-poly comparisons?

It turns out that Walk This Way was taken over by svdl and the version which encounters memory leaks was his, not Ockham's.  So I'm trying to reach svdl to ask about the RAM leak issues.  His seems to be the only script in Poserdom to have had this same basic problem, and I hope he may have some understanding of the leak situation.  Ockham informed me that it's quite hard to make Python leak memory.  Hmm.

I'm trying the Spanki weight-calculating method for triangles within the context of svdl's suggestion about weighting using a vertex approach.  I've tested using a spherical range check to find MeshA verts which should be weighted for a given meshB vert.  The radius of the sphere is substituted for the triangle edge in the Spanki code.  So far, this works to give me weights, but it is obviously incorrect, returning no correlations in many cases and returning groups of correlations which have a total weight above or below one in many other cases.  But something along these lines may go somewhere.  Some of the testing results are a bit puzzling, so far.  The same loop structure of each meshB vert checking all meshA verts takes much longer in some cases, depending on how the sphere radius/threshold is set.  

===========================sigline======================================================

Cage can be an opinionated jerk who posts without thinking.  He apologizes for this.  He's honestly not trying to be a turkeyhead.

Cage had some freebies, compatible with Poser 11 and below.  His Python scripts were saved at archive.org, along with the rest of the Morphography site, where they were hosted.