Quote - I'm not sure I can speak specifically to this, but I do have some general thoughts on additional / future enhancements...

Ray-Cast-Only option...

More flexible dot-checking...

Additional Screening options for the Correlation process...

Several additions to the Merge process...

• Use the weight values from each file to regenerate the (psuedo-)hitpoint and use the 'closest' one.
• Maybe an option to favor 3 weights over >3 weights (the idea being that 3 weights are more likely to have come from a more accurate ray-cast hit).
• Just to cover all bases, maybe an option to favor >3 weights over 3 (the idea being to keep you from puffing up over my wording in the previous suggestion ).
• Don't overwrite any existing values, only insert new values.

You'd do well to watch out for my puffing up.  :lol:  It's a bad thing.

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.

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: 

If we're going to favor one option over another, I do think that should go both ways.  Say you want to be able to screen a comparison to isolate which vertices are missing the ray-casting, then visualize it by generating a morph.  Being able to favor the >3 would accomplish that.  It's a good suggestion.  One should also be able to favor < 3, or specifically 1.0 weights.  Some sort of numerical entry as a screen might be a good approach.  I'll mull it over.

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.

I'm with you on the ray-casting, although I'm not sure how you're thinking about it.  Disabling the writing of a close verts weight sounds reasonable, but the close verts approach is still being applied, as the ray-casting is now piggy-backing on its greater flexibility, using that as a method to steer the rays and reduce the number of tripoly checks.  :lol:  Earlier, I was proposing adding an option for the "pure" ray-casting, which has its own range of useful applications,  But disabling the writing of close verts weights is fine with me.

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.

Good ideas.  Thank you!  I was thinking more in terms of looping over the figure's unimesh or something.  :lol:  Hadn't expecting all of this.  :laugh:

===========================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.