Right on!  This is excellent news, Spanki-sir!  PoserPython has needed something like this for some time.  I'm glad to hear that you were able to work out the creation process for a .pyd file.  I'm eager to test the implementation of this.  :D

Yes, we were using Numeric to store the vast majority of the data generated by the Geom module.  Apparently Numeric is reducing our memory overhead, compared to using mere lists, and possibly helping reduce leaks, too.  I understand that Numeric arrays will only store a reference to a Python object if specifically instructed to do so.  What we haven't been doing is making use of any of the built-in Numeric functions for the arrays, such as flatten.  Frankly, I don't understand most of them, although I'm currently trying to read up on them.

Now, ah, if we had .pyd modules for handling matrices and quaternions and rotations, PoserPython's potential would be vastly improved....  <Shifty-eyed emoticon which I don't know how to type>

Was it difficult to create the .pyd?

Do you have any thoughts on using a series of Vertex and Polygon class instances for Geom data organization, rather than comprehensive lists covering the entire actor geometry?  I plan to test this soon.  My thought is that it might make mapping verts and polys between actors (virtually merging geometries) easier, as well as mapping between normal polys and triangulated polys.  But what I don't know is whether it would actually be worse for memory usage or slower (or more involved) in terms of loop structure.  As far as I can tell, however, that would be moving toward ADP's idea of a more object-oriented structure.  (Or would it?)

Quote - Right on!  This is excellent news, Spanki-sir!  PoserPython has needed something like this for some time.  I'm glad to hear that you were able to work out the creation process for a .pyd file.  I'm eager to test the implementation of this.  :D

Once I tidy up some loose ends in the current code, I'll post my test stuff to look at while I expand on it.

Quote - ...Now, ah, if we had .pyd modules for handling matrices and quaternions and rotations, PoserPython's potential would be vastly improved....  <Shifty-eyed emoticon which I don't know how to type>

Was it difficult to create the .pyd?

The answer to both of the above can be found here.  I basically downloaded the PARC code, extracted the Vector part of it, fixed some bugs and then added functionality to it.  He also had Matrix operations in there, but I cut those out (for now, at least).  His binaries are for Python 2.2, so they may not be any use to you.  I didn't even look at or try his compile instructions, but you may be able to use them to rebuild for 2.4 if/once you get a compiler (I used some other example code to come up with the settings needed to make a .pyd file, using the free VC++ 2008 I linked earlier).

Quote - Do you have any thoughts on using a series of Vertex and Polygon class instances for Geom data organization, rather than comprehensive lists covering the entire actor geometry?  I plan to test this soon.  My thought is that it might make mapping verts and polys between actors (virtually merging geometries) easier, as well as mapping between normal polys and triangulated polys.  But what I don't know is whether it would actually be worse for memory usage or slower (or more involved) in terms of loop structure.  As far as I can tell, however, that would be moving toward ADP's idea of a more object-oriented structure.  (Or would it?)

This new vector 'type' is essentially a vector/vertex 'class', in that it knows about the format of and has methods for operating on data in that format (3 doubles, which includes vertices, normals, rgb triplets, uvw triplets, weight triplets or whatever else has similar functionality).  My intention is to also develop a tri-poly class that will be somewhat specific to our implementation (it just holds  the triangle vertex indices, but also a reference index to the parent 'polygon' it came from, as well as some other data like a normal and plane equation value).

There are a few other classes / types / extensions that can help as well - for example, my current C++ plugin has a 'PolyHitList' class / structure that consolidates and tracks things like our ixpolys, windex and weights arrays.

With all of the above in place, lots and lots of the current code functionality can be moved over into the .pyd extension (computing normals, plane equations, point-in-triangle tests, the entire linecast_loop(), weight and windex calcs, etc).

Brilliant work!  :D  :D  This is just excellent, with potential well beyond the application in this current script.  This could help make geometry manipulation through Poser Python much more accessible to more people.  I'm really excited about all of this.  :D

I'm puzzled about the version of the binaries.  Will they work with Poser?  How might they not work for me?  In terms of trying to compile something myself?

It could also be very useful to include data about neighbor verts or polys, the polygons to which a vertex belongs, the vertices of a poly, and possibly things like the polygon center or the material of a poly (or even vert).  And edges of polys, edge membership for vertices.  In trying to create a class for verts and polys, I was going to try to accomodate these things.  They've proven useful in the Geom module, at any rate.

But I'm getting carried away, huh?  <Shifty-eyed emoticon recurs>

Quote - It could also be very useful to include data about neighbor verts or polys, the polygons to which a vertex belongs, the vertices of a poly, and possibly things like the polygon center or the material of a poly (or even vert).  And edges of polys, edge membership for vertices.  In trying to create a class for verts and polys, I was going to try to accomodate these things.  They've proven useful in the Geom module, at any rate.

But I'm getting carried away, huh?  <Shifty-eyed emoticon recurs>

All in good time :).

For your amusement:

Hip - [ 1152  :  1279 ]<br></br>
---Test1 Numeric: 0.829999923706<br></br>
---Test1  Vector: 0.234999895096<br></br>
---vector.timetest1(): 0.0160000324249<br></br>
Abdomen - [ 2270  :  2362 ]<br></br>
---Test1 Numeric: 1.53500008583<br></br>
---Test1  Vector: 0.438999891281<br></br>
---vector.timetest1(): 0.0150001049042<br></br>
Chest - [ 3732  :  3914 ]<br></br>
---Test1 Numeric: 2.53799986839<br></br>
---Test1  Vector: 0.72100019455<br></br>
---vector.timetest1(): 0.0469999313354<br></br>
Neck - [ 676  :  754 ]<br></br>
---Test1 Numeric: 0.484999895096<br></br>
---Test1  Vector: 0.141000032425<br></br>
---vector.timetest1(): 0.0<br></br>
Head - [ 14022  :  15078 ]<br></br>
---Test1 Numeric: 9.77399992943<br></br>
---Test1  Vector: 2.82000017166<br></br>
---vector.timetest1(): 0.155999898911<br></br><br></br>

...note the 3rd timng on each actor... "vector.timetest1()" ...that's the same test code ported over into the .pyd file.  That confirms what I was talking about before... the real speed comes from moving entire routines into the C code :).

...just for completeness-sake, here's the C code version of that earlier test routine...

static PyObject *timetest1(PyObject *self, PyObject
*args)<br></br>
{<br></br>
 PyListObject *pVectorList;  // the passed in vector list
(list-of-Vectors)<br></br>
 VECTOR *pVector;<br></br>
 double ray[3] = {0.0, 1.0, 0.0};<br></br>
 double pn[3] = {0.0, 1.0, 0.0};<br></br>
 double point[3];<br></br>
 double *v;<br></br>
 double *v0,*v1,*v2;<br></br>
 double intersect = 1.0;<br></br>
 double ndota, ndotv;<br></br>
 long vCount, pi, vi;

 // start by deconstructing the args<br></br>
 if (!PyArg_ParseTuple(args, "iO", &vCount,
&pVectorList ))<br></br>
  onError("timetest requires a count and a list of
vectors");

 if(!PyList_Check(pVectorList))<br></br>
  onError("timetest requires a list of vectors as
second arg");

 // try to modify each vertex...<br></br>
 for(pi=0; pi<100; pi++)<br></br>
 {<br></br>
  for(vi=0; vi<vCount; vi++)<br></br>
  {<br></br>
   double eu[3], ev[3], wx[3];<br></br>
   double uu, vv, uv, wu, wv;

   // get each vertex/vector...<br></br>
   pVector = (VECTOR
*)pVectorList->ob_item[vi]; //PyList_GET_ITEM(pVectorList,
i);<br></br>
   if(!isVector(pVector))<br></br>
    onError("timetest requires a list of
vectors as second arg");<br></br>
   v = &pVector->v[0];

   ndota = V3_DOT(pn, ray);<br></br>
   ndotv = V3_DOT(pn, v);

   point[0] = v[0] + (ray[0] *
intersect);<br></br>
   point[1] = v[1] + (ray[1] * intersect);<br></br>
   point[2] = v[2] + (ray[2] *
intersect);

   v0 = &((VECTOR
*)pVectorList->ob_item[0])->v[0]; //PyList_GET_ITEM(pVectorList,
0);<br></br>
   v1 = &((VECTOR
*)pVectorList->ob_item[1])->v[0]; //PyList_GET_ITEM(pVectorList,
1);<br></br>
   v2 = &((VECTOR
*)pVectorList->ob_item[2])->v[0]; //PyList_GET_ITEM(pVectorList,
2);

   V3_SUB(v1, v0, eu);  //
vecsub(v1,v0)<br></br>
   V3_SUB(v2, v0, ev);  //
vecsub(v2,v0)<br></br>
   uu = V3_DOT(eu, eu); //
vector_dotproduct(eu,eu)<br></br>
   vv = V3_DOT(ev, ev); //
vector_dotproduct(ev,ev)<br></br>
   uv = V3_DOT(eu, ev); //
vector_dotproduct(eu,ev)<br></br>
   V3_SUB(point, v0, wx); //
vecsub(point,v0)<br></br>
   wu = V3_DOT(wx, eu); //
vector_dotproduct(wx,eu)<br></br>
   wv = V3_DOT(wx, ev); //
vector_dotproduct(wx,ev)<br></br>
  }<br></br>
 }

 Py_INCREF(Py_None);<br></br>
 return Py_None;<br></br>
}<br></br>

...it's not quite as easy to follow as the python code currently, but it's doing the exact same computations.

Quote - I'm puzzled about the version of the binaries.  Will they work with Poser?  How might they not work for me?  In terms of trying to compile something myself?

 
The binaries available for download were compiled for Python v2.2.  Poser 7 uses Python v2.4 (not sure about the other Poser versions, off-hand).  I suspect that that means it won't work with Poser 7, but you could always try it.

thanks to cage, spanki, adp, giorgio et al. for your work on this. as mentioned by one of the others, this may be the most valuable python script ever posted here IMVHO. I have no knowledge of how to write python code. I downloaded the script and the chm file (still awaiting edit), as well as this basic process from an earlier message in this thread. I just have a few questions: **

1. Line up the source and target actors as well as possible in the 3D view. This may involve any or all of the transforms, as well as morphing or using deformers.**

in this step, should the two figures' surfaces match, or should the target surface be some factor larger than the source surface?

2) Start the script. Select source and target actors.

I understand this part. **

1. For complex meshes with ovelapping or internal geometry, such as heads, it may be best to use the materials screening option.**

understood. in OS X, Poser 7, I get exception error screens unless I check this option. **

1. One may also wish to use region box screening to restrict an area of comparison.**

I don't understand this, but maybe it's optional for now. **

1. Analyze the meshes.**

how long should this take for the slowest processor with the least amount of RAM? in OS X, when a process is running, we see the spinning rainbow wheel, but I don't see this, hence I dunno when to go to the next step.

6) Transfer morph and transfer shape produce somewhat different results. Try using either to see which one may be best for your needs. When running transfer morph, a morph needs to be selected in the listbox. When running transfer shape, the desired morph (shape) needs to be set on the source actor.

basically I wanna get a dress for voluptuous vickie to fit mokei, an anime figure by hokusai. all I want at this point is to shrink-wrap the dress onto mokei's torso. which option (morph or shape) is gonna be easier to accomplish this (quicker to do), assuming I don't wanna repose of animate the result? **

1. In cases where materials or regions were screened, more than one comparison will need to be run for the meshes, to catch all the verts, eventually. This is the "lather, rinse, repeat" step.**

I don't understand this, but maybe it's optional for now. when you say "more than one comparison", does that mean click the "analyse" button more than once? **

1. Once you have a good series of datafiles for actors which were screened, you can merge them into a single datafile using the merge option in the file menu.**

I'm guessing that said datafiles are gonna appear in a folder in the same level as the run-tdmt script, then the merge command will access them, but haven't gotten to this step yet, as the script froze on me when I tried to transfer morphs. I don't see the keyword "merge" anywhere on the script window nor in the menus. I didn't see any datafiles after using the shape option, but didn't know how long to wait before quitting. I saw a folder based on the figure name after running the morph option, but the process froze and the machine was not responding.

**9) Smoothing (and the other "extra" functions) work on the source listbox selection - or, more specifically, on the selected morph for the source actor selection. All of the extra functions also require that both a source and a target actor be selected.

** I don't understand this, but maybe it's optional for now. I'm guessing that smoothing is self-explanatory, e.g. like subdivision smoothing.

10)  after doing steps 1 - 9, what function do I perform in the script to cause the target mesh
to shrink-wrap onto the source mesh in the pose room display?

The timing tests are very exciting.  Whoofa!

You're testing with Poser 7?  Or are you just sending "dummy" info to a standalone Python script?

Cross-posted with Miss nancy.

1)  It should help if the target surface is slightly displaced from the source (larger).

1. pass

3)  Can you explain the error you're getting, and the context?  I can't test on a Mac, but there shouldn't be any error because you aren't screening by material....

4)  This is optional and not necessarily well-implemented.  It basically creates a bounding box which the user can move to define selected or excluded areas for vertices in the run.

5)  With large meshes, analyses can currently take awhile.  I haven't been able to do extensive timing tests on multiple computers.  Perhaps Spanki can help with an overview on this level....  The next step, at any rate, can't be undertaken until the script automatically stops analyzing when it has finished.  Click to start it, let it run its course, then proceed.  You might want to get a cup of coffee, or maybe even go out for pizza, if you're handling large meshes on a slower system....  :(

Whoops.  Have to cut responses short, due to phone line demand.  I'll type up the rest offline and post them ASAP....

Hi Miss Nancy,

Thanks for the kind words :).  I'm going to leave many of your questions for Cage, but here's some quick/partial info...

• ideally, the two meshes should not be identical (due to math rounding errors for zero distance calculations), so one mesh should be ever-so-slightly larger than the other (doesn't matter which).

• re: morph transfer vs. shape transfer... shape transfer is closer in functionality to 'shrink-wrapping'.  Morph transfer attempts to create morph-deltas on one item that would be equivelant to the morph-deltas on another item that used a different topology (geometry layout) - it doesn't try to make the shapes match each other, just creates morphs that move similar groups of vertices when a morph is applied.

• re: running multiple comparisons... this is referring to the typical situation where each mesh'es 'body part' groups are cut differently.  For example, V4's "chest" geometry is cut quite differently from V3 (V4's chest group includes the breasts... in V3 the breasts are in the collar groups).  So in order for you to fit a V4 shirt onto V3, you'd have to do comparisons for chest->chest, as well as chest->left collar, chest->right collar and likely chest->neck.  Each of these comparisons creates new weight data files (and folders, I think), which can later be merged into a single list (I think). 

Quote - The timing tests are very exciting.  Whoofa!

You're testing with Poser 7?  Or are you just sending "dummy" info to a standalone Python script?

Yes, fire up Poser 7, import V4 figure, run script.

Quote - - re: morph transfer vs. shape transfer... shape transfer is closer in functionality to 'shrink-wrapping'.  Morph transfer attempts to create morph-deltas on one item that would be equivelant to the morph-deltas on another item that used a different topology (geometry layout) - it doesn't try to make the shapes match each other, just creates morphs that move similar groups of vertices when a morph is applied.

It may be easier to understand this way:

A hypothetical Morph Transfer:  V4 "nose bigger" -> Jessie would not result in a morph on Jessie that made her look like V4 with a bigger nose, it would still look like Jessie, with a bigger nose morph.

A hypothetical Shape Transfer: V4 -> Jessie would attempt to create a morph on Jessie to make her look like V4 (ie. Jessie shrink-wrapped to V4).

@ Miss Nancy (somewhat incomplete responses)

6)  What TDMT does is find the location where a given vertex from the target actor intersects a polygon on the source actor.  It stores this data in a .vwt file, to be read back and applied for the morph transfer.  Transfer morph takes this data and literally ports the morph deltas for the source over to the target (well, literally, through the weighted correlations).  That means that the same reshaping is being applied to a different source shape - which can produce less-than-desirable results, if your source and target actors don't have similar shapes to begin with.  Transfer shape takes the same .vwt data and uses it to port the current shape of the source over to the target, rather than porting morph deltas.  As such, you can get a result which might come closer to the original morphed shape of the source, if the actors are dissimilar in shape.

The thing is, right now TDMT isn't handling multiple actors very effectively.  So if you want to shrink all the actors of one figure to all the actors of another, you'll have to make multiple runs of the script and you'll likely end up with problems along actor edges, as JoePublic's tests have shown.  A way around this might be to shrink the base figure geometry for one figure around that of the other.  This might take awhile, however.  My current shrinkwrap script might work better for you, but I'm still working out a method for handling multiple actors (and the current form of the script leaks RAM like a sieve during that part of the process....)  I think Wardrobe Wizard currently defines a better toolset for the kind of problem you're trying to approach in your example.

7)  The transfer process requires data for each vertex, in the .vwt file.  If you've screened by material or region, you've presumably left some out.  If you transfer morphs without .vwt data for all verts, those which are omitted will simply not be affected by the transfer.

You might want to screen by materials, say to improve correlations between two heads.  With no screening, you may end up with lip vertices correlating improperly to the teeth or inner mouth polygons in the other mesh, for instance.  To work with this, run TDMT with the inner mouth materials excluded.  Then run another comaprison wwhich omits all materials except those which were omitted in the previous run.  That is: first run = skin, lips, eyebrows; second run = inner mouth, teeth, tongue.  This will give you two .vwt files for the same geometries, which need to be merged (they don't have to be, but it will be simpler for you than running multiple transfers later on).

So, only click the "analyse" button once for each script run.  But you may want to make multiple script runs.

8)  The file path handling for TDMT is currently one of the less-accessible aspects of the script.  I'm in the process of changing it, so hopefully that will improve.  The merge function is in the File menu.  I think I should try to explain this, along with the file path structure, in a separate post....

9)  Smoothing is optional, and it isn't subdivision smoothing, but basically averaging out the vertex positions in a morph.  If you've used Wings, it's a bit like the "tighten" function.  The results are somewhat similar to those given by the smoothing functions in Wardrobe Wizard.

10)  The Copy Shape button would be the one to use for any kind of shrink-wrapping.  With TDMT, it will only work on one actor at a time and it will require that you have a good .vwt file for the source-target correlations.

BTW, only slightly OT, if anyone reading this thread is using Cinema4D and wants to test my shrink-wrap plugin (which can work on entire meshes at one time), send me an IM (I only want a few testers, so first-come, first-serve).

Quote - ...The thing is, right now TDMT isn't handling multiple actors very effectively.  So if you want to shrink all the actors of one figure to all the actors of another, you'll have to make multiple runs of the script and you'll likely end up with problems along actor edges, as JoePublic's tests have shown...

I think you're mis-remembering this slightly... the problems along actor edges was because he was not comparing against multiple actors at the time (the missed hits would be found when the other actors were compared against).

But you're right in that the current script makes doing multiple-actor comparison and morph creation tedius... you basically have to do something like the following process:

1. transfer morph X, comparing chest->chest
2. transfer morph X, comparing chest->abdomen
3. transfer morph X, comparing chest->left collar
4. transfer morph X, comparing chest->right collar
5. transfer morph X, comparing chest->neck
6. set morph X on each of the above new morphs to 1.0
7. use Poser menu to "Spawn Morph Target", creating a new combined morph.
8. delete all those separate morphs
9. wash, rinse, repeat for any other morphs you want to transfer

...or something like that, depending on the actors and figures in question.

"I think you're mis-remembering this slightly... the problems along actor edges was because he was not comparing against multiple actors at the time (the missed hits would be found when the other actors were compared against)."

I did put some multi-actor looping into the script, to try to work with those findings.  I remember.  But my own subsequent tests revealed continuing problems with actor edges.  I used the script to port morphs for Vicky 1 over to her catsuit.  In many ways, it worked well enough, but there were problems along many of the body part seams.  I may have incorrectly assumed that mine was the same problem as JoePublic reported.  The results weren't really good enough for me to use, anyway.  I was better off using magnets to recreate the desired shaping.  That was much faster, and I didn't pull out any hair during the process.  LOL

Quote - ..just for completeness, here's the Numeric version of the above code:

Sorry, but whot you did has not mutch to do with using Numeric. What you do is taking a Numeric-array and transfer element by element back to python to compute results with pure Python.

What I meant with "Using Numeric isn't easy" and, most important, "consistent use of Numeric" is something like this (Numerc documentation):

Ufuncs can take output argumentsIn many computations with large sets of numbers, arrays are often used only once. For example, a computation on a large set of numbers could involve the following step

dataset = dataset * 1.20

This operation as written needs to create a temporary array to store the results of the computation, and then eventually free the memory used by the original dataset array (provided there are no other references to the data it contains). It is more efficient, both in terms of memory and computation time, to do an "in-place" operation. This can be done by specifying an existing array as the place to store the result of the ufunc. In this example, one can write:

*multiply(dataset, 1.20, dataset)
....
(see orignal doc for more)

Ufuncs have special methods The reduce ufunc method If you don't know about the reduce command in Python, review section 5.1.1 of the Python Tutorial ( http://www.python.org/doc/tut/functional.html ). Briefly, reduce is most often used with two arguments, a callable object (such as a function), and a sequence. It calls the callable object with the first two elements of the sequence, then with the result of that operation and the third element, and so on, returning at the end the successive "reduction" of the specified callable object over the sequence elements. Similarly, the reduce method of ufuncs is called with a sequence as an argument, and performs the reduction of that ufunc on the sequence. As an example, adding all of the elements in a rank-1 array can be done with:

>>> a = array([1,2,3,4])

>>> print add.reduce(a)

10

I suppose the benefit of having a specially-designed Vector .pyd for Poser Python would really be accessibility.  I don't know whether Numeric can be as fast as or faster than what Spanki is doing, because I don't understand Numeric.  The docs for the module are unclear and perplexing, as are any examples I've seen.  A tool is less useful if no one understands how to use it effectively, unfortunately.  How many Poser Python users use Numeric?  How many understand how to use it effectively?  A more straightforward tool would be a true boon for PPy, IMO.

So, no, we're not using Numeric at all effectively.  :(

In the meantime, I'm trying to read up on it again.  In the examples I've seen, it looks like Numeric's internal tools can only handle some of the needs of matrix handling.  Some functions, like inverting a matrix, were approached using the Linear Algebra module, which, as I said, is broken in P7.  It doesn't seem like Numeric or the other modules provided with Poser's build of Python really offer a full (much less accessible) toolset for 3D math.  Kind of a bummer, if that's actually the case....

(Mild irony alert: TDMT may or may not be a tool, itself, which no one really understands how to use, aside from the programmers....)

Quote - Sorry, but whot you did has not mutch to do with using Numeric. What you do is taking a Numeric-array and transfer element by element back to python to compute results with pure Python...

 
You're correct, but the functions you listed wouldn't really be any use to us, as far as I can tell (although there may be others that would help).  My test example is a little misleading, because I am using several 'dummy' values that aren't changing.  In the real code, those are different and/or computed for each loop.  It also doesn't have the 'if xx' tests of the real code in it (where it would break out of the loop early), so we want to be testing (and doing math on) them one at a time.

Anyway, here is a link to my current test-script and the Vector module (readme file included).  I'm always interested to learn new things, so if you can find a way to make the Numeric test faster (within the requirements above), I'm all ears :).  But that may just be an acedemic excersize...

With a few more additions/changes to the second test (python routine using vector storage method and features), that code is now almost 5x faster than the non-vector test.  But, the third test (test routine done by the module) is where the money is... it's about 10x faster than the slowest (current TDMT-style) code.  Once we have a few more classes and functionality ported over into the .pyd file, we won't have any more need for Numeric.

You are right, Numeric is a modul that just replaces something other with something faster. It's a tool your programs logic has to be designed for to be effective. In this case, it's too late to use it.

@Cage: Poser Python is broken, not Numeric or other tools. That's the reason why I don't try to use it directly. To mutch restrictions with Poser-Python, to mutch glitches and to mutch that avoids serious programming (threads, for example).

Numeric (better: NumPy/SciPy) has a very large userbase. It's one of the swiss-army knifes for scientists.

@Spanki: Part of my development is working with cameras. There is a tool available in C source to use a webcam with Python. This may be of interest, because it shows how to use a static memory buffer from both sides.
http://videocapture.sourceforge.net/

I think I sounded grumpy last night.  Sorry - I was fighting with my own limitations, trying to plug a reference-looping RAM leak (yet again).  Sigh.

But I don't mean toi suggest that Numeric is useless or that no one at all understands it.  More that it isn't terribly accessible to users of PoserPython, and doesn't really seem to be used much or, presumably, understood by the PPy user base.  If we want to think in terms of expanding the usefulness of Poser itself from within the constraints of Poser Python, it seems to me that we need to step outside of the limitations and complications which Numeric represents.  My excitement about what Spanki's doing lies in the fact that it could extend the utility of Poser Python a great deal.  Maybe more people will write scripts which handle geometry alterations in Poser.  One hopes!

Grabbed the example.  I'll try it!  :D

'Traceback (most recent call last):
  File "C:Program Filese frontierPoser 7RuntimePythonposerScriptsTDMTfilesspanki_vectorvector_test.py", line 13, in ?
    from vector import Vector
ImportError: DLL load failed: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail.'

I got the above error when I tried to use the example script.  Running Poser 7 with the latest available patch.

"To use the new type,
make sure you have the vector.pyd file in the Python/DDLs folder, then in your script add the
following somewhere near the top of the file:"

In the readme, is the "DDL" reference a typo, or does the .pyd need to have a new DDL folder created to foil the error I received?  I placed the .pyd file in Python/DLL.

And, unfortunately, I've no idea where to find my event log for Poser 7.

BTW, I think the actor edge problems I reported above were probably due to the clearing of the match distances list at the end of each loop, and/or the use of the -1 screening, as noted a page or two ago.  I did add code to optionally loop through neighbor actors, but there's no point in the process where TDMT tries to avoid multiple hit references or consider better hit options, between actors.  The loop structure of linecast (and possibly linecast_loop) needs some revision before multiple actors can really be handled effectively, I think.  Ideally, we would virtually merge the geometries and sort out the hits at the end (hence my thoughts, up there, about using vertex and poly class objects to map between actors and tri/poly types).

Oh, and I'm running Poser 7 on Vista (sigh).  I wouldn't be surprised if Vista is somehow to blame for my .pyd error.  Why not?  It messes up almost everything else....  Cough....

Just to clarify, the vector.pyd file should be placed in the PoserRuntimePythonDLLs folder.

Is that where you put it?

Yes, that's where I placed it.  I tried using a DDLs folder, but then Poser wouldn't acknowledge the existence of the file.  So it is finding it, it just doesn't quite like what it sees, apparently.  :(

Looks like a path handling error.  You may be the first one to test this on a Mac.  I'll have to check and see if I'm using any path handling which could end up being OS-specific, anywhere.

Thanks for the info, Miss Nancy!  I'll see what I can work out.

I couldn't get any results with mokei.cr2 and vvcutout.cr2, so I switched to mokei.obj and
vvcutout.obj, but still no results.  it appears that "analyse" happens very quickly (analyse
button goes from blue back to normal after a few seconds).  I'm guessing that "transfer shape"
calculations are active as long as the "transfer shape" button remains blue (more than 20 min.
in this case).  when I tried to spawn morph, then delete morph prior to the end of calculations,
poser 7 quit unexpectedly.

so i finally tried to "transfer shape" from the poser ball to the poser box.  it actually got to
the point where a morph shape transfer dial appeared in the box parameter list, but
poser 7 quit unexpectedly after I tried to change the setting of said dial, which had no
effect on the box shape.

Log Name:      Application
Source:        SideBySide
Date:          3/16/2008 4:05:19 PM
Event ID:      33
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Cage-PC
Description:
Activation context generation failed for "C:Program Filese frontierPoser 7RuntimePythonDLLsPPy_vector.pyd". Dependent Assembly Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.
Event Xml:

 
   
    33
    2
    0
    0x80000000000000
   
    10874
    Application
    Cage-PC
   
 
 
    Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
    C:Program Filese frontierPoser 7RuntimePythonDLLsPPy_vector.pyd
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
 

Here's what my event log reveals.  Apparently side-by-side is a Windows (Vista?) matter.

Quote - "To use the new type,
make sure you have the vector.pyd file in the Python/DDLs folder, then in your script add the
following somewhere near the top of the file:"

In the readme, is the "DDL" reference a typo, or does the .pyd need to have a new DDL folder created to foil the error I received?  I placed the .pyd file in Python/DLL.

 
Sorry, yes, 'DDLs' is a typo - it should read 'DLLs'.

Hmm... I'm not sure what's happening.  It kinda sounds like python versions or mis-matched or something.  Out of curiousity, have you installed Python 2.4 on your system? (might be a registry key thing)

...cross-posted... hang on, it might be a compiler library dependency.  Let me look around a bit.

@Miss Nancy:

It looks like all three errors are due to path handling.  The script is expecting to have received a path pointing to the .vwt location, but has received a NoneType object.  Am I correct in the understanding that you are running this on a Mac?

Hmm.  If Poser is crashing when you try to use or delete the new morph dials, presumably something isn't finalized before you try that.  See if saving the .pz3, closing Poser, then re-opening the saved file helps at all with the crash error.  Was there any sort of error message associated with the applcation crashes?

@Miss Nancy:

I think I've figured out the problem.  This is actually a compatibility issue with Poser 7, I think.  I had similar problems when I first tested TDMT on P7.  Poser 5 was giving a blank string ("") when asked for GeomFileName() for an actor with embedded geometry.  Poser 7 returns None for the same situation.  The way to counter this is to add conditions which handle None to the geomPath function.

If you're comfortable editing a copy of the TDMT.py, you could try replacing the existing geomPath function with the one below.  I'll see if I can put together a corrected version of the .py file for you, in the meantime.

    def geomPath(self):
        """
        Get the necessary actor and geometry file information, to construct the
        dataPath.
        """       
        self.verts1 = vertexPos(self.a1.Geometry())    #Fill the vertex lists (for octree preview)
        self.verts2 = vertexPos(self.a2.Geometry())    #(These are called by linecast())
        if not self.dataflag:
            self.gf1 = self.a1.GeomFileName()
            if self.geomVar1.get() == 1 or self.gf1 == "" or self.gf1 == None:
                self.gf1 = self.handleGeom(self.a1,self.gf1)    # Handle custom geometry options
            self.gf2 = self.a2.GeomFileName()
            if self.geomVar2.get() == 1 or self.gf2 == "" or self.gf2 == None:
                self.gf2 = self.handleGeom(self.a2,self.gf2)    # Handle custom geometry options
            if self.gf1 == "" or self.gf1 == None or self.gf2 == or self.gf2 == None"": return
            self.gf1 = os.path.splitext(os.path.basename(self.gf1))[0]
            self.gf2 = os.path.splitext(os.path.basename(self.gf2))[0]       
            self.dataPath = get_pathname(self.gf1,self.gf2,
                                         self.remove_fignum(self.f1,self.a1),
                                         self.remove_fignum(self.f2,self.a2))
        self.dataflag = 1
        self.showpath()

I'll try to edit said file.  it looks like the attached in BBEdit, which is the default OS X app for
editing cr2 files and python scripts, without altering the formatting.

I should say that, in the case of the poser ball and box, it actually got to the point
where it created 2 folders at the top level of the tdmt folder, and it wrote
a vwt  file in a subfolder of each folder, but it crashed before I could save anything.
perhaps if I had step-by-step instructions on how to transfer shape from poser 7 ball to
poser 7 box, then I could see if it works in poser 7/OS X.  it would mean spelling out
absolutely every operation, on the assumption that I haven't the slightest idea how to do it.
tdmt for dummies, if you will :lol:

@Miss Nancy:

I was encountering similar Poser 7 crashes with TDMT myself, before I started making alterations to the script.  The problems for me seem to focus on the popup mechanism being used for some of the secondary functions, which is part of why I'm splitting the script up into smaller pieces.  You may be having the same problem, here.  In which case, I should try to get the new version together and try to get my FTP access to my site working so I can upload it.

Let me know if the new TDMT.py helps at all.  If you get new errors, let me know.  I'll do my best to debug this thing.

But I don't think the Flush() call is really necessary, either.  So here's a test replacement file for the tdmtUtility.py.  It needs to be saved with that name and placed in the TDMT folder with the other module scripts (all of them with names beginning with "tdmt").  Delete the .pyc files in that folder, so Poser will recognize this new one.  Just replace the old tdmtUtility.py altogether.

The script on page one is slow, has a major RAM leak, and doesn't work well if your target geometry has a higher vert count than your source geometry.  And it doesn't do shape transfer, only morph transfer.  The new version(s) have been shown to work.  There are just some new bugs being revealed which haven't been noted before, because they haven't been a problem for anyone else (or because no one else has used the script?).  There are version-specific problems possible with Poser (I tested on Poser 5 while developing) and cross-platform issues possible for Mac users, with path handling and file IO matters.  We'll work it out.  Don't panic!  :D

My apologies for the extended series of errors, however.  All I can say is: these are new to me.  :(

A question: what does the acronym ISTR mean?

A bit of a side note: I managed to work decent multi-actor handling into the shrink-wrapping script, but it looks like the process is going to be slow, due to the fact that the Geom module really wasn't designed for multi-actor support.  I'm left having to loop through multiple meshes in multiple octree zones, which is about four times slower than running the same comparisons against source geometries which were exported merged and re-imported for a test run.  The alternative, pre-compiling the vertex data into a multi-mesh regions list before the collision run, creates a huge RAM leak.  So I'm really kind of hoping Spanki's .pyd works out, to be able to develop better multi-actor handling for TDMT.  The geometry handling needs to be re-worked in order to accomodate such an approach.

Update:

@Cage,
I think I fixed the loading problem... see below.

Here's some new timings...

Hip - [ 1152  :  1279 ]<br></br>
---Test1 Numeric: 0.922000169754<br></br>
---Test1  Vector: 0.202999830246<br></br>
---vector.timetest1(): 0.0310001373291<br></br>
Abdomen - [ 2270  :  2362 ]<br></br>
---Test1 Numeric: 1.7349998951<br></br>
---Test1  Vector: 0.390000104904<br></br>
---vector.timetest1(): 0.0319998264313<br></br>
Chest - [ 3732  :  3914 ]<br></br>
---Test1 Numeric: 2.90600013733<br></br>
---Test1  Vector: 0.641000032425<br></br>
---vector.timetest1(): 0.0620000362396<br></br>
Neck - [ 676  :  754 ]<br></br>
---Test1 Numeric: 0.546999931335<br></br>
---Test1  Vector: 0.125<br></br>
---vector.timetest1(): 0.0160000324249<br></br>
Head - [ 14022  :  15078 ]<br></br>
---Test1 Numeric: 11.1870000362<br></br>
---Test1  Vector: 2.45299983025<br></br>
---vector.timetest1(): 0.235000133514<br></br>

...there's several changes in this version. 

1. The name of the extension has changed from 'vector.pyd' to '_tdmt.pyd'.
2. be sure to read the top of the new "TDMT_pyd_Readme.txt" readme file.
3. be sure to read the top of the new "TDMT_pyd_Readme.txt" readme file.
4. be sure to read the top of the new "TDMT_pyd_Readme.txt" readme file.
5. Ok, I hope that makes my point :) - no sense in me re-typing stuff I wrote in there.
6. There's a new basic TriPoly type/class which I haven't had a chance to finish working on yet (let alone document it), but the new/updated test script uses some of it's features.

So, based on the Head timings above, we go from 11 seconds (uing current-type tdmt script code) down to less than a quarter of one second (using this update).  The new test script takes the time to generate polygon, tripoly, face normal and plane equation lists in both cases (the TriPoly type computes and stores the face normal and plane equations).

My time is going to be more limited this week (I've been slacking off on some real work, doing this stuff), but I'll try to get another update and/or more docs posted in the next few days.

@Miss Nancy, just a heads-up, this is not a general purpose thing for you.. it's just some geeky test stuff :).

@Cage,

Sorry, I really can't take any more time to think about and then respond to your multi-actor queries... I kinda stole a lot of time over the past week working on this stuff and need to go get caught up.

In general, my advice would be to... not do anything yet.  I will continue working on this as I have the time, but as you might notice, it's starting from the bottom and slowly building up from there to higher level functionality. For example, the new TriPoly class uses a Vector as a face normal.  And now that we have a triangle structure (so I know what verts make up the triangle), I added the Generate_TriPoly_Normals() routine.  But that would likely - eventually - end up as part of a higher 'mesh' level class that kept track of various lists instead of (or at least in addition to) being a stand-alone routine as it is now. etc.

'Some' of this stuff is fairly particular to what we've been doing, but I don't want to tie it tooooo tightly to any particular methodolgy.  We currently have tons and tons of various lists of indexes from every which-a-direction and I don't plan to tailor to all of them specifically (I don't want a Vector or TriPoly carrying around a couple dozen indexes - but we can add a few, after re-evaluating the need for them).  I just want to provide some tools to speed up the slow parts that can use common types/classes for (potentially) different purposes.

Before I go absent, here's a quick list of the (current) TriPoly members...

Creation:

TriPoly( int v0, int v1, int v2, int polyNdx, int triNdx
)<br></br>

Members:

v0.............. (int)    vertex index<br></br>
v1.............. (int)    vertex index<br></br>
v2.............. (int)    vertex index<br></br>
polyIndex....... (int)    index of the polygon this
triangle was spawned from <br></br>
triangleIndex... (int)    index of the triangle
within that polygon<br></br>
plane........... (float)  plane equation<br></br>
normal.......... (Vector) tri-poly face normal<br></br>

...the above can be assigned or retrieved, using the names given above, but you need to either assign the normal and plane values by hand before retrieving them, or call the:
 
Generate_TriPoly_Normals( list_of_tripolys, list_of_vectors )

....routine to get them generated for you first (but don't call that before filling in the tripolylist and vectorlists :) ).  The example script has examples of much of this, along-side alternative code that does the same thing.

Great work, Spanki!  I'll test the new one straightaway.  There's no need to hurry.  Thank you immensely for all your recent input. 

I think I'm going to get my altered version of TDMT, which is refined (hopefully) for use with Poser 7, together and post that as soon as I can.  If the .pyd develops effectively, the whole script will change as a result, but perhaps a better-working interim release will be helpful.

Hmmm... it just occured to me that moving stuff to a .pyd would leave out Mac support unless we had a Mac binary as well.  I might be able to eventually get it compiled for Mac as well, but that's a whole other development effort ( I don't have Poser on Mac, or even Python, etc).

I'm a little surprised to hear that it works on Mac at all.. I thought tkinter was broke on Mac?  Anyway, once you get a Mac-stable version, I'd stash that release off somewhere before doing any port to use features in the .pyd file.