Quote - Yeah, yeah - but can't a guy have some fun?   As mentioned earlier, I don't recommend porting this to the python code just yet, but at some point it could be.

The changes this time were... monkeying with the normals :).  The normal of the target mesh vertex (and thus the ray being cast) is averaged with the normals of all the closest vertices of the source mesh.  This is similar to an earlier suggestion you made, but instead of aiming at the 'position' that that method generates, it skews the ray more in the (average) 'direction' that that (cummulative) surface faces.

One thing to note about all of this is that - due to the tiny distances involved with very closely lined up meshes - the ray doesn't travel very far (in whatever general direction it's heading) before it hits the other surface, so the affect will be different if one of the meshes were scaled slightly (for example) - which might actually be an interesting test, btw.

I'm actually a little suprised at how well the brows worked out, but we already know that the non-ray-cast method works best on those, so they can be done as a separate pass.

As for the lumpiness in the forehead and outer-brow areas... I'm pretty sure that it's a general "UpHill" issue (hires vs lowres mesh). I'm still trying to come up with some way to address that but one of the problems is (as mentioned way back in the start of the previous thread), at the level where decisions are made, "shape" of surfaces/vertices are fairly indistinguishable from "smoothness" of said shape.  Having said that, I'm still a bit confused on why it's more "lumpy" than "flattened, to the lower-res polys", as I expoected.

Interesting.  Normal-monkeying has apparently helped, but there's still some messiness.  Have you tried using the normalized delta between the Target vert position and its weighted match destination?  It's a similar idea, but I'd think it would be more controlled.  :unsure:  That may be because I can visualize it better.  :lol:  I mean, we know where the vertices end up, after a shape match, and we know that's the direction in which we want to steer results, to some extent.  I'd expected that the results would improve as the number of influences increases, just as they do for the close verts process.

I tried to adapt the idea I posited myself, using the available .pyd functions, but: - It was slower than muck

• It didn't work

(Ha ha.  I have the power of bullets.  :lol:  I abuse my power.)
Yeh, it didn't work.  If you add the option to send a normal to the new .pyd function, it opens up possibilities.

I've been beginning to hope we wouldn't need any separate passes.  :lol:  Are there more possibilities to test?  Or it this the best possible result?  It's still going to need some cleanup, and I'll need to do some testing with morph transfer to be sure the results are cleaner than the shape transfer.

I'm used to dropped correlations with raycasting.  :lol:  Is it possible that there was a false positive for the "if hitpoint" test?  Any case in which a hitpoint could be detected but then not valid somehow?  I didn't track down the vertex index so I could look it up in the .vmf file, so I'm not actually sure there was no weight.  I know that there was no discernible delta created for the vertex.

I guess the lumpies are a good reason to keep Restore Detail around, then.  :lol:

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