Cage opened this issue on Feb 24, 2010 · 592 posts
Cage posted Thu, 25 March 2010 at 1:31 PM

The left image is a slightly more charitable version of the kablooey mess posted above. :lol: Here, I've had to keep the process from handling lashes, lacrimals, and inner mouth. There are still many areas where it fails. This illustrates how much the raycasting method needs closest vertices to fill in the blanks.
Look at the upper eyebrows, particularly, on the left image. The results here are presumably the best we can expect from raycasting under these comparison conditions. Any hybrid code would need to be able to recognize that they represent results which are worse, not better. Look at the right image. The closest vertices method produces something we can clean up with Restore Detail. The left image distorts the shape so badly that I'm not sure RD can help.
Now look at the middle, still considering the upper eyebrows. This is how the initial hybrid sorts out the two methods being applied. I've tested RD with these results, and it didn't handle very well. It can clean up the basic mess, but some areas of the upper eyebrows end up beneath the skin and others are badly pinched. They're no longer scrambled, but they're still not a desirable outcome.
Assuming the new .pyd hybrid code being tested is bug-free, the middle image shows the essential problem with trying to merge these two approaches. The raycasting is returning accuracy where it's able to do so, but it can't do so everywhere, as seen in the left image (and, even more so, the one posted earlier). The middle image, assuming no code bugs, shows how greatly the results of the two processes vary. They may not be readily compatible. The averaging applied by the closest vertices method gives results which the more accurate raycasting doesn't like very well.
But the raycasting obviously needs the closest vertices method to fill in the gaps. Even if we judge "best match" cases, how do we rule out disasters like the upper eyebrows? And the raycasting can't help us at all with a best match in places where it's altogether unable to even generate a decent match.
My musings to which you respond above are attempts to think ahead about these problems. The raycasting can't do it alone. The closest vertices comes much closer to being able to do it alone, but there are numerous flaws. We can't make the closest vertices as accurate as the raycasting. To bring these methods together, the accuracy of the raycasting may need to wiggle. Hence the suggestion of modifying the raycasting normals to try to generate hit locations compatible with the closest vertices positions. It's the kind of thing you'll hate, the kind of thing which gets rejected apparently out-of-hand. But something like that may be necessary. The final "hit points" would end up being closest vertices averaged positions, but those could be generated with only the tri weights. If all hits are generated this way, they should be compatible with one another. The results won't match those of the pure raycasting, but look at the pure raycasting's limitations, in this test.
One almost hopes that the hybrid .pyd code is bugged.
Apologies, Spanki. I only say that because it would mean a simple drop-in of one method might work out feasibly well. It really looks like the middle image just shows incompatibility, though.
===========================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.