Uh oh.  So we'd need a special Mac-specific .pyd?  Hoo boy.  All the more reason to get my revised release out, I suppose.

I believe Tkinter is working for P7 on Mac now, finally.  I'm not sure about previous versions of Poser....

I've tested your file, and it works nicely.  :D

Cool.  I structured the code in a way that should make it easy to tell, for example:

"if I used to do X, to accomplish Y, I can now do Z to accomplish the same thing"

...as mentioned earlier, 'Z' is somewhat of a moving target at the moment, as shown in one particular example in the file:

    # each of the following do the same thing, just progressively more efficient/faster
    # point = Vector(v.x + (ray.x * intersect), v.y + (ray.y * intersect), v.z + (ray.z * intersect))
    # point = v + ray.scale(intersect)
    point = v.project(ray,intersect)

...as new functionality is added, there may be new (and/or faster) ways to do the same thing.  On a related note,  because the new keeps track of the face normal and plane equation, those tables don't need to be built (or passed to the test routine) when using this extension.  (BTW, I noticed that I didn't do a "pplanes = []" after the Numeric test run, but that shouldn't hurt anything).

[EDIT: those (separate) tables don't have to be built or passed to the routine, but you do have to call the Generate_TriPoly_Normals() routine to get them generated in the TriPolys structure]

Hypothetically, Python will just garbage-collect those list references once they no longer appear in the code.  I don't know that you actually have to clear them at all, unless you've set up something that keeps them lingering in some way I don't understand.  I was doing a lot of experimental list-clearing in the early stages of TDMT, because I kept setting up reference looping without realizing it.  I think that's under control now in TDMT, and as far as I can tell, it shouldn't be a problem in your test script.

You said to do nothing, but I can't resist trying to port a simplified version of shrinkwrapping to this temporary .pyd, just to see.  We'll see what happens....

Right, the built-in garbage collection will handle things... my only reason for wanting to do it explicately is to include the time it takes to do it in the timings (since the new code doesn't have to delete some tables that never got created).

And yeah - feel free to experiment all you want with the extension - that's an excellent (and perhaps enlightening) idea/use of your time! :)  I was just advising against doing an overall re-structuring of TDMT until more is known about what will be available to you to work with :).

One thing that's not present right now is normals for vertices.  Easy enough to generate using Python code, anyway.

The mapping of the polys to tris is very useful! 

I'm wondering: can I do += with your unary operations?  As below:

def vertnorms(vpolys,pnorms):
    """
    [Spanki]
    normals of vertices, computed as the average of the face normals of the polygons which use each vertex
    returns a Numeric array
    """   
    vnorms = [Vector(0.0,0.0,0.0) for i in range(len(vpolys))]
    for vi in range(len(vpolys)):
        polys = vpolys[vi]       
        l = len(polys)       
        if l == 0: # In some unusual geometries, there may be vertices with no polygon associations - we try to skip these.  1/26/08
            print vi, l
            continue # If we don't skip these, we get a divide by zero crash error due to a bad mesh.
        for p in polys:           
            #vnorms[vi] = vnorms[vi]+pnorms[p] #Can we do += with Vector objects?  
            vnorms[vi] += pnorms[p]  # Can we do this???   
        for i in range(3):
            vnorms[vi] /= l       
        vnorms[vi] = ~vnorms[vi] #is this correct?
    return vnorms

Quote - Right, the built-in garbage collection will handle things... my only reason for wanting to do it explicately is to include the time it takes to do it in the timings (since the new code doesn't have to delete some tables that never got created).

...just to further expand on this (FYI and/or future-reference), keep in mind that due to the nature of the structure of Python ("every item is an object") and also because of it being an interpreted language, some relatively-trivial/harmless-looking things can actually take many cycles to accomplish.  Ultimately, each element of data is managed by some piece of compiled C code (like this extension).

So, the code that handles a 'list' object knows how to deal with the list of objects, but doesn't really know (or care) what those objects are. - some other module has to handle them.  This means that internally, when the list-handler goes to delete the list (assuming all reference counts or zero), it iterates over the list, calling the delete function of each object's handler.

So, if this is a list of 100,000 objects (for example), the list-handler would call my delete routine 100,000 times.  In the case of my , I also store a reference to a normal (which is a object), so my tripoly handler would also call the vector handler's delete function for each item being deleted.

The above may not be exactly how thnigs happen (many steps left out), but is just to give some idea of how things are happening 'behind the scenes', which can help explain why deleting a list of objects may potentially take a not-insignificant amount of time :).

Quote - One thing that's not present right now is normals for vertices.  Easy enough to generate using Python code, anyway.

Right.. we needed the face normals (and some sort of neighbor info) before doing vertex normal calcs, so we just hadn't reached that point yet.

Quote - The mapping of the polys to tris is very useful! 

I'm wondering: can I do += with your unary operations?  As below:...

To be frank, I was wondering about that and am not sure - let me know how that works out for you :) (it should either work, or cause and exception, so it's easy enough to test).  If it doesn't work, I have an idea of how to possibly implement it.

vnorms[vi] = ~vnorms[vi] #is this correct?

Yes.  I implemented the ~ operator to mean "return a normalized (unit) vector".

Looks like the += / *= thing works with Vectors...

>>> from _tdmt import *<br></br>
>>> v1 = Vector()<br></br>
>>> v2 = Vector(1.0, 2.0, 3.0)<br></br>
>>> v1<br></br>
Vector at <012941A0> = (0, 0, 0)<br></br>
>>> v1 += v2<br></br>
>>> v1<br></br>
Vector at <01294320> = (1, 2, 3)<br></br>
>>> v1 *= v2<br></br>
>>> v1<br></br>
Vector at <01294300> = (1, 4, 9)<br></br>

*"after deleting all pyc files and replacing tdmtUtility.py, I get a slightly different error
after clicking the transfer shape button.  python scripts didn't work in versions
of poser prior to v.7, but most of 'em that I've tried now work."

Most of them - except for TDMT.  Right?  Right?  Cough.  My apologies for  the ongoing problems.  It looks like Macs just do not like the Flush() call.  Hmm.  Note that we're getting the same complaint, but from a different part of the process.  So evidently TDMT needs to check for Mac and only use calls which cause problems (like Flush()), when we're on Windows.  That's not too difficult, hopefully.

If you're feeling adventurous, you can open the file specified in the error message and simply comment out the error-producing line (put a # sign at the beginning of the line).  Then you'll have to do the .pyc deletion again, and reinitialize Python so it won't keep using the old versions stored in its memory.  Otherwise, I can hopefully get something together for posting tomorrow.

My apologies again for all of this.  I've never had to interface with Python on a Mac before, so I honestly have no idea what to expect here.... 

@Spanki - good news, then, about +=, etc.  :D

Removed because Cage figured it out.  Stupid question.

I also wondered about scalar math for the vectors.  That could be useful, presumably....

This is really rather exciting.  :D

Actually, I'm not sure I did figure it out.  Dang.

Okay.  In the .pyd readme, does:

v1[0] = 1.0                 # general-purpose indexed access
v1[1] = 2.0
v1[2] = 3.0

indicate that the values for the vector are settable?

That's my dumb question, basically.  If they aren't, the only method for setting the vector would seem to be copy on another existing vector, or creation of a new vector.

And... I was wondering if the vector instantiation could receive a list or tuple.  This isn't a biggie, but if one has coordinates in an iterable container one would need to unpack the values right now in order to instantiate a vector object.

Oh - and you mention using the .pyd in other applications.  This would work?  Neat.

And, my really seriously nagging dumb question: what on Earth was John Nathan-Turner thinking, when he added Peri as a companion?  Holy hopping Bofur-blocks.  I mean, she's even more annoying than I am.  Whine, whine, whine.  Did Jo ever whine?  No, not that I recall.  Zoe?  No.  Sarah Jane?  No.  Tegan or Nyssa?  No, not to my recollection.  Grumble.

Yes, the vector/vertex x/y/z values are directly settable.  Currently, you can't use a tuple or list though. That's planned for a future update, but will require something like the following, once implemented:

v1.Set(vertlist[vNdx])

...( assuming vertlist[vNdx] looks like this: [0.0, 0.0, 0.0] ).

They're settable!  Good.  :D  :D

I think I tackled too big a test for the .pyd today.  I got about halfway through porting the shrinkwrap code and had to take a break.  I think I should start by just implementing the code during the slow part, the collision handling, for the time-testing sort of business.  It did feel good to get away from calling the Geom module so much, when adapting the code....  I've gotten a lot of mileage out of Geom, but it's really a bit snarled and tangled and what-all....

Click outside the Poser window (such as on the Windows toolbar) to take the focus away from Poser, whicle this runs.  That will speed it up.  I've used ProcessSomeEvents to keep Poser from freezing while we run, but that slows us down is Poser has focus.

Select the actors when instructed.  It's best if the shrink actor (first one selected) has no world transforms at the time of the run - otherwise, those will get baked into the final position for the morph (not sure how to fix that).

And this uses the whaddayacall Trumbore method.  Sorry Spanki - it was easiest for a quick test.  More later.

o.k., I'll await word on the updated version for OS X.  cage, I'm unqualified to edit the file in question,
as I dunno which file (nor which line) to edit. :crying:

Quote - Here's a quick test of the .pyd, doing shrinkwrapping. ...

I hadn't tested it yet, but here's a better version of vertnorms() for you...

def vertnorms(vpolys,pnorms):<br></br>
    """<br></br>
    [Spanki]<br></br>
    normals of vertices, computed as the average of
the face normals of the polygons which use each vertex<br></br>
    returns a Numeric array<br></br>
    """<br></br>
    vnorms = [Vector(0.0,0.0,0.0) for i in
range(len(vpolys))]<br></br>
    for vi in range(len(vpolys)):<br></br>
        polys = vpolys[vi]<br></br>
        numNorms =
len(polys)<br></br>
        if numNorms ==
0:           
# make sure we have some normals, so we...<br></br>
           
print vi, numNorms<br></br>
           
continue                
# ...don't divide by zero crash due to a bad mesh.<br></br>
        numNorms = 1.0 /
numNorms    # convert numNorms to inv_numNorms, so
we can multiply instead of divide<br></br>
        for p in polys:<br></br>
           
vnorms[vi] += pnorms[p]<br></br>
        vnorms[vi] =
~vnorms[vi].scale(numNorms) # get average (multiply by
inv_numNorms) and make into a unit vector<br></br>
    return vnorms<br></br>

...mostly, I just replaced the single-letter 'l' variable with 'numNorms' (for clarity) then inverted it, so we could multiply by it instead of dividing, then passed that to the vector.scale() method, normalizing the result.

Hmm.. I'm not positive of the precedence rules in Python, so you might need to do:

vnorms[vi] = ~(vnorms[vi].scale(numNorms))<br></br>
...instead of:

vnorms[vi] = ~vnorms[vi].scale(numNorms)<br></br>
...the parens would make sure that the scale() operation happened before the normalizing - in either case, it's more clear to the read what you 'want' to happen (once they understand that the ~ operator is being used to create a unit vector, at least) :).

*"I hadn't tested it yet, but here's a better version of vertnorms() for you..."

Right on!  I'll try it with the new alterations.  It's fast.  Not quite fast enough to get rid of the octree, but pretty fast compared to running the straight Python version.  :D

I still haven't run your script, but I did notice this...

class myMesh(object):<br></br>
    def __init__(self,geom,meshtype):<br></br>
        if meshtype ==
"vert": #verts, vnormals<br></br>
           
self.verts = getVerts(geom,1)<br></br>
           
self.pverts = getPolys(geom)<br></br>
           
self.vpolys = vertpolys(geom,self.pverts)<br></br>
           
self.pnorms = getPolyNorms(self.pverts,self.verts,1) #Normals for
not-triangulated polys<br></br>
           
self.vnorms = vertnorms(self.vpolys,self.pnorms)<br></br>
           
#self.pverts = self.pnorms = self.vpolys = []<br></br>
        if meshtype ==
"poly": #verts, pverts, tverts, pnormals, planes<br></br>
           
self.verts = getVerts(geom,1)<br></br>
           
self.pverts = getPolys(geom)<br></br>
           
self.tverts = getTriPolys(self.pverts,1)<br></br>
           
self.vpolys = vertpolys(geom,self.tverts)  # <--- ** BUG **
vertpolys() doesn't deal with TriPolys<br></br>
           
Generate_TriPoly_Normals(self.tverts, self.verts)<br></br>

...note the ** BUG ** line above.  Fortunately, you don't need to call vertpolys for that mesh, so you can just comment that line out (or better yet, delete it).

It looks like your alterations to the vertnorms function work very nicely.  No precedence issues.

Just to clean things up, here's the script with the alterations Spanki has pointed out....

Note that when I comment that this script isn't fast enough to do away with the octree, I'm commenting on point-in-tri handling which uses the .pyd for faster math but doesn't use a compiled point-in-tri function from the .pyd for the really slow calculations.  It will be even faster with a compiled (and optimized, as Spanki's point-tri code is, compared to what I used) test for the triangle collisions.  We'll probably still want octree for dense meshes....

Here, try this one.

I re-wrote the shrink_wrap script to use some new features (I used the same filename as earlier "Spanki_pyd_shrinkwrap.py", so you might want to copy off your old one, but it looks like you are using a new name now anyway).

See the readme file for details.

....oh, btw, I also changed some variable names around to help make things more clear -'pverts' and 'tverts' have always confused me, so they got named 'ngons' and 'tpolys', respectively.

If I think about it, I can understand why you call it 'pverts' / 'tverts', as it's the indices of vertices that make up the polygon, but - that's exactly what a polygon/ngon/tripoly is - a storage mechanism for holding indices of vertices that make up the polygon :).

The link took me to the .pyd download!  I assume it's the same .pyd (it has the original readme).  I'd like to see the script changes....

I won't quibble over names.  ngons and tpolys are fine with me.  :D

It should be a new .pyd zip file, with all new files inside... is it not?

EDIT: D'oh! sorry... try downloading it again.

Got it!  I'll take a look!  :D

Wow!  Nice additions!  Now I don't have to write kludgy functions to cover those things!  :D :D

And I was redundantly calling up the vert before setting it, huh?  D'Oh! 

Quote - And I was redundantly calling up the vert before setting it, huh?  D'Oh! 

 
...you mean, down in the shrinkwrap routine?  Yeah, v was already pointing at it :).

Okay.  Two questions.

1. Is it bad to have an option to fill verts with the localspace vertex coordinates?  These are sometimes useful, or even necessary (as when creating a morph which doesn't bake in the worldspace positions).

2. Is there any reason not to allow vpolys for tris, or is that simply not added?  I've had cases where the vpolys list for... tpolys, as you call it, has been useful.

I'm really pleased to see the distance functions ported over.  I was considering using squared distances for something, recently, because I was afraid the square roots would slow things. 

You know... I don't know this.  What does the abs function do when applied to a vector?  Just return the abs value of all the vector values?  Or is it completely different?

Quote - Okay.  Two questions.

1. Is it bad to have an option to fill verts with the localspace vertex coordinates?  These are sometimes useful, or even necessary (as when creating a morph which doesn't bake in the worldspace positions).

Just not there yet.  But I'm not sure the example you give makes sense :).  A morph is computed as a delta - from wherever the verts happen to be, to some new position, relative to there.

Quote - 2) Is there any reason not to allow vpolys for tris, or is that simply not added?  I've had cases where the vpolys list for... tpolys, as you call it, has been useful.

Just not there yet.

Quote - I'm really pleased to see the distance functions ported over.  I was considering using squared distances for something, recently, because I was afraid the square roots would slow things. 

You know... I don't know this.  What does the abs function do when applied to a vector?  Just return the abs value of all the vector values?  Or is it completely different?

 
Yes, the fabs() of each element.  Frankly, I'm not sure how usefull this is, but it was already implemented as such, so I left it.

Okay.  Good, good, and good.  :D

Maybe I've gotten myself confused.  In the shrink-wrapping script (the larger project, not the trimmed .pyd version), I generate the new vertex positions using initial worldspace locations.  I found that if I then generated the morph deltas using the same worldspace positions, any worldspace displacement could end up baked into the resulting morph.  To overcome that, I had to generate the deltas using the original base geometry vertex positions.  I may have muddled things while experimenting and ended up taking unnecessary steps?  This is more a problem of actor-level worldspace handling than of mesh-level (that is, world transforms versus shape changes via deformers or morphs).  Worldspace gives us the new surface shape for the mesh, but also the repositioning due to transforms.  I guess I'm having trouble sorting all of that out effectively, which is what prompted my question.  But, too, if I have morphs set before the comparisons, they get baked into the result if I don't use the base geometry positions to sort things out.  Did I explain that badly?  Probably.  Cage needs sleep.

I'm wondering about mapping polys/tris (verts?) between actors.  If we can virtually merge our geometries before running the comparisons, my tests seem to show that we'll run much faster than if we loop through multiple actors.  Would it make any sense to have the ability to merge the data internally for multiple geometries, then be able to separate it again at the end?  Did I explain that badly?  Probably.  Cage needs sleep.

As for the world-space, deltas issue... yes, the deltas would include any scaling or morphing used, unless you subtracted those deltas from the orginal shape.

Quote - ...unless you subtracted those deltas from the orginal shape.

should read: "...unless you subtracted those deltas from the [new deltas]".

"...unless you subtracted those deltas from the [new deltas]".

Right.  What's really happening when you fill the verts list?  I suppose one could just generate a list of vector objects as before, in your earlier example, using worldspace or UVs or whatever we haven't accomodated.

Don't mind me.  I'm trying to grasp a new system and its parameters.  I'm very pleased with all of this.  I'm still trying to understand how my current approaches will need to change.

I have a copy of your unimorph script, and I've pulled it out to think about it now and then.  A process like that could be useful for multiple actors in TDMT.  In shrink-wrapping, I also need to be able to accomodate actors which aren't part of the unimesh for a figure.  Or perhaps there's no figure at all, and I want to shrink a sphere around two spheres and a cone.  I don't know.  At any rate, I'm thinking about an indexing method similar to but more flexible than the unimesh indexing.  Hmm, hmm.  But wait... don't read this paragraph, okay?  Because I'm going on about it after you told me not to carry on about the matter....  Cough.

All is well.  :D

Heh.. carry on all you want - I'm just forewarning you why I may not be much for conversation on the topic (aside from neededing to stay focussed on what I'm working on, I'm really not even supposed to be working on this right now).

On the vert list thing, yes... I'm just doing exactly what the old python code was doing and it's not even much of a speed gain - it's just a convieniance function, so you don't have to have it in the python code.  And yes, you could continue doing it in Python for any vertex types not yet supported.

My only other concern/reason for providing those type of routines is because some of my other routines require data in that specific format, so I wanted to provide routines to format the data that way (if someone starts passing in data formatted some other way, it'll crash).

*"My only other concern/reason for providing those type of routines is because some of my other routines require data in that specific format, so I wanted to provide routines to format the data that way (if someone starts passing in data formatted some other way, it'll crash)."

*Yes.  I had to go through a lot of rather gruesome jiggery-pokery (if jiggery-pokery can be gruesome - who knows?) in the Geom module for just that reason.  Some lists require others as input.  In the end, it can become terribly confusing, which is why I built the "recipe" approach into Geom.  Well, that and because I had no idea what I was doing at the time - and perhaps still haven't!  Hmm.

You've been putting in more time on this in the past few days than I expected.  A big THANK YOU is appropriate, I think.  Many thanks, Spanki.  :D  Just don't neglect important stuff or, worse, burn yourself out. 

Ok, I really need to go do some other things now, but I just couldn't help myself....

New:

CorrelateMeshVerts()
and

...see readme and shrinkwrap script for details... have fun!

Wow!  Now that is... amazingly fast!  Whoa!  And seriously cool.  In my tests, it almost looks like it doesn't need any octree regions.  Of course, I haven't tried thousands of verts against thousands of polys yet....

I'll see if I can add my altered normals to the process.  It might be neat to have the option for spherical, cylindrical, box, capsule, and planar normals-casting for this.  (The only trouble being that my capsule type is really a major hack....)

This is most excellent, sir!  :D**100

numverts:  4062
 numhits:  4062
8.33699989319

Timing test for a 4062 vertex sphere prop against the Vicky 1 head geometry (with the neck hole capped off).  Eight point three seconds!  Holy guacamole!

I do use the passed in vertex normals, as well as he tripoly normals found in the tripoly structs, so yeah, you should be able to alter either/both of them before-hand.

Quote - numverts:  4062
 numhits:  4062
8.33699989319

Timing test for a 4062 vertex sphere prop against the Vicky 1 head geometry (with the neck hole capped off).  Eight point three seconds!  Holy guacamole!

:)   How does that compare to your python code above there? (comment out your process_events and DrawAll() calls to make it fair)

New timing tests.  It was a little slower this time.  (Why?  Transient conditions on my computer?  A matter of what else happens to be distracting the processor at the time?)

numverts:  4062
 numhits:  4062
8.50500011444 - .pyd CorrelateMeshVerts()
199.137999773 - Python whaddayacall Trumbore method (what's the name again?)

That's the raw result for time.time() - sTime.  So, let's see... divide by 60....

About 14 seconds for the CorrelateMeshVerts and 3.3 minutes for the Python method.  Is that right?  I always get mized up when I try to do base 6 conversions.  Hmm.

Now, the original old method, without even using the .pyd at all... took much longer.  I don't have code to test this.  I've added the octree handling into all my pre-.pyd code for shrinkwrapping....  It was slow.  Even with octree at 4 divisions, this test would take perhaps... four minutes?

I'm pretty sure that time() - stime just gives you the total elapsed number of seconds.  So the CorrelateMeshVerts() version is just 8.5 seconds, vs 199 seconds for the python version.

199.14 seconds divided by 8.5 seconds = 23.43 times faster.. not bad.  When I first tested this, my biggest impression was that the looping through, creating the morph was still a significant portion of the total time - I bet if you commented out that portion (or moved the stop time up to just after return from the call), you'd see that the CorrelateMeshVerts() is only taking a fraction of a second.

With my other test script (vector_test.py), I was/am seeing 50x - 200x (or more) speed-up pretty consistantly on large vert-count meshes.

I'm impressed by the speed gains already!  But... if I comment out the morph creation, the test is almost meaningless, isn't it?  I mean, the point is to create the morph, so the valid timing should include that part of the process.  I guess I could glom it all into a list and run that part separately, to simply time the collisions themselves.  Hmm.

This is very much a Poser 7-specific .pyd build, isn't it?  A separate build would be needed for Poser 5 or 6 compatibility.  I've been wondering about that, as I ponder potential implications of porting TDMT over to the .pyd.  Unless there are builds for Poser 5/6 and for Mac, we limit who can use the script....

Yes, not creating the morph defeats the purpose of the script :).  I was only suggesting that that portion of the script was still taking most of the time (and would likely go away if that portion also became a C++ routine, at some point).

And yes, this .pyd file is compiled for Python v2.4.  And likely won;t run with any other version of Python.

New one: tdmt_pyd.zip - see readme

Yay!  Cool!  Now I can put in the .vwt export as well as alternate mapping types.  This is already pretty close to being the foundations for a new TDMT.  It only needs material screening, .vwt export, and morph transfer to be a much lighter and faster version of the original.  Well, and (optional?) octree, I suppose....

I thought you were going to work on your other stuff.  LOL  Don't neglect the important stuff, now.  :D  Mind you, I'm not complaining one bit about having a newly updated version....

Woo!  This is fast.  Even without octree, the .pyd is running in twelve seconds the same correlations which were taking between one and seven minutes for me previously (longer for multiple actor looping).

I'm going to perseverate on multiple actors for a moment, because that's my next test.  It looks like the way to do it right now is to get the full set of correlations for each source actor in a group to the target actor.  Then sort through those to find the best matches, based on the lowest distances.  This will surely be faster (thanks to the .pyd) than what I was doing before, but I'm wondering if there will be any RAM overhead issues.  There will end up being multiple complete data sets for the hit points, corresponding to each source actor, which amounts to a lot of data coming in up front which will just be discarded (but when have I ever complained about that before, eh?)  So that's what I'm going to try.

I have the different shrink types worked in, but there script is currently a bit of a mess because I haven't ported over all the core to the new form.  So I hope to have a version to post tomorrow, which you can decide whether or not to make the one that gets passed in the zipfile....  :unsure:

re: .vwt files...

I'm not sure if you looked into this yet or not, but the old 'Windex' array is no longer needed... you can get the tripoly indices from the tripolys stashed in the new HitPoint(s).  Also, the flipmap array would still need to be created... but that code would also need to be re-written to use the HitPoint data (I might do a flipmap routine in the .pyd file, but I think I'll leave the file-reading/writing to the Python code, so it's easier to change in the future).

re: screening...

I'm personally hoping to avoid doing the octree thing (I had some problems in my other C code with those, but I never looked into it because they weren't really needed).  The material screening is a different matter... it's needed, but not supported with the current CorrelateMeshVerts() routine (the current routine looks through the entire poly and vert lists, and gets the pNdx/vNdx values from doing that - screening (and/or regions) requires looping through a separate list(s) of indices - and material screening happens to those lists).

Twelve seconds vs seven minutes eh?  That's (up to) 35 times faster - not bad :).  I don't have any answers to your multi-actor question(s) because I haven't taken the time to think about the best way to do it yet, sorry.