Ok.. I replaced the archive with a fixed one... turns out that mesh.GetVertTriPolys() was bugged.  With the fix in place, I can now turn a sphere inside-out :) (which means that disabling backface culling is working as expected).

Woo!  More new stuff!  Correlate to self!  Woot!  :woot:

I'll need to try this.  :D  I haven't read all your notes yet.  Actually, I signed on to ask a specific question about how the .pyd handles some things.

Would it be better to create a list once at the start:

lMesh.baseverts = lMesh.mesh.GetVertices()

Then hold it the whole time to be used as needed, or to simply call your function to create it at need (each step, in this case).  Basically, I'm wondering about what kind of overhead is involved in the call to create the list.  Do you calculate it each time, or is it already there, waiting to be called?

I'll check out the new .pyd and be back ASAP with excitement!  :D

It's not generated (merely 'fetched' from Poser and converted to Vector() format, in this case) until it's needed by some other call, including mesh.GetVertices()

EDIT: UNTIL you've called that (or some internal function calls it), my internal pointer is set to 'None'.

Once it's been created, I keep it around for future use, unless/until your mesh variable falls out of scope, or you intentionally 'del' it, or the new mesh.StructureChanged() call is made.

But for practical purposes, there's no reason to wait, unless you're going to free up some other list to make more room before getting that list.

ANOTHER EDIT: ...but keep in mind that now that I'm always returning clones of my internal lists, there would actually be two copies of it in memory, so it really will depend a lot on what a particular script is doing and when it needs some list or another.  The intention behind the Mesh class (in general) was to keep you from having to worry about various lists, unless you actually have some other use for it.

So... it sounds like maybe it might make sense for me to call the function with each step, rather than having another Very Large Array hanging around pointlessly in memory the whole time...?  I'll try it.  :D

I'm excited about the new changes and additions, but before I can test anything, I need to grasp when I should deal with the mesh.VertPositionsChanged() call.  In my case, I'm carrying around settable lists for vertex positions and vertex normals, and I've been passing those into the collision handling.  Do I need to use mesh.VertPositionsChanged() in addition to this, or can the new call somehow replace the need for my doing some of that (normals, perhaps)?  Or what?  Is it something I can ignore in this case?  There weren't any hints in the example scripts, so I'm just puzzled....

This is becoming a regular Swiss Army Knife!  Whoo!  A great deal of broad utility!  Fantastic!

Uhm, actually one of my points was... as long as you ever have it all in memory at any one time, you might as well have it all in emory, as long as it needs to be.  Anything you're going to be using within each loop you should just keep around for the duration.

re: mesh.VertPositionsChanged() ...

Here's the deal... previously, when you got the world verts, you were modifying those directly (even though your comments seemed to imply that you intended to be getting a 'copy' of them).  So anytime you modified them (ie. like in IntegrateSysOverTime()), you were modifying the ones that the Mesh class knew about.  Which, btw is the only reason that the correlations kept working.

Now that you're getting a real 'copy' (and not a pointer to the originals), every time you move th verts around (either setting the shape or updating the (active) morph values), you'll need to call mesh.VertPositionsChanged(), so the mesh can go grab the updated vertex locations and recompute the now altered/deformed poly face normals, etc.

Since you're generally just grabbing the vertex normals but then altering those anyway, there's no need to keep getting new ones (unless you want actual current vertex 'normals' instead of the ones you've been faking for 'projection direction' purposes).

Does that answer any (or all) of your questions?

...just to clarify on the (non-world) vertex thing...

What I would do is fetch them early on in the script and store them in your mymesh structure somewhere for future use.  After you're done fetching anything else for long-term use, just do a mesh.StructureChanged() and I'll free up my internal copy of those.

Since those are not needed or used by any other function in the .pyd file, they'll never get allocated again.  From that point forward, you're just moving the (world) vertices around, so mesh.VertPositionsChanged() is sufficient (when StructureChanged() is called, I delete all internal lists, when VertPositionsChanged() is called, I just set a 'dirty' flag on the relevent lists... in both cases the data will be re-fetched / re-generated if (and only if) it's called for again).

..just as another point of clarification, currently tripoly[x].normal and ngon[x].normal (normals of tipolys and ngons within the lists generated by the Mesh class) are currently generated using World vertex/normal values.  Currently, the functions within the extension that use those (the various Correlate() functions) all deal with world vertex/normal values exclusively. 

Yes, I think that helps me.  Thank you.  Takes me a bit to get my head around a new idea.  I tend to think immediately that I understand, but then I try to apply it and realize I don't.  I find this tendency of mine terribly frustrating, so I'm sure it's a bit irritating for others, too.  So - thanks again for taking time to explain!  :D

Unfortunately, there were thunderstorms.  I shut down and unplug everything during thunderstorms, which means I basically got nothing done on the computer during the whole latter portion of the day.  :(  So this will have to be something I sleep on, it seems.

Okay.  I've got it working.  :D  It's all fairly straightforward.

Thanks for the suggestion about the bounding boxes.  That has helped speed things up.

Now... I'm working on trying to figure out how to use the .pyd collision handling to do cloth polygons to actor vertices, instead of cloth vertices to actor polygons.  Presumably that would handle corners better.  So the script is currently a bit of a mess.  I'll work on it a bit and post later tonight....

I added some edgelist generation methods to the MeshType class, so here's an update.  I also integrated a few changes into my included sample script ('pyd_shrinkwrap_test.py').

I also made a few simple changes to your most recently posted script and linked that as an attachment to this message (as usual, just search for 'Spanki' to see the changes).

Edge lists are good!  Thank you!  And I'm always exceedingly grateful for your script pointers (although I may not always understand them initially...)!  I'll check it all out.  :D  :D

Now I'm going to try to adapt the more elaborate cloth script for the new .pyd.  I think the Mesh type should make multi-actor handling much easier and more straightforward.

Cool.  I'll take a look at them, but I'm curious exactly how you're determining that you're having a ram leak?

BTW,  "mesh.CorrelateByIndexToSelf()" is bugged.  Don't try that until the next update.

I have a freeware RAM monitor running (on Vista), which is called RamBooster.  It registers about 4MB of loss with each run of the script, which is doesn't do for the cloth.  It's exactly the same RAM loss I experienced with the earlier version of the multi-actor shrinkwrap.  Presumably I just need to track down where I'm looping references.  Do you pass any references in the hit data?  If it isn't all fresh copies, that might be the source of my problem, since I del the Mesh instance which created the hit list, but keep the hit list for the subsequent distance screening loop.

The attached copy of the elaborate shrinkwrap script has a couple of corrections....

Quote - I have a freeware RAM monitor running (on Vista), which is called RamBooster.  It registers about 4MB of loss with each run of the script, which is doesn't do for the cloth.  It's exactly the same RAM loss I experienced with the earlier version of the multi-actor shrinkwrap.  Presumably I just need to track down where I'm looping references.  Do you pass any references in the hit data?  If it isn't all fresh copies, that might be the source of my problem, since I del the Mesh instance which created the hit list, but keep the hit list for the subsequent distance screening loop.

Hmm.. there shouldn't actually be anything you can do in the python code to cause a memory leak.  deleting objects is not necessary, unless you're done with it and the script still has other things to do.  Otherwise, you can just let variables fall out of scope (including script termination).

• Explicately deleting objects doesn't necessarily free any memory... it just decreases the reference count on some item.
• If/when the reference count happens to hit zero, then the item is freed.
• If any other variable is still in scope and holding a reference to it, it won't get freed.
• Once your script terminates, it no longer holds any references to any items.

...so again, assuming there's no bug in C code somewhere (either my extension, or the Python interpreter itself, or some other extension), it shouldn't be possible for you to be causing a memory leak.  On the other hand,  you could del something more than once, but that might potentially cause some item to get freed before it was supposed to be, likely causing a crash, not a leak.

Other possibilities:

1. creating a morph cause Poser to use more memory to store that morph... are you deleting those new morphs from the mesh before checking your Ram guage?

2. once an extension (.pyd) file is loaded by Poser Python, it stays in memory until you quit Poser (and maybe not even then)... so that (those) takes some memory as well.

3. I've tried to keep pretty good track of reference counts in the C code, but it's possible I missed something.

So when you're testing memory, you should (at least):

• run Poser
• load whatever models you plan to work with
• run whatever script you're testing at least once.
• delete any newly created morphs from the model(s)
• (now) get a base memory reading
• run the script again
• delete any newly created morphs after the script has terminated
• check memory again

Aha.  Thank you.  My understanding (gathered from the early parts of this thread, actually) was that a reference can become fort of "orphaned" if it's embedded in a container (perhaps a list two-deep) and the original object, source of the reference, is deleted while the reference in the container continues to exist.  I had understood that under such circumstances, Python will get a bit confused when it goes to count down the references and can't find the original for the list reference.  I may have completely misunderstood the process, as I have found it rather confusing, in spite of having run all the tests early on with reference counting and garbage collecting, to try to get the hang of it.  If it doesn't necessarily happen that way, I can feel a bit better about the universe actually making more sense to me.  LOL

I don't think the problem can be related to morph creation - otherwise I'd see it cropping up more broadly.  This occurs when I loop on the multiple actorsin the comparison cycle.  It was happening before the .pyd was introduced; it was happening with the earlier .pyd version, prior to the Mesh approach; and it looks like the same thing is still happening now - whatever that thing may be.  Hmm.

I'll try the process you outline above, to do some more controlled testing.  :D  Chances are, this is another goofy Cage false alarm which can be explained by kludge-worthy coding on my part....

One problem is that we don't really know what or how Poser is managing memory internally, so it would be hard to pin it down to some particular operation.  Having said that, I'll continue to trippl-check my reference tracking, because the C code can indeed cause leaks.

My current understanding of the Python side of things (after working on the .pyd and being exposed to what's going on under the hood) though is that there really isn't anything the script itself can do to cause leaks.

But if you can boil it down to a simple test that seems to show repeatable results leaking relatively large amounts of memory, that would be worth looking into.

The .pyd doesn't retain data for each Mesh once they fall out of scope, does it?  Hmm.

I'll see if I can develop a consistent test of some sort.

No (not supposed to, at least)... when the script variable is freed (falls out of scope, or specifically deleted) - more specifically, when the reference count of the variable reaches zero - then Python calls my 'free' routine, where I decrement the reference counts I'm holding on the various arrays/data/members, then free the class/type structure.

If the script still has reference counts on any of those arrays/member elements, then they don't actually get freed (yet), but the class/type structure does.

In other words, it's supposed to all take care of itself.  Each and every Python Object (whether it's an int, float, list, tuple, bool or .pyd implemented extension-type, etc) has it's own internal reference count.  When (and only when) that reference count reaches zero, the Python interpreter calls that object's free routine.

The Python interpreter should be taking care of reference counts for everything the script is doing (re-assigning variables/pointers, tracking local vs global scoping, etc), so it should not be a concern for the script writer at all.

http://evanjones.ca/python-memory.html

http://utcc.utoronto.ca/~cks/space/blog/python/DebuggingPythonMemoryLeaks

I think these are where I got my ideas about memory leaks in Python.  I'm not trying to challenge anything, just pass along what I've read.  The early version of Geom seemed to have a leak, and the smoothing functions for TDMT still seem to have one.  At least one PoserPython script exists out there (it might be a later version of Walk This Way?) which goes to great lengths using the gc module to try to plug an apparent memory leak, according to the comments in the script.

But I'm just looking this up tonight because I wasn't able to get any time in today on Python, so I'm trying to contribute some little bit to the matter, anyway.

And, really, it's not a huge big problem, in the current situation.  The earliest versions of the script in this thread (well before it was TDMT) had RAM consumption problems, readily grabbing up hundreds of megs in a run.  A few MBs here and there is no problem, compared to that.  I'm just all flinchy about such things, after that early experience....

*"WARNING: Poser 5 suffers from memory leaks (I don't know about Poser 4). This script will use HUGE amounts of memory (easily over 1 GB!) when applied to a long animation of a complex scene. You can work around this problem by applying the script to a few frames. Then save the scene, restart Poser, and apply the script to the next couple of frames. Probably 50 to 100 frames at a time will prevent you from running out of memory.

Legal stuff: None. Use this script any way you want.

Happy animating!

svdl"

Here we go.  From the readme of a later version of WalkThisWay.  I guess Ockham handed maintenance of the script over to svdl.  I'm not sure where to find the script online.

Killed it again, haven't I?  sob  I haven't figured out a decent test for the apparent RAM leak....

I actually have a question about the Mesh type and the earlier functions.  In the shrinkwrap script, I have cases in which I need to get new vertex normals, and when using the TDMT Geom module and, later, PolyFaceNormals() I was able to get them from the points list.  This list is the modified verts list.  Using Mesh.GetWorldNormals(), I don't have to option to submit a vertex list to the function.  So if PolyFaceNormals() is going to be deprecated at some point, I'll have to set the morph each time I want to refresh the normals.

So I'm wondering: will PolyFaceNormals() be going away in the future?  If so, can the Mesh type be given the option to get worldnormals from user-submitted vertex positions?

Not killed - as mentioned, I just have limited time to work on this (next to none, currently).

When I get time again, I'll think about your question(s) in the overall context.  For the time-being at least, those functions are still there.

Righty-o!  I'll stick with using PolyFaceNormals() for that purpose, for the time being.  Thanks for responding.  :D

Actually, I'm going back to doing it manually, for this purpose.

Syntax: PolyFaceNormals( polylist, vertexlist)

Syntax: PolyVertexNormals( polynormlist, vertpolylist)

VertexPolys() - DEPRECATED: see VertexNgons(), below

Syntax: VertexPolys( polylist, numVerts)

Essentially, the approach is already deprecated, as it relies on a deprecated function....

No biggie.  Just making a note of it.  :D

The functions are all still there (in case they ended up being needed), so the fact that you want to be able to use them is usefull info to me, for planning purposes.  If it turns out that functionality is still useful, then the functions will either stay there or some other means of doing the same will be made available.

Can do.  Actually, I reverted to using the deprecated functions rather than doing it manually.  I guess I sort of freaked out on it... I got mixed up between new Ngon functions and the old Poly list-driven functions, and I kept locking up Poser by mixing them.  When I posted, I thought you'd already removed the deprecated functions (in spite of the point of a warning of deprecation... is that a word?) because I couldn't figure out the Poser crashes.

Sigh.  There are some days when I just shouldn't try to make my brain do anything.  Perhaps I need more sleep....

Sorry to be a pest.  And thank you for the response....

Kind of neat.  :D  Bravo Spanki, for making it all possible!  :D

That's pretty cool, actually.  I'm surprised you got the ears done so well.

A lot of jiggery-pokery with magnets, for that.  But thank you.  It's been an easier process than comparing V3 and V1, because I have a bit more flexibility in the process due to the fact that I'm building a new mesh base.

I've mainly used the .pyd shrinkwrap for the above.  I think it shows how the results from that are better than those from the "classic" TDMT... so far.

And... this silly sub-project is going to send me off on UVs again.  The UV handling in the posted TDMT is completely knackered.  I'm going to have to try to make it work.  That has me wondering: do you think it would be at all advantageous to be able to gather the parametric coordinates for a mesh, using the .pyd?  Could 2D parametric coords help us improve something like 2D UV handling?  Is that something you've tried in your own explorations of the area?  No rush on an answer.  Just add that to the list of silly Cage questions, for when you have a bit more time....  I need to post such thoughts when I have them, or they'll get lost altogether.

Another question to add the the queue (sorry... Cage is inquisitive).

*"Update 03/21/08:  Weights now being set...

The 'Weights' value(s) are now set/valid in the list returned by the CorrelateMeshVerts()
routine. Also note the 'HitDelta' value added below... this is the delta used by shape_transfer()
or shrink_wrap() type code and is also the value saved to the weight files."*

Based on the above, I assumed the hitlist weights were being set and I adapted the .vwt save routine for .pyd use.  I'm comparing using Mesh.CorrelateTo().  The saved .vwt file consistently writes one 1.0 weight and two 0.0 weights for each hit.  Here's a sample listing:

As written using the .pyd weights:

w 1535 2028 2153 2177 0.0 1.0 0.0 1.36664070909e-005 1.24608113424e-005 -2.71567055685e-005 8506

Same vertex, same mesh comparison, using TDMT classic:

w 1535 2140 2152 2153 0.0177274320282 0.120319208833 0.861953359139 -3.77376342688e-006 -2.86467008559e-006 8.37792508411e-006 8623

And it's like that throughout the file.  So I assume implementation of hitpoint Weights may just be incomplete for correlation methods other than C*orrelateMeshVerts()? 

*But there's more to it than that.  Hmm.  The correlation indices don't match either.  I guess I need to check my code to be sure I haven't done something wrong, as usual.  But I don't see what I could be doing to render those weight results....

Okay.  I pulled up a bad TDMT .vwt file for comparison.

As written using the .pyd weights:

w 1535 2028 2153 2177 0.0 1.0 0.0 1.36664070909e-005 1.24608113424e-005 -2.71567055685e-005 8506

Same vertex, same mesh comparison, using TDMT classic:

w 1535 2028 2153 2177 0.0188956160789 0.97048276005 0.0106216238709 1.35098976427e-005 1.25283043355e-005 -2.72095887317e-005 8506

Another question for the Quizzical Cage Queue.  The HitPoint type includes a TriPoly type listing.  Is this a reference, or a copy?  If it's a reference, that may be the cause of my RAM issue.  I loop through a series of Mesh instances which exist only during the comparison loop and are overwritten as the loop progresses, but I save the HitPoint lists for use in a subsequent comparison loop.  If the HitPoints being saved contain references to the TriPolys of these Mesh instances, they could end up being orphaned references, such as are supposed to cause trouble for the Python garbage collector.  The Mesh objects to which they refer have been deleted, but the references persist and can't be cleaned up when it's time, because the object to which they refer no longer exists.

At least that's my understanding of how that particular memory snarl can crop up.  If these are references, I may be better off copying the data from the HitPoints rather than storing them....

Again, no rush on an answer.  I'm posting the questions as I have them so I don't forget to ask when you're able to answer....

Quote - And... on UVs again... 

 
At some point, I might port my UV code over - I'll give that some thought.

Quote - ...Based on the above, I assumed the hitlist weights were being set and I adapted the .vwt save routine for .pyd use.  I'm comparing using Mesh.CorrelateTo().  The saved .vwt file consistently writes one 1.0 weight and two 0.0 weights for each hit... 

Hmmm....

Quote - And it's like that throughout the file.  So I assume implementation of hitpoint Weights may just be incomplete for correlation methods other than *CorrelateMeshVerts()? *

Maybe... frankly, the weight computing code has not really been tested until now, so I'll have to look into this when I get a chance.  It's probably just incomplete/buggy.

Quote - Another question for the Quizzical Cage Queue.  The HitPoint type includes a TriPoly type listing.  Is this a reference, or a copy?  If it's a reference, that may be the cause of my RAM issue.  I loop through a series of Mesh instances which exist only during the comparison loop and are overwritten as the loop progresses, but I save the HitPoint lists for use in a subsequent comparison loop.  If the HitPoints being saved contain references to the TriPolys of these Mesh instances, they could end up being orphaned references, such as are supposed to cause trouble for the Python garbage collector.  The Mesh objects to which they refer have been deleted, but the references persist and can't be cleaned up when it's time, because the object to which they refer no longer exists.

At least that's my understanding of how that particular memory snarl can crop up.  If these are references, I may be better off copying the data from the HitPoints rather than storing them....

Again, no rush on an answer.  I'm posting the questions as I have them so I don't forget to ask when you're able to answer....

I don't have time to look into this right now, but at first-glance, my thought/understanding is that what you describe above can't really happen.  The HitPoint holds a reference count on the TriPoly, so the TriPoly can't be free'd until the HitPoint releases it's reference, as well as any script references get released.  In other words, if you free up the HitPoint, and the refernce count hits zero, my HitPoint destructor code will be called... that code will decrement the reference count on the TriPoly, but if your script still has a reference to it, that won't actually get free'd until the script is done with it, but the memory for the (rest of the) HitPoint sstructure will be free'd.  It should all work itself out.

It should, I agree.  But it doesn't seem to be.  As noted with the links I provided, the orphaned reference problem is apparently known to exist.  Perhaps I should ask whether those TriPolys called up by the HitPoints are linked to the Mesh objects.  The Mesh objects are being overwritten, because of the loop structure (I can't think of any other way to iterate over multiple Meshes, sadly).  If there are still references in play for their elements, then something may be ending up orphaned.  I'll see if I can work out a way to test this idea.  Sorry to keep going on about it....  It's a frustrating puzzle, on my end.

I checked my code, and I don't see anything wrong with it, but that doesn't rule out error on my part fully.  The weights the .pyd is giving me are always either:

1.0, 0.0, 0.0

or

0.0, 1.0, 0.0

The third weight, which picks up the slack from the other two in the code, is always zero.  Which suggests that when the first two are being calculated, one is always set to 1.0 and the other to 0.0.  The higher value of these two seems to end up with 1.0, based on a quick glance at my results.  At any rate, in every single case, one of the tri vertices had a full 1.0 weight and the other two were zero.  This looks to me like the .pyd is offering the wrong results, because of the consistency of the results and the zero value for the third weight....

I've ported over my initial UV code, which doesn't do anything to handle seams or splits, and it works so far.  Having UV transfer integrated into the .pyd would be fantastic, of course, but I wonder if it might be premature, until and unless we can work out a way to handle the seams.  I had a couple of new thoughts to try for that, which probably won't work, but I'll test them anyway....

Okay.  More testing.

It looks pretty definite that the odd weight results are coming from the .pyd, unfortunately.  I've varied the conditions and I still keep getting weights with the same pattern I've outlined above.

I think the RAM issue may be a Cage goof, caused by doing del on each Mesh instance during the loop.  Somehow Python may be able to overwrite the variable name and keep the data in memory for reference cleanup later.  I need to test a bit more.  There may be some oddities with reference passing elsewhere in my process.  At any rate, Poser now uses the same amount of RAM as before, but eventually releases it, although not right when the script finishes.  Previously, it's taken that RAM and never let go of it.  So I think I'm on the right track....

I have a proposal for expanding the .vwt file data.  If we add the hit distance to the end of each listing, it won't interfere with current read processes and it will open up new potential applications for the file type.  With multi actor looping, I can save a full .vwt comparison for each of the actors in the loop.  If distances are included, one can easily call up any combination of actor .vwt files and compare the distances to find the best matches.  Storing the distances could also enable the .vwt files to be used for a no poke function without running the comparisons at that time, by calling up the .vwt file.  Adding this seems like a good idea to me, but I don't want to change the type without getting your input.  We could also add a comment at the top, listing the various actors used in the multi-actor comparison, or something.  I assume tweaks to the comment portions are not an issue at all.

I'm still busy with other things, so I can't comment on all of the above yet, but...

**re: delete vs re-assignment...
**
Whether you just re-assign some variable or specifically delete it first should result in exactly the same thing...

 - When you re-assign it, it essentially "falls out of scope" (as far as the interpreter is concerned), so before assigning the new value to it, the interpreter (should) decrement it's reference count on that variable (potentially freeing the memory it uses if the reference count hits zero), then it assigns it to the new value.

• If you specifically delete it, you're just decrementing the reference count (potentially freeing the memory it uses if the reference count hits zero) and then you re-assign it to some new value in the script.

...again, I haven't had the time to look at the links you posted earlier, so if there's some bug in the interpreter that I'm not aware of, that might change things.

**re: hit distance -> .vwt file
**
I'm not opposed to this in general, except for the fact that... that distance is dependant on the conditions at the time that the correlation was done (morphs in play, world-space positions, etc) which is lost / not tracked in the .vwt file (and I'm not suggesting it should be :) ).

On the other hand, so is the rest of the data in the .vwt file, so it's probably no big deal.

re: actors, comments, etc.

I hate to comment on this without taking the time to re-aquaint myself with the entire .vwt file format and all related issues... .I know I've had multiple suggestions early on that were related to this particular subject, that may or may not have ever been implemented.

But in general, I'm not opposed to putting whatever you want in a comment record, until/unless it starts getting parsed by the script, in which case it should no longer really be a 'comment', but some (new) record type, instead.

Aren't the hit point positions themselves (and thereby our hard-coded deltas which derive from them) valid only for a correlation using two specific actors with two specific deformed shapes?  Once the actors are differently deformed, or re-positioned relative to one another, you're dealing with a separate correlation.  When I posted a bad example for the .vwt weight listings, above, I accidentally drew on a .vwt file for the same actors for which both were differently morphed.  The result was wholly different tri and vert correlations.

So I guess I don't understand what you're saying, in commenting about adding the distance.  Hmm.  I gather you don't like the idea....  Bummer.  :(

Regarding the memory issues, the Python interpreter for 2.4 and earlier versions was apparently buggy, which results in certain conditions in which there can be leaks.  One of those conditions would be orphaned references such as I've been on about.  Or that's what I gather from the info at the links.

Quote - Aren't the hit point positions themselves (and thereby our hard-coded deltas which derive from them) valid only for a correlation using two specific actors with two specific deformed shapes?  Once the actors are differently deformed, or re-positioned relative to one another, you're dealing with a separate correlation.  When I posted a bad example for the .vwt weight listings, above, I accidentally drew on a .vwt file for the same actors for which both were differently morphed.  The result was wholly different tri and vert correlations.

So I guess I don't understand what you're saying, in commenting about adding the distance.  Hmm.  I gather you don't like the idea....  Bummer.  :(

You must have missed this:

"On the other hand, so is the rest of the data in the .vwt file, so it's probably no big deal."

...in other words, having discussed the only issue with it, I then basically said "but - that doesn't really matter - go for it" :).

Oh.  I did miss that.  Have I mentioned that when I'm online during the day, I'm rushing to keep from being booted off any time the phone rings?  LOL  Bit of a hassle.  Leads to my not reading posts fully, with sometimes hilarious results....

Right-o.  Thank you, and my apologies for being my usual bumble-headed self.  Sigh....

I hope to make this able to load an actor for editing and another for comparison, in the background.  Then the background actor could be used as the frame of reference for moving the texvert positions.  This could also hypothetically be used to create a new .vwt comparison from the UVs, which is an interesting idea to me.

Right now all it does is allow you to select and move vertices, as well as weld and split and find back-facing polygons (which is slow, because I'm not yet using the .pyd for this).  Hold down shift to select multiple vertices.  Hold down control and drag to use a selection box.  Oh, and the current actor has its UVs displayed.  I need to add a better selection process....