More fun...

Update: 03/22/08 (search on: "03/22/08" to see changes)

• fixed another reference count(s) in a few places to plug some memory leaks
• added psrTexVertexList()
• added psrTexPolygonList()
• added FlipWeightIndexing()
• added a (currently optional) 'texvertexlist' arg to TriPolygonize()
• added uv0, uv1, uv2 texture (UV) vertex indices to
• ...I don't think I made any changes to the scripts - hell, I didn't even test most of these changes yet - let me know how/if it works :).

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

BTW, I'm going to flip-flop on the above... the correlation is indeed taking most of the time (not actually creating the morph, as I had supposed).  I was misled by the speed things happened when the DrawAll() was still in the loop (which slows things to a crawl).

I guess I shouldn't post stuff (without testing) when I'm headed to bed... something broke in that latest download.  I'm looking into it now.

Ok, let's try a...

Round 2: 03/22/08

• I guess I should sleep before posting (or at least not post un-tested code)...
• fixed bug(s) in new tripoly update
• fixed bug in TriPolygonize() (introduced with the new optional texvertexlist arg)
• Updated Spanki_pyd_shrinkwrap.py to 'undeform' the deltas (world-space vs local-space issue that's had Cage losing sleep for ages now :))

...same link as usual.

(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?

How do you solve the worldspace vs. localspace matter?  Because, as I note above, one may want to alter the hit point locations before setting them.  What's the trick?  I couldn't figure it out.  (Sigh.)  Does it involve matrices?

Grabbed the new one.  :D  :D

I'm just passing through, so I'll answer in more detail later, but the world vs local problem is a one-liner at the bottom of the python sample script file... you can see it (and the explaination) there.

The attached adds "mapping" types, offset from collision surface, and multiple actor handling.  The multi-actor is basically what we'll need in TDMT to get rid of any issues with neighbor edges.  With these new additions, I was able to do a more valid timing test.  This script handled the comparison which took seven minute before in 23 seconds.  Not bad.  :D  No need for octree that I can discern.

One question: I thought distance was always a positive value, but the distances returned by HitPoint can be negative.  Have I misunderstood something?

The multi-actor function will select actors which fall within the bounding box of the target actor.  Actually, this needs some tweaking.  I have been checking actor center distances from the bounding box to screen out actors before I do any intensive checks on any of them, but this can miss some valid actors.  So I need to re-work the process.

I haven't added .vwt handling yet.

Also, the lower cap on the capsule mapping type is broken.  My approach for capsule mapping is a bit of a kludge, really, and needs to be corrected.  I think I have the math reversed somewhere in the process, for that lower cap.

I'm still curious about the if delta versus if abs(delta).  Right now I have that part commented out, wehere I would have applied it, and I use the old FLT_EPSILON test.

Thanks, I'll check the new script out and think about some of your questions.

This may be a bunch of partial posts/answers....

re: negative distances...

Ok, the short answer is that you're right - distance values are typically inherently always positive - getting the length of a vector always returns a positive value.  The longer answer is that this particular distance value is not generated by geting the length of a vector, it's used to create the vector in the first place :).  In the original code, we computed the intersection distance as follows...

intersect = (pplanes[pdx] - ndotv)/ndota

...which can be negative, as it is also used to determine a direction, and used to build the actual intersection point...

                point = [v[0] + (ray[0] * intersect),
                         v[1] + (ray[1] * intersect),
                         v[2] + (ray[2] * intersect)]    #ray_segment(v, ray, intersect)

...(which would now be performed with this extension like so:  point = v.project(ray, intersect) ).  We later do abs() comparisons with the matchdist variable, and used that to keep track of the closest match.   Once done looping, we used matchdist to re-create the intersection point (so it still needed to have a sign/direction), but in the old code, we never really stored/returned it as a distance - we just stored the actual intersection point.

So, the new C++ code is based on a similar functionality, except that it now stores/returns the value as the hp.HitDist member.  Of course we also have the actual intersection, so we don't need to keep the sign of the distance anymore, but it is being used internally to "prime the internal matchdist variable" if there's a pre-existing value there (if that vertex gets passed through the comparison routine again).

My current thought would be to leave it as is for now and just document the fact that it can be negative.  I guess it may be a point of semantics... it might better be described as a 'scalar', but what it represents is both the distance and the direction (either positive or negative, along the vertex normal) from the current position to the intersection point.

Aha!  Good answer.  Thank you.  The ah, whaddyacall-Trumbore (dang, I have to backtrack to look up the proper name you gave me) code was using a returned distance value in the collision loop, and I just assumed this would be the same.  I hadn't really thought it through in terms of what I (might) know about your process.  So I did the right thing, in simply doing abs() for the value.

I would just leave it and note the potential for a negative value (if not explain what it represents), particularly if it can be more useful somehow in its current form.  Hmm.  As both distance and direction, it could be added to the vertex position as with vector.project.  This is basically both arguments you'd use in project, pre-glommed together.  Right?  (Note to self: stop asking more questions.  There are already too many of them.)

Yes, it currently provides more information than just the distance, so it might have some other use later... I need to think about it some more.  And heh, yeah, I'm trying to get caught up on your other questions (which might answer some current ones). :)

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.

Quote - Okay, the local-world thing was simple...

Just one comment on this, to note that whether you 'add' or 'subtract' that local->world delta from the hit point delta depends on whether you do:

localvert - worldvert

or

worldvert - localvert

...I only mention this because my earlier post suggested 'subtraction' but my example in the script uses 'addition' :).  It's more of a mindset/semantics thing... whether  you think in terms of "removing that deformation influence from the delta" vs "effectively pre-transforming the vertex into position before applying the delta".... so just use whichever you're comfortable with (until/unless it gets fixed for you in the .pyd function).

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

 
Ok, after reviewing your script, I assume you're asking about the code in your setShape() routine...

The answer, in that case, is that "if delta:" should be sufficient.  Currently, the "if" non-zero conditional test on the class only specifically tests for 0.0 values, but that really only catches the "not yet initialized" cases (and/or some cases where the python code explicately set it to 0.0).  I've been meaning to change that to an epsilon value test, so I think I'll do that in the next build.

Hmmm.. your new script is missing some hits (actually, it's finding them, just not setting them), but I'm not sure why yet - still investigating.

Ok, it looks like this same non-zero test causing the problem... I hadn't looked closely enough at that test - it turns out that it only returns true if ALL axis have a non-zero values. So, if vec.x = 10000000000.0 (any non-zero value) but vec.y and vec.z were both 0.0, then "if vec:" would return a 'false' condition (!) heh.

I'll fix that in the next build.

Another version...

Update: 03/24/08 (search on: "03/24/08" to see changes)

• I decided to just keep including the (simpler) shrinkwrap example script for now.
• added "Instance vs Pointer/Reference issue..." discussion/section below.
• added additional notes on HitPoint.HitDist member (...can be negative)
• added CorrelateByIndexLists()
• fixed bug with zero/non-zero test.

Woot!  I'll check it out.  I don't blame you for keeping the simpler script.  I spent most of yesterday trying to plug a RAM leak in the later version....

Mostly, I just went with the simpler one because... it's simpler :).  Easier to see which parts are being done in Python vs the extension and how the data is used.  If people want a more complex example, they can grab your script(s) from this thread.

Sorry, I got kicked offline last time I responded.  Now I've looked at the latest upload, and I'm very happy.  Thank you, thank you for adding the CorrelateByIndexLists() to the .pyd.  This opens up new possibilities beyond the TDMT implementation of the point-in-tri.  :D

Yes, it is simpler.  Simple is good, particularly if the script's purpose is meant to be whaddayacall didactic.

The latest zip includes a vector_glue.c file.  Is that meant to be included?  Does it need to be placed anywhere, or is it just a glimpse into the code you're using?  I assume one can't compile from it without the .h file referenced at the top.

So... I'm off to tinker and test!  :D

Whoo.  So I was right to use the clone() function when filling the points list in the complex example. I'm rather nervous, myself, about setting up funny reference loops and things, with all the RAM leak trouble I've had due to reference handling.  Cough.

I'm a bit puzzled about how to interpret the hit distance.  It gives direction and the values are useful, relative to one another, to check good distances against bad.  It works that way for screening out the multi-actor collisions by distance.  But yesterday I tried to plug the abs() values for the distances into some code which needed the true distance from the collision point, and the values in the hit distances were nothing at all like the PointDistance values I ended up using.  How does one, ah, disassemble the hit distances to separate the direction vector component from the actual distance?  Or can that be done, given that we have a scalar here and not a vector?  I assume there's some modification by the direction of motion (our raycasting normal for the vertex) here....  Not that I need to get the values from the hit distances.  I can do point distance if need be.  It would be better, I assume, to use the existing values, though, if they can be used this way.

Boy, I have so many ideas about how to implement these .pyd functions.  And so little math skill.  LOL

Quote - The latest zip includes a vector_glue.c file.  Is that meant to be included?  Does it need to be placed anywhere, or is it just a glimpse into the code you're using?  I assume one can't compile from it without the .h file referenced at the top.

Ooops... I guess I just clicked on the wrong file - that was supposed to be "vector_test.py".

(vector.c is just one of the files used to create the .pyd file)

Quote - Whoo.  So I was right to use the clone() function when filling the points list in the complex example. I'm rather nervous, myself, about setting up funny reference loops and things, with all the RAM leak trouble I've had due to reference handling.  Cough.

Yes.

Quote - I'm a bit puzzled about how to interpret the hit distance.  It gives direction and the values are useful, relative to one another, to check good distances against bad.  It works that way for screening out the multi-actor collisions by distance.  But yesterday I tried to plug the abs() values for the distances into some code which needed the true distance from the collision point, and the values in the hit distances were nothing at all like the PointDistance values I ended up using.  How does one, ah, disassemble the hit distances to separate the direction vector component from the actual distance?  Or can that be done, given that we have a scalar here and not a vector?  I assume there's some modification by the direction of motion (our raycasting normal for the vertex) here....  Not that I need to get the values from the hit distances.  I can do point distance if need be.  It would be better, I assume, to use the existing values, though, if they can be used this way....

Sorry, I'm a bit puzzled by your question(s) :).  Ideally:
 
a = abs( hp.HitDist )
b = hp.HitDelta.length()
tmp = hp.HitPoint - origvert
c = tmp.length()

.... a == b == c  (though dealing with floating point, so they may be off by some small fractional amount).  Three different ways to determine the distance between the original vertex and the intersection point with the tripoly of the other mesh... the only functional difference is that hp.HitDist can be negative, so you have to wrap it in abs() to get the true distance.

Well... if that's so, then I can see why you're confused by my question.  LOL  When this sort of things happens, it's probably fair to assume that Cage is confused and he goofed somewhere.  Hmm.  I'm wondering if I may have down something which created a reference loop in my test code and I ended up re-setting the distance values I was tracking.  Should have used copies of the values, perhaps.  At any rate, I was getting funny results, and I checked the hit dists (as there were in the list to which I'd logged them) against the point-distances and the hit dists were very high.  (A distance of 5.0, say, compared to 0.2).  I think I probably did something odd in one of my loops.

Thanks for the explanation.  :D  If I keep asking embarassing questions like this, I'll understand everything in NO TIME!  Then - watch out, everyone!  LOL

Thank you for being patient.  :D

... in fact, the code that generates the above values is:

--- snip ---
intersection_distance = ( tp.plane - ndotv ) / ndota   # refer to the clasic code to find similar
hp.HitDist = intersection_distance
hp.HitPoint = origvert.project( origvertnormal, intersection_distance )
hp.HitDelta = hp.HitPoint - origvert
--- snip ---

...the normal is a "unit vector" meaning that it's value = 1.0 (it's like multiplying by 1.0, but "in some direction") and the intersection_distance is just true distance, but with a sign, so it can flip the normal's direction from positive to negative when it gets multiplied by it in the project().   Don't let the sign confuse you, it just means:

if hp.HitDist < 0.0:<br></br>
   the_intersection_is_towards_the_center()   #
must shrink to get there<br></br>
else:<br></br>
   the_intersection_is_away_from_the_center()  #
must inflate to get there<br></br>

Well... I should have thought of that!  I guess I need to read my 3D Math Primer book and come back to this thread in a few weeks.  LOL 

In theory, Cage's constant, silly questions can help casual thread readers come to an understanding of these matters as he does.  Really, that's the point, and Cage is actually a Very Bright Guy, like Spanki, who already knows all of this.  Right.  Just don't ask Cage these questions to test that assertion.  Koff.

Yes, I'm increasingly certain that I ended up redefining my values somewhere because I used references to objects, and not fresh copies of the values.  I assumed that floats would always give me fresh objects, but perhaps that isn't true when simply copying over a list.  The second list conatins pointers to the values in the first list.  Hmm.

S'funny how feedback loops are my enemy here.  I love feedback loops in music.  Had a guitar which I couldn't play, just so I could generate feedback loops.  I guess I developed a knack for such things, because I'm sure a whiz with them in Python. 

No problem... going over it many times helps me understand what's happening as well :).

Spanki's psuedo-no-poke-code-snippet:

if hp.HitDist < 0.0:<br></br>
    if abs( hp.HitDist ) < fit_tolerance:<br></br>
       
move_vert_out_along_its_normal( fit_tolerance - abs( hp.HitDist )
)<br></br>
else:<br></br>
    move_vert_out_along_its_normal( hp.HitDist
+ fit_tolerance )<br></br>

...if it's negative, then it's not poking, but it might be very close, so we make sure it's at least 'fit_tolerance' distance away.  If it's positive, then it's inside the other mesh (skin poking through), so we have to push it out by that much, plus the fit_tolerance (offset).

That's twice today you've mentioned No-Poke, unless the reference in your recent readme was from yesterday.  Hmm.  Someone should use this .pyd to... write a no-poke routine!  Hmm.  And it certainly looks like easy code to utilize....  An alternate function for the sample script, perhaps....

Useful wisdom!  Now let's just see me forget it after I've slept....  :D

Yes... the only difference in doing a 'shrinkwrap" vs a 'no-poke' is that you don't necessarily want to shrink the clothing down to skin-tight (shrinkwrap) - you just want to make sure it's all outside the skin by some amount (though you might have to do some smoothing or something after moving various single vertices out - but that's probably not even necessary, most of the time).

...you could also do a "shape_preserving_refit" routine... that would find the minimum shrink value (or maximum inflate value - which would have precedence over the min shrink value) and just apply that (plus a fit_tolerance) to all the verts.  That could scale a pair of jeans up to fit some other figure, or if overall too large, down to fit some other figure.

...erm, except that... none of any of this stuff handles things like folded-over meshes at all well.  Like the hem of a garment.  On the inside of the mesh, the normals of those vertices point the wrong direction (towards the figure), and/or the ones on the bottom of the crease might point straight up in the air.

All of this code currently only really works well with single-layer meshes, with all vertex normals pointing outwards.

EDIT: that is, unless you do something like your other mapping methods, where you diddle with the normals prior to calling the correlate routine.

Sigh.  Don't you love it when the response editor eats a post?  Let's see if I can recreate my earlier response which never was....

I kind of think the way to handle "areas of detail" or "folded-over" would be to identify those vertices, then move them together with nearest verts or polys somehow.  I haven't thought about it a lot....

I think the cylindrical "mapping" for shrink might give better restulrs than just using the object's normals, but it wouldn't have detail preservation or the ability to handle layered meshes, as you note.  Everything just collapses on top of underlying layers.

Hee hee.  He said "diddle".

Lots of good ideas.  :D  I'm experiementing with another one, which I won't talk about yet, because I have no idea whether I can pull it off....  <shifty-eyed emoticon>  Just a test of the new .pyd.  Ultimately, all of this should (hopefully) be useful for the overall TDMT effort....

Heh,, looks like I forgot to export the CorrelateByIndexLists() method, so that won't work in the current version.  I'm in the middle of some other changes, so I'll upload a new one later.

http://darwin3d.com/gdm1999.htm

Load the .obj (in the next post), load the script, then click outside of the Poser window (like on the Windows toolbar) to see it work.  It may or may not require a decently fast computer....  Not a very impressive example, I think....

BTW, when you "fire up" the script, you want to select this ball as the "shrink" and GROUND as the "wrap"....

D'Oh!  CorrelateByIndexLists() is the one I was looking forward to, too.  No worry, however....

I don't know if you noticed, but ADP had some potentially useful thoughts for me (us?) in the other thread I started recently (where I whine about my RAM leak, you know....)

Cool - I'll take a look at that once I have some time.  Meanwhile, here's an update.

Update: 03/26/08 (search on: "03/26/08" to see changes) [Note: see "03/25/08" below, as well]

• changed my mind and reverted to old methodology for type member storage and returns see the current notes in the "N E W - T Y P E S" section below
• looks like I never exported the CorrelateByIndexLists() method, so it was not available for use... fixed.
• added some additional error-checking code throughout.

Update: 03/25/08 (search on: "03/25/08" to see changes) [Note: this version was not posted]

• all data type member return values are now 'new' instances/copies (no more pointers).
• related to the above, I added comments in a new "N E W - T Y P E S" section below and...
• removed the old "Instance vs Pointer/Reference issue..." section/comments.
• added 'Clone()' method to class.
• added 'Clone()' method to class.
• added 'Copy()' method to class.
• added 'Copy()' method to class.
• changed all methods to use First Letter Upper Case format, for consistency. (ie. v1.clone() becomes v1.Clone(), etc.) - sorry for the trouble, but better now than later :). [Edit: actually, I left the lower-case versions in for now, but you should change over to the new ones so your code will continue to work when I remove the deprecated ones]
   

Or, wait.  You added the new instances on 3/25 and then undid them on 3/26.  So, uh... my previous paragraph is pointless.  Don't read it, okay?

Basically, method name alterations, added Clone and Copy, and fixed the IndexLists.  Good, good.  :D

Anyway, the silly thing I posted last night was broken because I'd commented out the FLT_EPSILON.  Fixed in this one, just to be posting a less buggy version for anyone who wants to try to explore the whole thing.  The effort to convert the C example to Poser is, I suspect, intrinsically flawed.  Most of his constants seem to be sensitive to scale, and there's also a need to convert from his timing process which uses the system clock to one which uses steps (or frame rate).  There's also a bit of trickiness in plugging in our collision methods with his code.  He uses gravity in his equations in kind of the way that we use normals for collision raycasting.  Right now the script uses both, in different parts of the process, but could presumably only use one or the other (perhaps normals direction with an adjustment for the intensity of his gravity force).  Anyway, this kind of shows that something like this might be possible - the .pyd seems fast enough for calculations like this - but it seems evident that the implementation would need to change a great deal.  I'm not sure it's worth my developing any further.  My basic idea was that we could use the cloth simulation as a clothlike shrink method, if we sent vertices in the direction of their normals, rather than the gravity direction.

Boy, I had that last posted script all wrong.  Hmm.  I think this can be made to work, so I'm working on a complete re-write of the idea, even though it's a bit of a digression....

Okay, I read the new .pyd readme, and let's see if I now understand, or whether I'm confused.  Can I generalize and say that any time I'm going to use one of the math operators on a vector, I should be prepared to be handling a reference, so I should use Clone() unless I definitely want to change the source vector?

tempvec = listvec[x]
tempvec += othervec # will alter listvec[x]
newvec = tempvec + othervec # will not alter listvec[x]
newvec = listvec[x] + othervec # will not alter listvec[x]

tempvec = listvec[x].Clone()
tempvec += othervec # will not alter listvec[x]

Is that correct?  :hopeful:

Correct. Except that, the examples you used would be true no matter how my extension worked, because that's how Python lists work.

The thing that I have some control over (and have decided to mimic the way lists work) is when getting cmplex members from my other new types...

norm = tripoly.normal
norm += vec                      # <-- just altered what's in tripoly.normal

norm = tripoly.normal.Clone()
norm += vec                      # <-- did not alter what's in tripoly.normal

...if in doubt, my suggestion is to fire up the stand-alone interpreter and do some tests (with lists, as in my docs, as well).

...in other words, try this and see what happens...

list = [[0,0,0], [1,1,1]]
sublist = list[0]           # <-- retrieve a complex member (a list) of list[]
sublist[1] = 5
print list                     # <--- see what happened to list[0]

I think I'm crashing Poser 7 by trying to use CorrelateByIndexLists().  Here's what I'm doing.

        tripolyindexlist = [i for i in range(len(polyMesh.tpolys))] # Always send all of the polys      
       
        vertindexlist = [i for i in range(len(vertMesh.verts))
                         if vertMesh.particles[i].oneOverM != 0.0] # We'll be locking the mass for some verts
        print step,"pyd"
        print vertindexlist
       
        hitlist = CorrelateByIndexLists( tripolyindexlist, polyMesh.tpolys, polyMesh.verts,
                                         vertindexlist, vertMesh.verts, vertMesh.vnorms )

So I screen the vertindexlist under certain conditions, and then send an incomplete vert list with a complete poly list.

It handles fine when I send a complete vertex list, but once I screen anything, it crashes during the .pyd step in the code.

Incompletelist doesn't work.

[5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
17, 20, 21, 22, 23, 24, 25, 28, 29, 30, 31,
32, 33, 36, 37, 38, 39, 40, 41, 44, 45, 46,
47, 48, 49, 52, 53, 54, 55, 56, 57, 60, 61,
62, 63, 64, 65, 68, 69, 70, 71, 72, 73, 76,
77, 78, 79, 80, 81, 84, 85, 86, 87, 88, 89,
92, 93, 94, 95, 96, 97, 100, 101, 102, 103,
104, 105, 108, 109, 110, 111, 112, 113, 116,
117, 118, 119, 120, 121, 124, 125, 126, 127,
128, 129, 132, 133, 134, 135, 136, 137, 140,
141, 142, 143, 144, 145, 148, 149, 150, 151,
152, 153, 156, 157, 158, 159, 160, 161]

Complete list, no problem.
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25,
26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49,
50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61,
62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85,
86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97,
98, 99, 100, 101, 102, 103, 104, 105, 106,
107, 108, 109, 110, 111, 112, 113, 114, 115,
116, 117, 118, 119, 120, 121, 122, 123, 124,
125, 126, 127, 128, 129, 130, 131, 132, 133,
134, 135, 136, 137, 138, 139, 140, 141, 142,
143, 144, 145, 146, 147, 148, 149, 150, 151,
152, 153, 154, 155, 156, 157, 158, 159, 160, 161]

Am I misunderstanding something or doing something wrong, or have I found a bug (and thereby actually done something useful for the first time in a week or more)?

You may have done something usefull :)  -  I hadn't actually tested that code yet.  I'm in the process of documenting many massive changes, so I'll look into that when I get a chance.  Thanks for the report!

Just to clarify.... CorrelateByIndexLists() will return a list of HitPoint structs for EVERY vertex of the vertex list... not the (smaller) culled index list.

Is it crashing on the CorrelateByIndexLists() call? or when you access the returned hitpoint list?

Nevermind, I see the bug in my code now (copy/paste, forrest/trees, etc.).

New one...

Release Notes:

Update: 03/28/08 (search on: "03/28/08" to see changes)

This is a fairly extensive update to the extension/library... including two new data types (, ), with the versatility they add, along with some re-organization of some internal structure to accomodate them and various other changes.

As mentioned in the preamble description above, this extension is very much a work-in-progress. My early goals were to get some structure in place to build on (new lower-level data types and core methods for dealing with them) and then to layer higher-level functionality on top.

This update is a big (but still early) step in the second phase. The new class off-loads a lot of the lower-level details and house-keeping from the Python script, to the compiled extension proving both speed and a more object-oriented mechanism for performing various tasks (reducing the number of arguments needed for various tasks, which means much less for the script to keep track of and worry about).

The general routines are still available, but much of that functionality is now also provided by the new class (which is currently Poser-specific).

Be sure to read the individual update notes below for more details...

• added new (not a lot of functionality here yet, but it's used by...)
• added new (high-level class to track/generate/provide various data)
• added GetVertexEpsilon()
• added SetVertexEpsilon()
• fixed bug in CorrelateByIndexLists() (D'oh!)
• some additional documentation (and functionality) on coercion.
• added some clarification and/or correction to previous discussion about intance vs reference.
• added new minimal/updated example script named ****** pyd_shrinkwrap_test.py ********
• lots of new semi-tested code (and potentially incomplete docs) - please let me know if you run into any problems.

[lots of changes, documentation changes.. let me know if I missed anything]

Holy cow!  What an update!  The Mesh addition is wonderful.  :D  I've been looking at the readme, and I don't think I've quite managed to absorb it all yet.  There's a lot.  Which is good! 

The new example script is quite, what... sparse?  At this rate, all of TDMT (save perhaps the GUI) will be able to be written in only ten lines of code, thanks to the .pyd!  LOL

I was looking at the readme and noted the comment about addition or subtraction returning nothing useful for ngons.  I could imagine addition simply merging the two, creating a new ngon with the combined vertices of the two original ngons as its outline, presumably with any resulting inner verts removed.  Not that I expect it to be added to the .pyd.  It just struck me as a logical way to think of polygon addition.  Subtraction would leave me a bit more puzzled.  You don't want to punch a hole in an ngon....

Yeah, you could implement addition and a few other things like that with TriPolys/Ngons - and I had thought of that - but the extension isn't/wasn't at a point of generating 'new' geometry, per-se, when I wrote that.  So I wasn't thinking narrowly, but my wording was probably poorly chosen :).

BTW, I just remembered... when I was doing the code for generating/setting the Tex Verts for Ngons, I discovered that the code I had previously written for doing the same with TriPolys was wrong/insufficient, but I forgot to go back and fix it.   For the time-being, you should not pass the (optional)  'texpolylist' to the TriPolygonize() routine, or count on those elements being correct in tripolys unless you know that the entire mesh in question is fully uv-mapped.  The indices found in the Ngons (if not set to 'None') should be correct though.