Cage opened this issue on Feb 24, 2010 · 592 posts
Cage posted Thu, 04 March 2010 at 4:21 PM
Quote - Is the time-consuming bit the one where for each vertex of mesh A you identify the closest vertices in mesh B?
If that's so, one idea to speed things up is using a grid like you would on a map (only in 3d, of course, so the grid cells would be cubes instead of squares). First you preprocess mesh B and for each cell in the grid you store the list of vertices in B that it contains. Then when you look for nearest neighbors of some vertex in A, you only need to look at the cell that vertex falls in and possibly its neighbors. If you space your grid cells right, you can be certain enough not to miss anything, but you'll only have to do a fraction of the distance computations.
Aha! We had this built into the old, pre-pyd version of TDMT. We were (probably inaccurately) calling it an octree process. It can help, but there are potential complications with any vertex which is near the edge of a sector. The solution we had was to run the comparison twice, first with sectors which don't overlap, to catch the majority of cases. Then a second time with slightly enlarged, overlapping sectors to try to catch anything which had been missed near the sector edges.
I've been hesitating to implement this again, in part because Spanki was so pleased that the pyd allowed us to get rid of it, in part because my implementation is rather messy and I'd end up having to create separate code for pyd processing and non-pyd with this "octree" in place. 
But it's a good idea, which can definitely speed things up. I'll start thinking about how I might be able to implement it more efficiently than in the past.
Any thoughts on the possible use of an external application? Is that too awkward, or tacky and frowned-upon in programming circles?
===========================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.