I'm just thinking out-loud and on-the-fly with the above, due to the limited time I have right now.  I do agree that such a change would have wide implications for other parts of the script and I also agree that it's a complex issue that should be given some thought.

There are several separate, but related issues...

1. multi-actor (or cross-actor or actor-spanning) correlation data generation

In most cases, in order to get a 'complete' dataset for a target actor, you're going to have to include comparisons to multiple source actors ('complete' does not necessarily rule out or contradict the 'sparse' nature of the file format, but instead refers to 'coverage area' of all the intended vertices - we may not care that the eyelashes are included, but we want to make sure all of the neck is).

Due to the nature of this process...

a) due to the way the polygons and vertices are indexed, each new source actor comparison will generate actor-specific (or actor-relative) data.

b) the second actor scanned should (could) only need to fill in 'missed' vertex info from the first actor.

c) the third  (and each subsequent) actor scanned should (could) only need to fill in 'missed' vertex info from the previous actors scans.

d) the 'area' (region box) where these additional polygons are going to be found is in close proximity to the edge of the target actor mesh - ideally, a new bounding box, created from the currently missed vertices of the target mesh, inflated just enough to include a vertex of the polygon we're trying to hit out of the new source mesh - we probably don't need to look at ALL of the polygons of the new source mesh.  This is just a speed optimization.

2. morph transfer, including the potential for multi-source-actor data for a given target actor

Some morphs (nose-wider, ears-pointy, etc) are localized and will not involve multiple source actors.  Others (Muscular, Neck-wider, etc) will likely involve 2 but potentially any number of source actors (most parts have 2 other parts welded to them, some have one, the chest has 4, the hand has 6, etc.), depending on the area affected and how the bodypart groups are split between the two figures.

In either case, if cross-actor correlation data exists and the morph in question exists in the second (or third) actor, then that data should be used for the specified vertices to complete the morph transfer.

3. automating the above

Referring back to the above on the correlation data generation side of things, finding a solution that satisfies all of a,b,c,d at the same time (for an optimized automated process) is trickier than it seems on the surface (I'm betting on a "aha! - this is what he was getting at" moment sometime in your future ).  I don't really have the time to (study, understand and then) explain better what I mean about this, other than to refer you back to my comments earlier about the xpolys issue.

Automating the morph transfer side of the process will involve...

a) access to the (actor-specific/relative) data generated ealier (filename / file-format / number and/or location of files issues)

b) accounting for those differences when generating deltas for the new morph (by that, I just mean that part of the morph will come from one source actor, using one set of correlation data and other part(s) of the morph will come from other source actor(s) using separate correlation data).

c) if transfering multiple morphs at once, then a and b are multiplied.

4. file storage of cross-actor / multi-actor / actor-spanning correlation data

Whether or not the cross-actor correlation process is automated, the data needs to be stored somewhere, in some manor and format that is prefferably deterministic, or at least user-specifiable, so it can be found later by the morph-transfer end of things.

Obviously file reading / writing / merging support routines will all be affected, but I see those as being written in support of whatever the infrastructure is determined to be, based on the other issues above.

...so those are some of the separate, but related issues involved.  As stated earlier, the current script, using the current file format should be capable of doing multi-actor morph transfers - al beit in a manual, non-automated fashion.  Which means that most of the above is really only relevent to trying to automate one end or the other of the process.

I'm afraid that I just don't have the time to help work this out currently, but I hope the above at least helps outline what some of the issues are.  My only other additional comment / suggestion at this point would be to repeat what I said earlier... once you have good correlation data for two figures, the focus / interest / usefullness switches over to the morph-transfer end of things, so if I was looking to automate one side or the other, I'd favor that side.

Cinema4D Plugins (Home of Riptide, Riptide Pro, Undertow, Morph Mill, KyamaSlide and I/Ogre plugins) Poser products Freelance Modelling, Poser Rigging, UV-mapping work for hire.