The module didn't run at all under the tdmt.spanki.py so eliminated the first period and tried again and got the same result. I'm going totinker with a couple lower rez versions of the head on my end. Even tho the morphs won't transfer, the mesh analysis should take place and that might give a clue as to the problem.

Well, I've got some good news. I took the head and separated the skinhead , the densest of all, out and placed two copies in my runtime. Ran TDMT and the meshes analyzed. Then tried the full test heads and screened out all mats but skinhead and got the crash result again. Is there any way to break the mesh up and compile the data that way? That looks like it will work. :O)

*"The module didn't run at all under the tdmt.spanki.py so eliminated the first period and tried again and got the same result."
*My bad.  I gave you the wrong name!  Ack!  :-P  The file should be saved as tdmtSpanki.py, exactly as the file it replaces.  Sounds like you figured that out.

You would be able to split off parts of the mesh and combine the resulting datafiles, as long as vertex numbering remains the same.  Somehow that doesn't seem likely.  If the vertex numbering changes, you'd need to correct the tdmt correlation datafiles to reflect the vertex order of the original meshes, rather than the split ones.  This could be done, hypothetically.  I don't have a tool for it, offhand.

What meshes are you working with?  It sounds like this somehow reveals the limits of the script.  I'm puzzled and a bit worried....

Good heavens.  What figure is that?

I've been testing a case in which two geometries from an identical source are being compared, but some verts are missed in spite of the fact that they are indentical between meshes.  Looking at the code, it looks like identical meshes may represent an uncertain factor in the comparison process.  I found that by scaling either figure up or down slightly, the correlations turned out much better.  Apparently there can be problems with comparisons of verts which have identical coords.  Creating some slight difference in worldspace position, using scaling, seems to help that.

I'm trying to see if I can come up with a better handling, but this was Spanki's code area and I hesitate to muck it up.  Perhaps changing the scaling can help in your case, however.

I'll give it a whirl. Thanks for your continued support. You've got one terrific script.

Hmm.  I'm not sure the matter I was testing today will help in your case.  I was working with Posette and the old Eve figure.  They should have the same geometry, as Eve is derived from Posette.  But it looks like the Eve geom is slighly repositioned - not enough to really be noticeable or even interfere with Posette's morphs, but enough to confuse the script.  Spanki's notes indicate that comparison troubles may result with matched meshes in the point-in-triangle test.  It looks like Posette-Eve is close enough to match each vert correctly, but not close enough to pass the test as Spanki has calibrated it.  So it finds the correct verts and then ignores the fact that it found them. 

Again, the solution was to scale Eve down slightly.  I scaled down the Body by less than 1%.  Then the match came through perfectly.

Interesting....

My last effort earlier failed. I brought the scale down 2% earlier. I retry at 99.5 or so.

Select both actors in the listboxes.  Then click on the "Screen regions" button.  A menu will pop up, as shown above.  Select "Create region screening box".  You may need to click it a few times to get it to respond.  My popup menus aren't handling as well as I'd like.

Continued in the next post....

Name the box, deal with the checkbutton, read the instructions, Then click "Okay".  A box will be created in the 3d view.

Minimize the script (you can close it, if you prefer), and position this new box prop so that it encloses the areas of the two meshes which you DO want to compare.  (The script can also use exclusion boxes together with the region boxes.  With exclusion, the box should contain areas you want to exclude.  If a selection box and an exclusion box intersect, the exclusion box will prevail.)

Once the box is positioned, run the script as you would otherwise.  I would try using the box to select only the face, in your case. 

Cage,

Please excuse me if I am asking a question that was previously answered in earlier threads. I read quite a few but am still unsure what your scripting can do.

Is your script only for certain figures (V3,M3) or can it take morphs from any figure that works in poser (apollo, sixus) and transfer them to other figures that work in poser??

Thanks!

*"Is your script only for certain figures (V3,M3) or can it take morphs from any figure that works in poser (apollo, sixus) and transfer them to other figures that work in poser??"

*Hypothetically, this can be used with any two geometries.  That includes figure actors as well as props.  The script works by comparing two geometries based on their positions relative to one another in the Poser 3d view.  The comparison (assuming it runs correctly) correlates vertices between the source and target meshes, assigning three weighted source vertices for each target vertex, based on the worldspace positioning when the comparison was run.  These correlations are saved to a .vwt datafile, which is used to transfer morphs between the two meshes.

So the entire process hinges on having a decent correlation between your two meshes, and this is the difficult part of the process.  If you can successfully wheedle a datafile out of the script, you can use the script with any two actors.  Depending on how similar or dissimilar any two compared geometries may be, this comparison may be quite easy or rather difficult.  And it seems that at least one case - that of fls13, above - reveals that there may be as-yet-undetermined complications or limitations to the comparison process.

I have mainly focused on comparing Vicky1 and Vicky3.  JoePublic has used his own customized figures in comparisons.  And Apollo and the P4 dork were compared by fls13.  Hypothetically, any two figures can be used.  The trick is in crafting the datafile.  I'm still puzzling out how I might make that comparison process more workable in some situations.  One's results will vary, depending on the quality of the comparison in the datafile. 

Sorry for the long answer.  I have some trouble being concise.  :-P  Does that help answer the question, at least?

Cage,

Ha! Your reply wasn't long or difficult to understand...I can top that easily. Just be wise and don't ask me any questions! lol!
Okay, so the file to download is:
tdmt_16a_UV6k18.doc 

Is that correct?
Thanks so much for your reply.

That one should work, although it isn't the current version.  The current version has been split into modules and is posted on the scripts page linked in my sig line.  It's at the top of the page.  All of the scripts going back to... what, page 10?... of this thread should be successful when doing comparisons or morph transfers.  Those primary functions haven't been changed since Spanki succeeded in getting them to work.  And he deserves credit for the fact that the core of this works!  I've done all the fiddly bits, the confusing or incomplete functions, the confusing and cluttered GUI.  :)  I may be the spokesperson, maintainer, and the one giving the script a home, but I'm not the smart one in the project.

I don't doubt that you can top my lengthy response.  If you look at, for instance, the Poser forum thread about "how long have you been poser-ing?", it seems evident that my responses are generally less on topic and concise than those of most people.  I begin to perceive that I'm a babbler.  This totally unnecessary paragraph in the current response may be a case-in-point.  :-P

Let me know if and how the script works (or doesn't) for you.  Feedback may still be helpful in improving the process.  I have a limited range of figures on which to test, and I spend less time on refining and debugging than on exploring new ideas....

Okay, I have a question.
If I wanted to transfer the full body morphs of M3 over to James is there a "one dial do all" that will transfer them?
Like for instance if I just set the Muscular2 dial setting to 1 on M3, how/what would I choose for the select source actor?

Or is it a matter of if you really want it then you have to transfer every body part individually?

*"Or is it a matter of if you really want it then you have to transfer every body part individually?"
*Nothing is currently set up to cover groups of body parts during the comparison process.  The script will automatically check welded body parts on the selected set, to compensate for the fact that those parts probably won't have the same cuts, so a true transfer of the morphed shape from one actor to the other may involve the connected parts.  And multiple morphs can be transferred in one run.  I think I had a reason for not setting up multiple actor looping in the comparison process, but I don't remember what that was, offhand....  :-P

I'll take another look at it.  Right now the script does require that you move through the figure, actor-by-actor.  If there won't be any conflicts with other functions, perhaps I can integrate multiple parts.  It's a good suggestion....

Well I certainly don't want to give you extra work just for me.
Maybe if morphs were applied and then a spawn morph target after that (just that 1 dial that incorporates all of the morphs applied)...and then be able to transfer from that new morph target???

*"Well I certainly don't want to give you extra work just for me."

*The script is still in development, so it isn't really extra work, as far as I'm concerned.  And it's more likely to be something I can handle, at my skill level, than some of the puzzles that are currently blocking progress in other scrtipting ares....  :)

*"Maybe if morphs were applied and then a spawn morph target after that (just that 1 dial that incorporates all of the morphs applied)...and then be able to transfer from that new morph target???"

*I'm not sure I follow you, here.  Are you asking for something to transfer morphs for multiple body parts with one button press?  Or something to automate the setup of full body morph ERC?  Or something to combine morphs after they've been transferred?  I'm not quite sure what you want.  I assumed you were talking about the first of the possibilities I list.  Can you clarify?

It is being able to transfer morphs for multiple body parts with one button.

I was blabbering for the rest of the post.

Hi,

(Sorry if this has been asked before - I've read chunks of the thread but not all.)

All the talk I've seen has been about using this script for transfering e.g. a head morph from one character to another. I'm just wondering whether it could be the solution I've been looking for doe a different problem.

I'm wanting to convert some clothing from one figure to another (mostly V3 and M3 to V4) which involves regrouping. I can deal with the reshaping of the mesh, rigging and putting in morphs to fit the FBMs of the new character. The one thing I'm stuck on, though, is transferring style, effect and movement morphs from the original clothing to the regrouped version for the new fit.  For example, a number of 'open' morphs in a jacket. Because of the regrouping, I haven't found a way to do this.

Would this script work for doing this kind of morph transfer?

O.K., let's see, this is the first E-Bot I've gotten; from this thread, since page...6!

Be back after I've cought up on my reading...

 :ohmy:

*"Would this script work for doing this kind of morph transfer?"

*It should be able to do this, as long as you are able to generate a decent mesh correlation datafile for the changed mesh(es).  I would approach it by re-grouping the mesh before making any shape changes to it, then running the comparisons and using the resulting datafiles with the re-shaped mesh.  The closer the two meshes in a comparison are, the better the results will be.  Since you have a point in the process where the shapes of the two compared meshes could be identical (although the grouping is changed), I would use the script at that point.

I haven't tested this technique, however.  It should work.

*"O.K., let's see, this is the first E-Bot I've gotten; from this thread, since page...6!"
*Heh.  I wondered where you'd gone.  I was afraid you'd been offended by something, or - perhaps more likely - driven away by a dozen endless pages of back-and-forth while Spanki was still helping develop the core.  :-P

:blushing:

No, no, you and Spanki got right to work!  I'm impressed by the amount of correspondance he's added to this thread!  Much, much more than I could have!

I'd gotten side tracked by Poser 7.  It went DOA on me, for the 90 days the EULA would allow.  Then I got a refund, after EF deleted like dozens of my Support Tickets.  I got to keep my registration, but it's definately not where I want to be testing this script for you; I've found P6 much more stable, especially when it comes to morph transfer. 

I've read threw to where you and Spanki were wondering where I was!  Right now I'm finishing up some work with baginsbills chainmail.   I'll definately set aside a day soon, and then start testing as much as I can!

:thumbupboth:

fls13 - was that post intentionally blank, or is the response editor eating your posts, like it is mine?  I've had to switch from AOL to Mozilla again, to deal with Rosity.

Hey mods!  The response editor is terribly buggy!  Please don't bother to try to fix it.  Replace it!  :-P

Bump - just for the hell of it :).

[someone new (with a few hours to kill) might find it interesting reading]

I wondered where you'd gone off to, Spanki-sir.

I've actually been working on re-organizing and de-bugging this script for Poser 7.  I plan to finally separate the functions into discreet scripts which are more straightforward and manageable.

It may interest you that I've recently tested you point-in-tri code against two other approaches, and yours came out the fastest!

Hey bud,

I'm still around, just off busy on other projects. I recently ran across this thread again while researching some stuff and thought I'd pop in to say hi :).

It also got me curious about your UV-remapping code, which I'd never gotten around to looking at, and decided that I wanted something similar in one of my plugins.  I breifly looked at it and/but my eyes went fuzzy as I tried to:

• re-aquaint myself with Python
• remember the intricacies of that code-base (what/where/how all the data was stored)
• figure out the how/when/why/where of Poser-specific entanglements
   
  ...so instead (and since Cinema4D handles UVs completely differently anyway), I just thought about how you might have done it for a few minutes and whipped up some C++ code :).

I basically got to the same point you were - everything works fine, except for polygons on seam borders.  So far, I hadn't come up with an easy solution for that yet - but even if I never fixed that problem, this could be extremely useful to me  - so thanks for the inspiration.

Speaking of which, you give yourself far too little credit in the docs and messages here.  I'm happy to have helped with the parts that I contributed, but I would have been lost doing all that interface and other code you did.  If you manage to get this split into separate scripts, that would be great! I'll keep an eye out for that.

Thanks for the info on the point-in-tri code... I didn't come up with it, I just tried to make it run as fast as I could :).

Cheers.

I got the UV handling to work perfectly - until it needs to locate new seams and split and join the new island edges.  I couln't figure out any way to do that, so the UV features are both incomplete and a bit of a mess, with a lot of WIP testing code thrown in.  The UV frustration kind of caused me to lose steam with this project.

But I've been using our source code a lot.  I've been developing the smoothing functions as a separate script and I've been working on a set of shrink-wrapping tools.  Hopefully all of this can be glommed onto a release of the revised and reorganized script.

You wouldn't happen to have an algorithm for capsule mapping lying around, would you?  I'm trying to alter object normals to shrinkwrap in capsule form right now, and I'm very close, but I'm getting a ridge where I need to transition from the cylindrical treatment to the rounded cap....

You did all the hard thinking with TDMT, so you deserve credit as the smart one!  :D  I learned a lot from working with you.  Hopefully I've made some progress.  But the working core of TDMT was your contribution, and all of my successes since have been built on what I learned from our collaboration.  So I kind of feel like you deserve mucho credit.

One area where your point-in-tri code may fall behind a bit is in dealing with line collisions on split edges.  So far, it's looking like the alternate code may accomodate that better.  I need to test that more carefully.  Since the problem with TDMT and body part seams may be a split-edge problem, fixing that trouble might rectify some things....

Actually, the only problem with the point-in-triangle code itself is in getting the round-off-error values right, based on the language being used and the scale of the objects and angles involved - it doesn't have any trouble with 'split-edges' per se.

The split-edge problem is due to the fact that you have more than one 'valid' hit polygon when you hit an edge (two potentially valid polygons) or a vertex (n-potentially valid polygons).  In the case where the polygons share common (welded) vertices, it doesn't matter which one you work with (for the geometry/morphing code).

When the edge is split (each poly has it's own vertices), then you need some method of figuring out 'which' is the one you need (in fact, you're going to have to deal with all of them at some point - so they're all valid).  This is very much related to the UV seam problem... the uv polygons can have seams pretty much anywhere (effectively splitting the edges), so the polygon that got (more or less randomly) chosen back in the collision code is the one you want  only about 50% of the time (or worse, if it was a vertex hit) :).

In addition to that, the weight values generated were also based on that particular polygon (the ordering of it's vertices), so you'll need new weight values for the alternate polys as well.

Once you have all that data stashed somewhere, you still have to come up with some method of figuring out which one to use, for the given situation... In the case of geometry/morphing, it probably still doesn't matter much... since the split vertices will likely morph/move the same amount anyway.

In the case of uv remapping.... the answer is.... not-so-simple (if/when I figure it out, I'll let you know :) ).

Capsule-mapping?  No, sorry - I don't have anything like that.

When you've hit a split edge along the welded edge of an actor, the only valid polygon is the one that belongs to the current actor, not the parent or child.  Right?  I think we may be talking about slightly different things.  I wasn't referring to split edges in which the polgons on both sides belong to the same geometry, edges split to create sharp-edged normals.  More along the lines of creating a prop from a figure head and having hits to the lines around the edge ring which would weld to the neck fail to be recognized.

Am I babbling again?  I do think that I'm babbling again already.  Drat this thread.  It always makes me babble.  :D

No, not babbling :).  But I do think we covered this particular subject before...

I'd have to see the specific example to figure out exactly what the problem is, but remember your earlier test of that super low poly Poser mesh head?  A few vertices on the back of the neck area 'missed', because the vertex normals point downwards slightly and so they passed under the source head polygons.  Scaling one mesh up/down a bit and testing in world-space fixes that problem.

Quote - When you've hit a split edge along the welded edge of an actor, the only valid polygon is the one that belongs to the current actor, not the parent or child.  Right?

Uhm.. I'm not sure I agree with that.  Meshes are cut differently.  If you're trying to correlate V3 head to V4 head (for example), you're going to have to find some polys in V4's neck, so that's absolutely not true in the broad sense.  But maybe you're talking about some other, more specific operation (but, for example, even for uv remapping - you have to find the uv polys in whatever group/mesh they happen to be in).

I am thinking of a specific case, yes.  I used Modo to intensify the Vicky 1 head, then used TDMT to correlate the results.  Almost perfect, but many dropped edges where the newly added vertices split an edge which is along that cut edge ring where the neighbors stop.  In this case, the edge which should be correlated belongs to only one polygon.  As far as I can tell so far, it looks like the alternate point-tri code may handle things with split edges better, but I haven't tested methodically, as I said.

On the other hand, you have a conceptual grasp of all the parameters here, while I only have a, what?  Hueristic, perhaps?  I only have an understanding based on testing results, for the most part.  I've begun to understand cross products and dot products, but many of the underlying ideas are still mysterious....

I'm probably still not following your example completely, but all things considered (and from some recent testing in my own plugin), my best guess is that the rounding-error-values used in this test:

                    if (s < -0.00000022) or (s-1.0) > 0.00000006: continue        # point is outside T

...and the one below there...

                    if (t < -0.00000022) or ((s+t) - 1.0 > 0.00000006): continue    # point is outside T

...are not yet 'loose' enough.  In my own code (C++ code in a Cinema4D plugin) I have changed the above values to:

                    if (s < -0.0001) or (s-1.0) > 0.00001: continue        # point is outside T
                    if (t < -0.0001) or ((s+t) - 1.0 > 0.00001): continue    # point is outside T

...note that the first < test on each line is now reduced to 4 decimal places (instead of eight) and the second > test on each line is reduced to 5 decimal places (instead of eight).

Again, the final numbers may depend on the language (C++ math libraries vs Python vs Poser Python) and the particular scale of the meshes involved, so you basically want to cut the decimal places down until you can get good hits, without starting to pick up false hits (some intersection out in the next polygon somewhere).  The whole idea of that code is to make sure that the intersection point is within the triangle, so we're just trying to account for any rounding error in the math.  If the normal is shooting off in a direction that places the intersection outside the polygon in question, you want the code to reflect that fact.

...the above values were derived by me looking at some debug print out for specific - and well understood - vertex->polygon intersections that I thought should be taking place but weren't.  I simply adjusted them enough for those test-cases, then verified that it didn't seem to break other test-cases with some other meshes.

Right.  The alternate approaches don't seem to have anything immediately resembling the test you use there, yet they don't seem to suffer from dropped matches or false hits.  So I wonder whether a different approach might be applied to test whether we're in the tri which might somehow avoid the need for the sensitivity test.  On the other hand, I'm not sure I understand what they (or you) might be doing in every step of the code, so I could easily be overlooking something.

Really, it might make some sense to make your hueristically determined sensitivity value one that the user can set, to alter or refine results based on the needs of the meshes being compared.  Or am I wrong in thinking that?  I know the script is already pretty confusing for the user (which is largely a GUI design problem), and such a setting might make things more baffling rather than less....

Hmm.  See, you're still the smart one in the thread.  :D

Speaking of sensitivity: I got better results for correlations with that Modo head mesh when I exported the objects at 1000% scale, then re-imported them.  Would or would not multiplying all of the vertexPos values by 10 (or more?) give equivalent results to importing a mesh with a larger scale?  If it would, it might help if we just virtually enlarge the scale.  That really did generate better results, particularly in the area of the innermouth, teeth, and eyelashes.  Poser's teensy scale makes things hard. 

Similarly, I've found that significantly reducing the value of FLT_EPSILON, in my shrinkwrap script, really helps improve matches.

So perhaps TDMT could be improved a bit with some sensitivity tweaks?

Just wanted to say:
Good to see both of you back at work, Cage and Spanki.

Just yesterday I used this script to successfully transfer a custom head morph I made from V2LO over to standard V2.
I had to do a bit of smoothing with the morphbrush to catch a few stray vertices, but other than that it worked perfectly.

:thumbupboth:

Hey JP,

I'm happy to hear someone getting some use from the script - it was fun to work on.  Unfortunately, I don't really have the time anymore to be 'back at work' on it though :).

Cage,

Keep in mind that when I last messed with this script, I was under the impression that it was working fairly well (relative to 'hits', etc).  So without knowing the specific details (or having the time to investigate them), I'm reluctant to draw any conclusions.

But to respond to your suggestions and comments in general...

• Yes, scaling the mesh up (internally) would likely help.  But I wouldn't stop at 10x, I'd scale everything up by 1000x (which is how I typically work with Poser meshes in my 3D app).

• If my suggestions about the rounding-error-values above are not working for you (? which would be a bit surprising, so I'm guessing you didn't try yet), then if you have other point-in-tri code that works better for you, I'd say use that :).  I'm not married to that bit of code, I just tried to make it work in this implementation (and it does seem to be working well for me).

...I'm not sure I'd bother making the error variables a user-supplied value, you just need to find the ones that generally give the right answer.  Or, as mentioned, if you think the other code you have works better, use that instead - I won't be offended or anything :).

@JoePublic: Glad to hear someone is using this script, at least.  I use it a lot, myself, but I've found some of the secondary functions creating mysterious crashes in Poser 7.  So I'm trying to clean things up a bit.  I still haven't come up with a straightforward way to integrate neighbor geometries into a run, to help with body part edges....

I recently used your reduced resolution character trick in reverse, using TDMT.  Rather than creating a reduced Miki, I created an intensified Vicky 1.  If you're like me (and who isn't?), you've said to yourself, "Golly, Vicky 1 was a great figure - I'll bet she'd be even better with four times as many vertices!"  Cough.

But, anyway.  The process worked - and I didn't even get the "lumpy" morphs problem we've seen with going uphill.  I think that may have been avoided because of the specific mesh intensification process used by Modo, but I really don't know.  I was surprised.  Great success.  Although I had to correlate half of the body part edge matches by hand (a week of agony, that).

@Spanki: No, I haven't tested your suggested tweaks yet.  Sorry.  I was working on trying to figure out how to express a vertex's relationship to its neighbors in terms of weighted values, then got distracted by some refinements for the shrink-wrapping script.  I'm in no way trying to criticize the existing code in TDMT.  I suppose I'm just picking your brain.  Hurm.

The script is working very well, but I still keep wondering how to make it better.  I really did have some headaches, comparing two identically-shaped meshes.  That kind of got me thinking about how to improve things, if possible.  Anyway, I'll try an internal scaling factor for the script.

Just how silly is Cage?  He spent three or so hours trying the most ridiculously complex things to try to get weights for the neighbors of a vertex, based on their distances from the vertex.  The answer is simple.  Each neighbor's weight is its distance from the vertex divided by the sum of all neighbors' distances from the vertex.  And then he finally applied the idea, and it didn't work as well as the fill-in kludge approach he'd used when he couldn't figure out the weights.  Feh.

That's it.  No more fighting with math today.  Cage is going to go watch Jon Pertwee.

This post was, of course, completely unnecessary....  Koff.

If you need to compare two identical meshes, then you'll likely need to scale one of them up or down slightly.

Got it!  Thanks.  :D  I'll test it today.

Having found the weights of neighbor vertices based on distance from a point, I've been wondering now whether we need the weighting based on tri edges.  Couldn't we just get the weights for the tri vertices as

weight = (point distance from tri vertex)/(sum of all distances from tri vertices)

for each point?  Mind you, I haven't tested this to be sure it gives me the same weighting values.  Would it be less precise?  If it worked and we didn't need point in tri to help weed out bad matches, I would wonder if we could even do away with a point in tri test and gather the nearest vertices.

Don't worry!  Fear not!  I'm not planning on changing anything in the code.  LOL  Nor am I questioning the validity or effectiveness of anything currently in the script.  I'm just wondering.  I suppose I'm thinking that possibly neighbor weights (or nearest verts weights) could have been used to get results from the original nearest vert process.

What do you think?  I'll just point out that this wasn't the reason I was looking for neighbor weights, yesterday.  I'm working toward stretch correction and detail preservation for a shrinkwrap run, and I thought neighbor weights might help me....

Let me think about your question(s) some, but my initial response is that if you don't do the point-in-tri, then you loose uv-remapping (uv mapping is based on polygons, not vertices).

Actually, before I respond again, could you draw some diagram that illustrates how you're doing whatever it is you're doing?  I really don't have any context to go on...
 

• I don't know how you are determining the closest vertex (I can guess at this one)
• or which/how many neighboring vertices (all vertices of all polygons connected to the nearest vertex?)
• or how you're determining thier weights
• or what you plan to do with that information, however you get it :) ).
• or even what, specifically, you're talking about when you refer to your 'shrinkwrap' stuff (I assume it's a script that does roughly the same thing as the shape transfer code in TDMT?)

I'm not sure about a diagram.  Umm.  I'll try a description, first.  I've tested this for shape reconstruction after a shrinkwrap run, and we can properly position a vertex using weights gained from neighbors as I've described.

In terms of my current application, a neighbor vertex is any vertex which shares a polygon with the current vertex.  That's all the vertices in the pverts listing for any vert, excluding the vert itself.  The weights describe the "influence" of the neighbors to the vertex, based on distance.  This is used to restore some of the mesh "integrity" (basic relationships between vertices) after a shrinkwrap, which helps correct areas where we've had a great deal of stretching.  (In this case it also shrinks us.)  It basically restores the vertex relationships in the context of the new shape.  it could be used to smooth a morph using another morph as input, for instance, or using the base shape.  Possibly a good way to counter the "lumpy" morphs.

Clear as mud, right?  For the nearest vertex application, I'd still need to cast a line to find a point on the correlating mesh, presumably.  Then create a bounding box around that point and locate the set of closest vertices.  Then weight them based on distance.  The trouble would be that we'd get arbitrary correlations and introduce potential noise into the reshaping, because we don't know that "closest" verts in this case really should have any influence on the collision point.  This would work better if we had a structural constraint, such as polygon relationships - which we do have with point in tri.  I don't think the nearest vertex idea would be very effective.

My main question should be whether neighbor weights could be used within the context of the located triangle.  Would the weighting I'm using be equivalent to the triangle edge weighting currently in use, or would my process involve some sort of averaging error or something?  I guess I should test this and post the testing code, lacking a concise and descriptive diagram....

Here's the shrinkwrap script, in current form.  It relies on edited versions of the TDMT modules, which haven't been posted anywhere yet, so this won't work for anyone in Poser at this time.  I post it in case you'd like to scan my spaghetti to see what's being done.

The result can be a lot like the (revised) form of shape_transfer used by TDMT.  I wrote a new function for that, which builds the shape based on the current source shape, rather than using our hard-coded deltas.  This current script goes beyond that, applying different shrink-mapping techniques, by altering the normals before the run.  It also provides some corrective measures after the run.  Today I hope to integrate the convex hull, to further refine the results.

Anyway, as a curiosity and to clarify my ambiguities, here's the script.

I just tested newlinecast.  I'll have to look at it more closely to see what you changed, because it was much slower than the original.  Varying nothing but which version of linecast_loop was used, the new code took 4.7 minutes for my test comparison, and the old code only took 0.7 minutes.  Which is a hyoooge slowdown.  Maybe I need to tweak my settings to compensate for some of your changes?

Quote - I just tested newlinecast.  I'll have to look at it more closely to see what you changed, because it was much slower than the original.  Varying nothing but which version of linecast_loop was used, the new code took 4.7 minutes for my test comparison, and the old code only took 0.7 minutes.  Which is a hyoooge slowdown.  Maybe I need to tweak my settings to compensate for some of your changes?

Yes, if you read my notes in there, it says that you should no longer call the function more than once (we used to call it multiple times, with different angle limit values).