Cage opened this issue on Dec 20, 2006 · 1232 posts
Cage posted Sat, 22 March 2008 at 7:01 PM
(Post written off-line, before Spanki's most recent response...)
Yes, I think we might be able to avoid octree when using the _tdmt.pyd, which is a Very Good Thing, because a huge number of the complications with the pure Python ("classic"?) TDMT arise from trying to handle the octree zones. Octree requires a lot of sorting and unsorting and, at least potentially, multiple passes. (Is what we're using really "true" octree? Or is it something else, like the "quadtree" I've seen mentioned?) So far, this seems to be fast enough to lose all of that. Huzzah! But I fear for the ability of Poser 5/6 and Mac users to be able to have the benefit of this. :(
RE: materials. Can't you just pre-screen the lists to remove verts or tris which are associated with the materials to be screened? That's pretty much what the script does now. I guess the difference is that the "classic" script doesn't have us looping in numerical index order through verts and tris. We loop through pre-sorted lists which aren't in any sort of order that way. But anything that's screened is being removed up front, so there aren't added lists for the actual correlation processing. I may have misunderstood your post....
I'll need to refresh myself on the flipmap. Hmm. I did notice that the windex information was now returned in the HitPoints list.
For this shrinkwrap application, I need to take the actual collision locations and then make modifications to that, to smooth or restore certain mesh relationships or to add an offset from the collision surface. So I'm going to have to disuse the actual deltas which are so effectively being applied in the current test code. :(
BTW, the seven minutes result I noted was common only when looping through multiple actors (with all the octree complications in place). To really have a fair comparison against that, I'd have to test a multiple actor loop with the new code. More common was a time between one and three minutes, using the same geometry, but exported as a merged object and re-imported (same comparison without multiple actor handling). That's a huge slowdown, which is why I'm obsessing with multile actor handling. LOL
Hmm. How would I use the .pyd code to do our zero deltas check before adding a morph delta?
...
if delta:
...
if abs(delta):
...
Or something else? Do we need the abs() now, given that you've added the non-zero check for vectors?
===========================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.