Let me re-arrange these a bit...

Quote - On the additional screening, I rather hate using the bounding boxes and I don't know the math for the case of a spherical ellipse.  I think a morph used as a vertex screening "map", based on zero or non-zero deltas, would be potentially more flexible.  The Trimmer script uses this as Morph Subtraction, and once I finally adapt the Trimmer functions to handle .vmf files, those will be able to be edited that way.

Robert (IPP guy) came up with a neat way to handle the spherical zone weighting, so I might be able to dig that up at some point... but your other suggestion sounds interesting as well.  If I could create (for example) an Ear morph and then tell the correlation script to ignore (exclude) any verts listed in that morph, that would work.

Quote - ...How are the inserted values to be handled?  They will be redundant and replaced by the final ones for the same index which are read in from the file.  We'd end up carrying around excess data and potentially slowing the transfer step.  This is another option I can see as possibly useful for some kind of testing purpose, but not for general application.

Uhm.. either I'm misunderstanding your response or you misunderstood my suggestion :lol:...

File #1 has weight info for the following vert indices...

1, 3, 4, 5, 6, 7, 9

...File #2 has weight info for the following vert indices...

1, 2, 5, 6, 7, 8

...ok, now "merge" those 2 files, "inserting" any weight info found in File #2, that's doesn't already exist in File #1 and you'd end up with 2 and 8 from File #2, being "inserted" into File #1 (or creating FIle #3).  None of the other values from File #2 end up in File #1, because we didn't select any option that let's it overwrite existing values.

Does that make sense?  In other words, we're just "filling in" the missing weight info in File #1, with info from File #2.  There is no redundant data written back out to File #1 (or the output/resulting File #3).

Ok, so the other options I mentioned - making some decision on what to do with duplicate vert info - would decide what to do with those indices in File #2, where there was already data for them in File #1.  Currently, (my understanding is that) your script just replaces the info, without doing any other tests on it.  File #2 data currently takes priority over FIle #1 data.  I'm suggesting that some sort(s) of tests could be done to determine which data to use.  Again, no redundant info in the resulting output/merged file.

Quote - What is the presumed utility of the reconstructed "hit point", stored in a .vmf file?  I don't see the value of it.  It seems that you're really proposing a change back to the old .vwt format, and we've been through that.  :hoo boy: 

Again, remember that the (or my) definition of a 'hitpoint' is "the point you move each vertex too, when doing a shape-transfer".  This is also "the spot each vertex correlates to the other mesh". 
With that in mind, we do shape-transfers to get a visual indication of just how well the correlation is working (or at least, that's one benefit of doing them).  So, if you have 2 different correlation points for some vertex, you can compare them.  My guess/suggestion (though I could be wrong) is that the closest correlation (shortest distance to it) would be the preferred one to use.

So, I'm not (necessarily) suggesting moving back to the .vwt format, but since you mentioned it, I'm still unclear on your reluctance to list that additional data.   You seem all for options that may or may not be of any value, but you seem opposed to additional data that might be useful to have handy .

Quote - What are you considering, with respect to the dot-checks?  I agree that there's potential there, but I'm not sure quite what you may mean.

Just that currently we're testing for a deviation of <= 90deg (anything greater than 90deg off-axis is skipped).  I'm only suggesting that it's possible that other values might be useful in some situations.  I would consider this a "for testing" option, or at least an advanced option (assuming it gets an interface at all).  The current code tests for < 0 (less than 90deg), so the new code would just test for < input_value (supplied in the same format listed above.. the cosine of the angle).  So the routines in the PYD that currently take a "backface_culling" option would take that value, instead.  If you wanted to allow anything, you just use -1.0, then nothing is skipped (there are no cosines less than -1.0).

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.