And yeah, I don't have any current plans for doing that GUI stuff in the .pyd, so there's still plenty of room for python code :).

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

I take (part of) that back... just to clarify, if you are using the MeshType interface to get your TriPolys, then the uv0, uv1, uv2 members of the TriPoly will either be correct, or all set to 0.

If you're using TriPolygonize() and pass in the optional 'texpolylist', there's a potential for crashing (or at least causing an exception).

I'm having a bit of luck with this spring system implementation, finally.  Check out the attached image.  Did I make that square all cloth-y in the cloth room?  Nope!  I used Python and the _tdmt.pyd!

I'm still struggling a bit with collision implementation, however....

Hey, that looks pretty darned cool! ;).

I breifly looked at your cloth/bouncy script above... and had some problems with it (had to reduce the step-size from 10 to 1 for my faster machine, for one thing :) ), but I didn't spend enough time with it to figure out what all the issues are.  I managed to get the ball to collide with the floor (instead of passing through it), and it bounced back up, but some of the verts stay on the floor, so it eventually mangles itself up pretty bad.

Here's another, higher res square, colliding with a cube.  Firefly doesn't like to render smoothing and shadows on these, unfortunately, so no shadows....

The script above has instructions for setting up this effect.

hmmm....

def normToForce(mesh,intensity):<br></br>
 """Convert normals to force
information"""<br></br>
 if intensity !=
0.0:           #
shouldn't this be...<br></br>
  for vi in
range(len(mesh.particles)):   # swapped with this
line?<br></br>
   norm = mesh.vnorms[vi]<br></br>
   mesh.particles[vi].f = norm.Scale(1.0/intensity)
#?<br></br>
  else:<br></br>
   mesh.particles[vi].f = Vector()<br></br>

...and...

def normToGravity(mesh,intensity):<br></br>
 """"""<br></br>
 if intensity !=
0.0:         # shouldn't
this be...<br></br>
  for vi in range(len(mesh.particles)):  # swapped
with this line?<br></br>
   norm = mesh.vnorms[vi]<br></br>
   mesh.particles[vi].gravity =
norm.Scale(1.0/intensity)<br></br>
  else:<br></br>
   mesh.particles[vi].gravity = Vector()<br></br>
   mesh.particles[vi].oneOverM = 0.0<br></br><br></br>

...see the # comments, above.

I'm babbling, aren't I?  I may have screwed the tabs up when I converted from spaces to tabs.  The else pertains to the global if at the opening. 

Oh, bugger.  I just checked, and the spaces to tabs script broke it.  Sorry.  Here's a correct one - but you'll have to suffer through spaces again.  :(

Edit.  Nope, you were right.  I had it wrong in the clean copy, too.  Huh.  Thank you.  The question is, why did the function still work when I called it, with wonky syntax like that?  Hoofa....

I didn't really look at what it was trying to do.. just the syntax ("if: , else:" should be inside "for:" loop). :)

...also, you should (now) be able to replace tests like this:

    if (abs(vec.x) > FLT_EPSILON) or (abs(vec.y) > FLT_EPSILON) or (abs(vec.z) > FLT_EPSILON):

..with just:

if vec:

Thank you, Spanki!  :D

Thanks for the heads up on the if vec.  :D  I had asked about that, you answered, and I knew I could use it now.  I've just been focused on WHY THE SILLY SPRINGS WOULDN'T WORK, y'see, so I kind of neglected a lot of other brainy-think-y type stuff.  Sigh.

no problem... was just reminding, in case I hadn't mentioned it yet.

I think you put it in one of the very early .pyd updates, didn't you?  It's been a week or more since, but I think it was covered up above somewhere.  Always good to have reminders, though.

Have I killed the thread again, like I did with my long digression into UV handling?   

not dead, just resting.  :lol:
wanted to mention my gratitude to cage, spanki et al. for their work on this.
I have tried some of the scripts in OS X and am impressed with their capabilities.

Quote - Have I killed the thread again, like I did with my long digression into UV handling?   

Nope, just the aforementioned planned absense (other obligations).  Here's a new one to tide you over a while...

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

First off, a word about direction... as might be gleaned from recent developments within the class, my plan is to move away from the old 'Polygon List' and only develop new functionality based on the newer class. For the script writer, this typically adds one additional line of code to get to the vertex indices...

poly = polylist[i]

...becomes...

ngon = ngonlist[i]
poly = ngon.vertIndices

...or even just...

poly = ngonlist[i].vertIndices

...but that extra effort also gives you easy access to the other Ngon members (it's normal, plane equation, uv indices) - all in one place - so you don't have to manage 4-5 different lists of data for every polygon.

This (and use of the class in general) also helps me keep track of things internally, because (for example) the TriPolys can be directly generated from Ngons, instead of having to track and pass around 4-5 lists of data to create them (it also lets me make certain assumptions about the validity and formating of the data in many cases, reducing the amount of error and range-checking bloat in the code).

In short... the various old 'Polygon List' routines might (or might not) remain available, but my advice would be to try utilizing the instead. The routines I'm referring to are:

psrPolygonList() -> mesh.GetNgons() /
psrNgonList()  (new)<br></br>
psrTexPolygonList() ->
ngon.texIndices              
(member of NgonType)<br></br>
TriPolygonize() -> mesh.GetTriPolys() / TriPolysFromNgons()
(new)<br></br>
PolyFaceNormals() ->
ngon.normal                    
(member of NgonType)<br></br>
VertexPolys() -> mesh.GetVertNgons() / VertexNgons() (new)<br></br>
PolyVertexNormals() ->
mesh.GetWorldNormals()        (stand-alone
routine to come)<br></br>

...once I have suitable Ngon replacements in place for the above (which I mostly already have), the above routines (left-most column) hit the endangered-species list :).

[NOTE: rather than try to use the stand-alone functions, it's recommended to use the MeshType class, which does a lot of things like generating Ngon and tripoly face normals for you automatically. (ie. if you do: 'ngons = mesh.GetNgons(geom)' then the normals and plane equations (and tex indices list) of the Ngons are already filled in - if you call the new stand-alone 'ngons = psrNgonList(geom)' instead, the tex indices list is filled in, but the normal and plane members are not]

Individual updates list:

• added psrNgonList()
• added TriPolysFromNgons()
• added VertexNgons()
• added mesh.GetVertNeighborsByNgons()
   

Whoa!  More new stuff!  :D  :D

I started to adapt my WIP testing script to the new Mesh type, but ran up against the fact that it's read-only.  Which is probably a good thing, except that I've been using the mesh class instances to store additional data beyond what we're handling in the pyd.  Which means I need to change my approach somewhat, and end up with a pyd Mesh instance running alongside a class container which will operate for the other things.  Since that involved some major restructuring, I set it aside for a bit.  But I think I should probably go ahead and make those changes, to get a sense of how this new and apparently preferred approach will work.  I like the look of things in the pyd_shrinkwrap_test script.  Very clean and concise!  :D  :D

Thank you for a vertex neighbors function!  Woot!  I find that to be very useful, at times....

I'm also considering adding a few 'userdata' type members, which would allow you to store whatever you want in the MeshType.

BTW, I had added a few comments to one of your earlier scripts (attached), just search for 'Spanki' to see them.. nothing major, just a few comments/tips.

re: on the oneOverM thing... I see from the comments that the 'M' actually does stand for Mass, but I haven't researched exactly how it was being used in the original C code (and wouldn't want to hazard a guess), so don't take my comments in there too literally... unless it can always be multiplied by (which may not be the case).

The source C++ code is extremely ambiguous on certain points, one of them being exactly what oneOverM represents.  I'm not exactly certain.  I only know that he receives the value from the GUI, where it seems to be preferred to have it clamped between 1.0 and 0.0.  Whether that represents mass or some pre-altered value related to mass, or something else altogether, I don't know.  I've retained his variable name with oneOverM, however, so presumably the name itself is some sort of indicator of what it is....

I was thinking about embedding your Mesh type in my container.  I'll try that, then!  :D  This seems like a bit of a serious paradigm shift, regarding the general approach we've had since the start, but I think I can see how it will be beneficial.  Among other things, I expect it to make calling up multiple actors easier.

Y'know, I had in place the same basic simplified code that you've added for the gravity handling, but at the time I couldn't see the springs working (it turned out that I was setting the Ks value too low), so I more literally copied the source code's approach in order to be sure I wasn't mishandling anything.  Thanks for restoring the more concise version!

And the zero equivalency test for float... well... .  That was initially just an else condition, and I unthinkingly made it more literal.  I had since changed it (along with a great deal else), but only ever seem to get penetration cases, never collision - which means the general while loop used to pop out the mesh and enable soft body dynamics never works.  Huh.  Anyways.  Thanks for the notes.  I'll see if I can refine this.  Unfortunately, it takes the speed gains for collision handling via the pyd and then applies them in a way that creates yet another Cage script that takes seven minutes to run in even fairly simple situations....  Sigh.  I'm not feeling optimistic about the pseudo cloth right now....

Okay, first question: how do I get the vertex normals using the Mesh/Ngon types?  Maybe that's explained in your recent .pyd update post....  Go through, uh...

<font size="2">PolyVertexNormals() ->
mesh.GetWorldNormals()        (stand-alone
routine to come)<br></br><br></br>
???<br></br><br></br>
Help!  What happened to my text?  How do I un-format
this?  Jane!  Stop this crazy thing!<br></br><br></br>
I guess I should tinker and test....<br></br></font>

Yes, to get vertex normals, you simply:

shrinkMesh = Mesh(shrinkActor.Geometry())
vertnorms = shrinkMesh.GetWorldNormals()

...just as a reminder and/or in case anyone is wondering...

Obviously Poser Python already has a method for getting Normals, but we determined very early on that they were not 'correct' (at least for what we wanted to use them for - I don't recall the details atm), so we are computing our own.

I noted while working on this that the vertex neighbors routine recently added to the .pyd isn't returning the same data as the routine I've been using for TDMT classic, so I still use the hand-written version.  :(  The .pyd version is returning the index of the vertex itself, as well as fewer neighbors than the classic method.  My use requires that the neighbors include indices of all vertices which are part of ngons of which the vert is also part, excluding the index of the vert itself.  It's hard to express such things without being confusing, isn't it?  Cough....

Otherwise, all is well, and it does seem a bit faster, although the process as it stands is certainly not going to be robust enough to become an effective alternative to the cloth room.  My hope has been that this could expose the basic simulation handling for cloth for users to adjust as desired, in ways not allowed by the clothroom.  For instance, simulate a rope without having it collapse in on itself.  Or adjust the direction of gravity, to create a vacuum-wrapping effect.  The vacuum-wrapping works here, but can be painfully slow, alas....

BTW, a big "THANK YOU!" to Miss Nancy for the kind words, and thanks to Spanki, again, for putting up with my hack-ish ways.  I do fear that I may drive folks away, just by being as haphazard and air-headed as I can be....  :(

Quote - I noted while working on this that the vertex neighbors routine recently added to the .pyd isn't returning the same data as the routine I've been using for TDMT classic, so I still use the hand-written version.  :(  The .pyd version is returning the index of the vertex itself, as well as fewer neighbors than the classic method.  My use requires that the neighbors include indices of all vertices which are part of ngons of which the vert is also part, excluding the index of the vert itself.  It's hard to express such things without being confusing, isn't it?  Cough....

Actually, you just described how I intended it to work (mimicing the functionality of your python code), so if it's not doing that, I'll have to look at it again.

*Actually, you just described how I intended it to work (mimicing the functionality of your python code), so if it's not doing that, I'll have to look at it again.

*I found it to be returning the index of the vertex itself, which isn't a big deal.  I just wrote something to screen that out.  The screened lists weren't giving me all the desired neighbor polys, so I stopped messing with it and just adapted the old function for Mesh use.  There is a chance that I erred while screening the index of the vert and ended up somehow screening valid neighbors as well.  I don't think I did, but it is always much more likely that Cage goofed, when something like this comes up....  :-P 

Not a biggie.*

D'Oh!  Cross-posted....

I didn't know we could attach binary files as .txt....

I'll test this now!  :D

vertneighbors(mesh) #still need to run this manually - pyd isn't returning the same data.  
mesh.vneighbors2 = mesh.mesh.GetVertNeighborsByNgons()
for vi in range(len(mesh.verts)):
    print vi, mesh.vneighbors[vi],mesh.vneighbors2[vi]
return

0 [1 2 3] [0]
1 [0 2 3] [0, 1]
2 [0 1 3] [0, 1, 2]
3 [0 1 2] [0, 1, 2, 3]
4 [7 6 5] [7, 6, 5, 4]
5 [7 6 4] [7, 6, 5]
6 [7 5 4] [7, 6]
7 [6 5 4] [7]

The above code prints the results of a comparison between the "classic" vertneighbors and the .pyd just posted, using the two-sided square primitive....

Am I mis-applying the code for GetVertNeighborsByNgons()?

Just to clarify... I did find what was causing the vert itself to get added and fixed that.  As for the complete list of neighbor verts, I also found a potential problem with that (my fix needs testing), but what I'm doing internally is...

• get list of vertex Ngon neighbors ( vngons = mesh.GetVertNgons() ) and then...
• walk through the list of ngons each vert is a part of and building a list of (unique) vertices used by any/all of those ngons (now properly excluding the vertex itself).

...so just to clarify, my code doesn't know anything about any potential screening you might be doing, before or afterwards.

<cross-posted>.... hmmm.. let me study that a minute.

I need to go eat dinner and watch some shows... I'll look at this afterwards :).

Ok, I'm not getting those results.  When you downloaded that new file above, did you quit Poser, download that file (overwriting the _tdmt.pyd file in the PoersRuntimePythonDLLs folder), then re-start Poser and try again?

I just tested with this:

import poser<br></br>
import math, Numeric<br></br>
import time, os<br></br>
from _tdmt import *

def vertneighbors(mesh): # _tdmt.pyd
GetVertNeighborsByNgons() doesn't return the same data....<br></br>
 ngons = mesh.GetNgons()<br></br>
 pgons = [i.vertIndices for i in ngons]<br></br>
 vpolys = mesh.GetVertNgons()<br></br>
 vneighbors = [[] for i in range(len(vpolys))]<br></br>
 for vi in range(len(vpolys)):<br></br>
  screen = [vi] # Need to exclude the vert itself!<br></br>
  for ps in vpolys[vi]:<br></br>
   for v in pgons[ps]:<br></br>
    if not v in screen:<br></br>
     vneighbors[vi].append(v)<br></br>
    screen.append(v)<br></br>
 vneighbors = [Numeric.array(i,Numeric.Int) for i in
vneighbors]<br></br>
 return vneighbors

scene = poser.Scene()<br></br>
actor = scene.CurrentActor()

if actor:<br></br>
 geom = actor.Geometry()<br></br>
 if geom:<br></br>
  mesh = Mesh(geom)<br></br>
  vn = mesh.GetVertNeighborsByNgons()<br></br>
  vn2 = vertneighbors(mesh)<br></br>
  for vi in range(len(vn)):<br></br>
   print vi, vn2[vi], vn[vi]<br></br>

...and got this result:

0 [1 2 3] [1, 2, 3]
1 [0 2 3] [0, 2, 3]
2 [0 1 3] [0, 1, 3]
3 [0 1 2] [0, 1, 2]
4 [7 6 5] [7, 6, 5]
5 [7 6 4] [7, 6, 4]
6 [7 5 4] [7, 5, 4]
7 [6 5 4] [6, 5, 4]
 

Hooray!  Yeh, I had failed to reinitialize the Python!  See what I mean... when something seems wrong, it's probably a Cage error.  LOL

Hoo boy.  Sorry for the concern.   

And here's an update which applies the fixed version.

Since it appears to now be working correctly, I replaced the download zip file with the new .pyd inside (didn't update the docs any).

Thank you again, Spanki-sir!  :D

Here's a bit of a poser... does that qualify as a pun?  Hmm.  I'm thinking about cloth self-collision.  To do this, it seems one would have to send the cloth mesh as both verts and polys.  The likely result (borne out in a quick test I ran) would seem to be that the vert would collide with itself in all cases.  Indeed, my cloth just quivered in place.

The only obvious workaround I can think of would be to send each vert individually, as a one-item list, along with a poly list which screens out all the polys of which that vert is part (I assume it can't collide with those, but I may be wrong).  This seems like it would be quite slow, unfortunately.  This really isn't something for which this point-in-tri approach was designed.

Can you suggest any approach for this, other than the one I have above?  Is there anything in the .pyd that could make this easier?

Erm, yeah, it wasn't really designed to account for self-collisions... let me think about that some (I'm actually afk right now, just doing a drive-by :) ).

It's a puzzler.  I don't think even adding a screening list to the optional submissions for the point-in-tri routine would help.  :(

Whenever you come back, you'll have to tell me what "afk" is....  LOL

afk = Away From Keyboard :)  (which I still am, for the next hour or so)

S'okay.  I'm going to be otwdw (Off To Watch Doctor Who) pretty soon, anyways.  Going to reprise some Eccleston tonight, I think.  :D

Actually... I'm kind of wondering if collision detection of the robustness of the _tdmt approach is even necessary for this sort of approach.  The C++ example simply uses distances from objects.  His approach is far to simple and not really useful for Poser, but I wonder if the basic idea may still hols.  That is, for both self-collisions and other-collisions, with cloth or something like this, we don't really need the exact point of collision, or perhaps we don't even need to identify a specific collision poly or tri.  I don't know.  Could one simply use distances from all the poly or tri planes somehow, reacting if a vert comes within a certain distance of something?  Hmm.

But I guess the plane is infinite, so one might need to break that down into the area of the tri or poly, so....

Hmm.  Umm.  Where's my 3D math book....  Need a refresher....

Yes, we're generating more data (weight values) than is needed by that code, and a lot of it could be by-passed with some simple bounding box tests (until you got within range of an actual collision)... but at some point (once you have the objects close to each other), you still need to determine ray->polygon intersections along with the distances generated in those tests.

New toys...

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

While it might not have been apparent or stated clearly in previous releases, the lists being returned by the various MeshType methods were pointers (by reference) to the actual lists being tracked (and used) internally by the MeshType class. This was implemented as such for two reasons...

1. keep memory allocations smaller.
2. consistancy with the behavior of other types implemented by this extension.

...the potential problem with this is/was that there was no 'Clone()' method for the Python Lists being returned (you'd either have to roll your own or Clone() the entire MeshType). So, while it was consistent in behavior (returning pointer/references for complex data types), it was inconsistent in functionality (not providing a way to easily get 'new' lists to play with).

As of this release - and at least for the time-being - I have changed the MeshType methods to always return fresh copies/clones of the lists that it's working with internally. This also has the side-effect that if you modify the vertex positions, you need to tell the Mesh class about it, so it knows to fetch/generate fresh data the next time it's needed (ie. face normals and vertex normals likely need to be re-computed and distances, positions and intersection locations would also be off). You can accomplish this with the new mesh.VertPositionsChanged() call.

If you actually make structural changes (ie. change which vertex indices are used by Ngons and TriPolys, the winding order used to create them or add/remove any polygons or vertices or tex vertices, etc.) then you need to call mesh.StructureChanged() instead. This one basically invalidates all internal lists, so any data will get re-computed when next needed.

The other new features of this release are an attempt to address the self-collision/correlation issue. For the purpose of discussion, assume we have a flattened spherical mesh (like seat-cushion). And that you wanted to write a script that flattened it out even more, but not so much that one side of it penetrated the other side... in this case (and most other self-collision cases), you need to correlate the vertices of the mesh with the tripolys of the same mesh - typically with tripolys on the other side of the mesh - but not necessarily. This poses a couple different problems for our current/original Correlate() routines...

1. correlating a mesh with itself would always get 'hits' on the tripolys that the vertices lived in (one of them, more or less randomly, since the intersection would be AT the vertex).

2. the current routine doesn't bother testing for collisions with any tripolys that face the opposite direction as the faces that use the vertices being tested (you might have to read that a few times for it to make sense :) ).

...so, to address these issues, there are two new Mesh class methods...

CorrelateToSelf()
CorrelateByIndexToSelf()

...see the documentation below for details, but for the record, neither has been tested :) and/so, I'm not even sure that the backface culling (or lack thereof) is working as it should (and, if it does produce the proper hits, what happens to or how to interpret the sign of HitDist, etc. [but I don't think that changes, actually - it should still give the same indication of direction to the intersection, in a positive or negative increment along the tested normal, so the only real difference is that the tripoly it intersects may be back-facing]).

Trial and Error is the order of the day - have fun! :)

Additions:

• fixed bug in mesh.GetVertNeighborsByNgons()
• added mesh.VertPositionsChanged()
• added mesh.StructureChanged()
• added mesh.CorrelateToSelf()
• added mesh.CorrelateByIndexToSelf()
   

WAIT  - that version has bugs.  ;)