Quote - My impulse would be to allow multiple source actor selections, rather than trying to scan the figure looking for appropriate parts.  Then I would just loop through the selections, checking for morphs of the same name, looking up the new datafile for each set of correlated actors.  This would require a bit more attention on the user's end, but would presumably be less code-heavy and less open to various flaws or errors.  And since the user has a choice, it's more flexible than automatically checking all the actors which might be involved.

Works for me.  Just allow multiple source actor selections, but only a single target.

One of my goals was to remove as much reliance on the filenaming as possible and consolidating target actor info into one file helps accomplish that, but your code already has mechanisms in place to look for files based on actor names, so it's not that important vs complications it might cause you to get the info merged - just go with what you're comfortable with.

Also, limiting the bounding box for cross-actor scans is just an optimization and may not be worth the trouble for non-head parts (which typically have far fewer polygons) anyway.

So, having said that, on the correlation end of things, my remaining suggestion would be for you to treat previous matches as 'screened' vertices on the target mesh.  In other words, once you've written these out to the file, screen them out from subsequent passes.

I'm not looking at the code, so I can't talk in detail about the difference between 'screening' them out - BEFORE building the region list - vs just relying on the xpolys array, but that is the affect I'm after - previously matched vertices should no longer be included in the target vertex-region list for subsequent actor scans.  The xpolys/xpoints arrays will have BAD data in it from the previous scan relative to new actor scans - they need to be rebuilt for each new actor.

Again, the above is just an optimization... there's no need to look for hits on vertices that have already been correlated in previous passes.  However, it also shouldn't hurt anything, so the alternative is to 'reset all results data' for each new actor correlation pass (clear out, rebuild or re-initialize xpolys, xpoints, and any other 'results' type arrays).

For the morph transfer end of things, yes - allowing multiple morph transfers at once would really be handy!

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.