Quote - (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.  :(

It could probably be compiled for other versions at some point, but I'm not going to even worry about that while it's changing so much.  Of course folks with Poser 4/5/6 are also missing various other forms of functionality/features that come with later versions, so that's nothing new... 

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

Actually, if you re-read what you wrote there, you'll understand what I was saying earlier - you seem to grasp the situation perfectly, but miss what it means... IF I was getting the vertex and tripoly indices from a list (as in the classic code), then you can pre-process that list all you want.  But since I'm not getting the indices that way - I just loop over all of them, so my index value is derived directly from the loop variable - if you remove some from the list, the "indexes" would be wrong.

To support parial lists, we either need to change CorrelateMeshVerts() to use a list of indices, or add another function that does that (it's planned, just not implemented yet).

Quote -
I'll need to refresh myself on the flipmap.  Hmm.  I did notice that the windex information was now returned in the HitPoints list.

You may or may not have noticed, but there's a new function now for creating the flipmap - FlipWeightIndexing() - which creates the same (flipmap) output as we used before.

Quote -
...snip....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?

If you look back into the flipmap creation code, it did a test and culled out extremely small weight values... the new C++ routine does the same thing, so if you're using a flipmap generated by FlipWeightIndexing() to create a morph, then it already has those culled out.

If you are doing something else and can point me at the spot in the code, I can give a better answer.

Cinema4D Plugins (Home of Riptide, Riptide Pro, Undertow, Morph Mill, KyamaSlide and I/Ogre plugins) Poser products Freelance Modelling, Poser Rigging, UV-mapping work for hire.