Quote - Just to clarify a bit... I AM still dot-checking the ray with the intersecting polygon normal, so it's not like the code is suddenly choosing opposite-facing polygons.

Speaking of which, 2 things...

1. on the "if hitpoint:" test... just to verify that, you might want to spell it out more as "if hitpoint.Valid:" - that does an explicit test of the variable that should only be true if the data is valid (the other way should be doing that internally, but... who knows).

2. some of the current "poor matches" (or poor weighting) may be where the ray-cast fails, so it's mixing in some of the close-vert method weights.  Without looking up the actual vertex indices, one way of testing that might be to:

if the ray-cast test fails, instead of falling through to the close-vert weighting code, comment that out for now and just set up a known condition (in other words, assign all of those to the first vertex of the mesh, with a 1.0 weight) - then you can see which ones are falling through the ray-cast test... are the ones in the eyelids falling through?  how about the ears?  etc.

I think I'm trying to test too many different things in one script, and not getting enough sleep.  :lol:

What a mess!  In trying to test your points from the above quote, I found one dumb error after another.  I really need to get more sleep.  Sigh.

It looks like you are very definitely correct.  :woot:  The uglies are coming from the close verts results which haven't been modified by the raycasting.  Which is actually bad, overall, I guess.  But it's good for the current .pyd raycasting process.  It means the only error I'm finding in it is that it fails to catch those areas I've mentioned.  Unfortunately no change I can make to available settings alters that fact.  Why it misses these areas, I'm not sure.  I probably shouldn't do any more guessing until I've had a solid eight hours' sleep. 

The uphill results with close verts alone have been coming out worse than I realized.  The area between the top of the eye and the eyebrow has been collapsing down toward the top of the eye, which effect isn't obvious unless the morph is dialed up, instead of having the 1.0 setting entered into the field on the parm dials.  The lacrimals have a tendency top go blooey.  I'd been looking for piggybacking as an indication of close verts failures.  Things going blooey is something I've tended to associate with raycasting, from years of experience.  :lol:  But, of course, close verts can make it happen too, in its own way.

So.  I'm glad you made me look at this.  Can you note any other significant errors or shortcomings that I may be overlooking? 

I'm still seeing a lot of dropped verts, but now I've seen them with the pure close verts approach, too.  I need to start working with a pristine copy of the last posted script, I think.  I've made too many testing edits to this one, and I'm afraid something I'm not seeing is in error.  Hopefully that will solve the dropped vertices.  If not... I don't know.  I'd never seen them before I started this recent testing, but I was also only rarely working uphill before I started with this testing.

So, again.  The only evident problem is that the raycasting is not catching the vertices in the problem areas I cited above.  Any idea why that could be? 

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