BTW, as an aside... it looks like that morph was created with questionable .vmf data... aside from several "missed" verts, there also seems to be a general asymetry - the left and right sides of the face are not morphed the same.  Was one mesh slightly translated, or something?

Quote - Ok, so I thought this was also how RD worked, but apparently I was wrong (?).  It looks like you set the morph you want corrected on the figure and then run the script and then the morph created only contains the corrections... ?

I offer basic explanations on the first page or two of this thread.

Quote - > Quote - Ok, so I thought this was also how RD worked, but apparently I was wrong (?).  It looks like you set the morph you want corrected on the figure and then run the script and then the morph created only contains the corrections... ?

I offer basic explanations on the first page or two of this thread.

Yeah, I was just confused... just to clarify, RR will work in the same way RD does - just creating a delta/corrective morph, if no morphs are selected in the list-box.  The difference is, if there are morphs selected in the list-box, RR will include that morph along with the corrections in the resulting morph.

Quote - When I was looking through your code, I was either confused about or misinterpreted what they were for, but having looked back into it, it sounds like something I might have suggested in the first place :)

Okay.  Sorry, man.  I need a vacation from these interactions.  The tone of them is really causing problems for me.  I need a mental health break.

I really get the sense that something is troubling you, and I've had that sense since you entered this thread actively.  I invited you here in good faith, because I though you'd get a kick out of the new morph-transfer process.  Apparently not.

If you want to get a point across to me, you need to state it overtly, I think.  Otherwise, I get lost, I don't get the point.

Thanks for all the great things you've been contributing.  I respect and admire that.  :thumbupboth:

If you really want to do a great thing for Poserdom, I think you should try to compile the .pyd for Poser 5/6 and Mac versions.  Poser could use it.  It's a great extension.  :thumbupboth:

I'll be interested to see the results of your efforts with Restore Relations.  Go for it!

Folks, Spanki has taken over the thread, which is fine.  He wants your attention.  Listen to what he has to say.  He's smart and he knows his stuff.  His services are available for hire, too.

I'll get back to morph transfer after a bit.  The script website is in my signature line.  Apologies to those who have sigs deactivated.

Quote - When I was looking through your code, I was either confused about or misinterpreted what they were for, but having looked back into it, it sounds like something I might have suggested in the first place :)

You left out "(or at least, it makes perfect sense now)." - which was an important part of that comment.

Quote - Okay.  Sorry, man.  I need a vacation from these interactions.  The tone of them is really causing problems for me.  I need a mental health break.

I really get the sense that something is troubling you, and I've had that sense since you entered this thread actively.  I invited you here in good faith, because I though you'd get a kick out of the new morph-transfer process.  Apparently not.

If you want to get a point across to me, you need to state it overtly, I think.  Otherwise, I get lost, I don't get the point.

Thanks for all the great things you've been contributing.  I respect and admire that.  :thumbupboth:

If you really want to do a great thing for Poserdom, I think you should try to compile the .pyd for Poser 5/6 and Mac versions.  Poser could use it.  It's a great extension.  :thumbupboth:

I'll be interested to see the results of your efforts with Restore Relations.  Go for it!

Folks, Spanki has taken over the thread, which is fine.  He wants your attention.  Listen to what he has to say.  He's smart and he knows his stuff.  His services are available for hire, too.

I'll get back to morph transfer after a bit.  The script website is in my signature line.  Apologies to those who have sigs deactivated.

 
Uhm.. wow !  I'm basically speechless, but let me take a stab at a reply anyway...

I'm guessing that you consider my comment you quoted above is a way of me trying to claim credit for something you did, or at least not giving you credit for it??  That certainly wasn't my intent.  Did you see the smiley face?  In this particular instance, it was not meant to imply "smugness", it was meant as laughing at myself for not recognizing what that code was doing.  Did you see the rest of that sentance (in parens)?  That further clarified my intent. I have stated many times in this thread that I thought what you'd done with that script was extremely cool.

And now you think I'm trying to take over the thread? (!)  And 'implying' that the reason I'm here is to promote commercial/freelance bussiness for myself?  Why do you keep reading alterior motives into my comments? Give me a break.

Nothing is troubling me (aside from continually needing to spend so much effort re-explaining myself) and the reason I'm spending effort in this thread is to try to be helpful.  If I see something that I think can be improved, I have (since 2007 in the other thread, until today, in this one) tried to come up with something that improves it, or offers some useful alternative.

For the record, I don't want ownership of this thread - it's your thread.  Feel free to use the script I posted (or not) in any way you choose.  It is not meant as a replacement for RD (that's why it has a new name, etc), but can be used in conjunction with it to further refine the mesh. It still suffers from some shrinkage and I had some ideas on addressing that, but since noone else seems interested and I can't seem to communicate with you, I'm not sure if I'll do anything else with it.

Sorry, I guess I just can't get my head around some of this...

Quote - ...I invited you here in good faith, because I though you'd get a kick out of the new morph-transfer process.  Apparently not.

...and I entered into the conversation in a good faith effort to help out if I could, too.  Exactly what makes you think that I'm not getting a kick out of the new process?  If it wasn't interesting to me, I wouldn't be contributing.

Quote - If you want to get a point across to me, you need to state it overtly, I think.  Otherwise, I get lost, I don't get the point.

Related to the comment you quoted, the only point I was trying to get across as a "head-slap" on myself.  It had nothing derogatory / negative or even sarcastic towards any one else, what-so-ever.

Quote - Folks, Spanki has taken over the thread, which is fine.  He wants your attention....

Wha'??

• I posted a script and asked for feedback.
• You provided feedback and a sample test-case (thanks again).
• I used that to try to figure out what problems you were having (more specifically, why the script was failing to do what I though it should be doing).
• While investigating, I found a major flaw in my implementation (related to the mesh.details[] array).
• I 'fixed' my script, using the above info and more testing.
• I came back here and posted the updated script.
• I reported what the issues were and how I'd overlooked an important step.
• You are somehow insulted and claim that I want everyone's attention.

...I just can't figure out how you interpreted anything I said to come to these conclusions - I'm honestly baffled/confused.

Anyway, for anyone still interested, here is the sample image I was preparing related to the earlier posts...

On the left is a 'messy' (his labeling, not mine) morph that Cage sent me, applied to V3.  The right image shows the mesh after 2 passes of the latest RR script, using the current defaults (Steps = 4, Threshold = 0.000025, Omit Welds and Split Edges both checked).

As you can see from the image, the top and top-rear of the head lost some volume and this will happen to sparse mesh areas (large polygons) when using tight tolerances.  However, areas like that are easy enough to edjust with a few magnets if you really want to get that shape back and that side-effect also brought the rear of the skull back in line with V3's neck joint.

The denser areas of the mesh (lots of tiny polygons) still held the shaping, while cleaning up the messy vertices (note the nostrils and lips).

So, in general...

• the sparser the mesh (or larger the polygons in some area), the more they will tend to move back to the original mesh shape (V3, n this case), as you use smaller and smaller Threshold values.
• the denser the mesh (tiny polygons), the smaller the threshold value needs to be, in order to clean the mesh more, but because they are tiny, they retain the 'shaping' of the morph better than large poygons.

..this is a bit of a catch-22 with a mesh like V3's (depending on how messy the mesh is)... you need to use tight tolerances to clean up the tiny poygons, but tighter tolerances (or multiple runs of the script) cause more 'shrinkage' on the large polygons.  At some point, I might get interested in working on this issue again, but in the meantime, it's not a huge problem, because: - as mentioned, if you really want to get some of that volume back, you're just a few magnets away.

• If you're just trying to clean the mesh up as a better candidate for the Correlation script, you'll still get decent correlations.
• the 'sparsest' areas of typical Poser meshes are in areas like the top/back of the head - which is typically covered by hair anyway :).

Anyway, as I mentioned in my earlier post, the Restore Relations script is not meant to replace the Restore Details script.  My advice is to try both and use the one that works best for you in your particular situation (as mentioned earlier, one of the best corrections I got on the above situation was actually to run RD once first, then RR).

I'll monitor the thread and answer any questions directed at me, but otherwise, I'm off...

Have fun!

Possibly silly question: is anything forcing you to use the same threshold in all areas of the mesh, or is it conceivable to make it depend on the mesh density in the neighborhood of the current point?

Quote - Possibly silly question: is anything forcing you to use the same threshold in all areas of the mesh, or is it conceivable to make it depend on the mesh density in the neighborhood of the current point?

Not silly at all... it's what I had started playing around with, actually.  The current script will 'lock down' verts (stop moving them) as they get closer to where the script thinks they need to be (based on the threshold value).  It does this by filling in a matchlist[] array with a 1 for verts that should no longer be moved.

The large polygons don't really need tight threshold/tolerance values as the smaller ones... My current thinking is to determine an approximate "mesh density" value for each vertex, based on the shortest distance to a neighboring vertex. The script would then use this density value to 'lock down' the sparse areas earlier (higher threshold) in the process.  I had some success with some crude hard-coded values earlier, but hadn't yet come up with the best way to compute the right values to use, for any given mesh (in other words, values I was using for V1 or Antonia didn't work well on V4 and values I used for V4 didn't work well on V3).

The early testing code is in there (along with my related comments), it's just commented out right now.

With the new default Threshold value (0.000031), it will still move those polys in the back of V3's mesh towards the head-neck connection, but it won't smooth it out very well.  At that setting, it maintains almost all of the total 'height' of the skull - the polygons on the top of the head are ever-so-slightly larger and so aren't affected (as much).  However if you increase the Threshold to 0.000032 then you start affecting those.

With that in mind...

• in order to really clean them up and affect all of them, the Threshold would need to be more like 0.000045 or something.
• Values smaller than that will only affect smaller and smaller polygons, as you decrease the Threshold value.
• It turns out that that same default value of 0.000031 is a good starting point for the V4 mesh as well.
• It's probably too small to start with when working with less-dense meshes like Antonia or V1 (it might affect the smaller polygons more than you want)... I'd start at something like 0.000045 and work down from there.

...so, given the above, my recommendation would be to just start with the default settings, run the script and see what you get... - if you see large polygons that look like they didn't get cleaned up, increase the Threashold value until you narrow in on the ones you want affected.

• if you see large polygons moving too much (deforming back towards the base shape), then decrease the Threshold value until they are no longer affected.
• if you see small (and/or tiny) polygons that still need more adjusting, decrease the threshold (once you get down past the larger-poly threshold size, they won't move anymore, so you can concentrate on the smaller ones).
• there really is no bottom-end Threshold for polys as small as the ones you see in V3's lips (for example), but a value of 0.0000131 is a good practical limit (just insert a 1 in front of the 3 that's there in the default setting).

...note that you can also run multiple passes... this can sometimes help smooth out the existing topology (ie. once the polygons look like they are shaped correctly, but may still be a bit 'bumpy').  Just keep in mind that multiple passes on relatively large polygons/threshold may cause additional distortion (erm... more towards the base mesh shape).

The general issue / rule of thumb is... large polygons (or polygon areas) are more likely to move back towards the base shape, since there's relatively fewer of them defining the shape within that area.  If an area is made up of tiny V3 lip-size polys, then you can get away with pretty tight tolerances and/or more additional passes before you start losing the shape.

With the above in mind, you'll need to keep a close watch when working with V1 / Antonia type meshes, because the smallest polygons are not as far apart in size from the largest ones (like they are in V3 or V4).

Interface / Options:

Omit Split Edges -

For the most part, you want to leave this Enabled.

Omit Zero Deltas -

There are 3 'general' usages of this script... 1. You set the desired morph(s) on the Figure and then run the script - the resulting morphs will only contain the corrections.

1. You zero all morphs on the figure and select some morph(s) from the list in the script's interface - the resulting morph will contain the selected morph(s), along with the adjustments/corrections.
2. A combination of the above... the resulting morph will contain any morph(s) selected from the list, along with corrections based on those morphs, as well as the current (morphed) state of the figure, but will not contain the morph(s) set on the figure, themselves.

...the Omit Zero Deltas option is ONLY related to morphs set on the figure - only those vertices (contained in morphs active on the base figure) will be processed.

Omit Non-Morphed Verts -

This option is ONLY related to the morphs selected in the list - only those vertices (contained in morphs selected from the list) will be processed.  NOTE: Setting this option overrides the Omit Zero Deltas option.

Mesh Density Screening -

The enables/disables the option described in the top part of this post.  When this option is disabled, the complete list of polygons/vertices (not already screened out by some other option) will be processed, regardless of the Threshold setting.

Max Repetitions -

With this script, the only time you're likely to need this setting is if you set the Steps value very high, combined with tight Threshold values on a dense mesh :) (I had it kick in once when doing 100+ Step value with a small tolerance on V3).  Generally, you can just leave it alone.

Threshold -

How close you want the vertices to resemble thier original Relationships (relative to each other, in the base mesh).  See the top of this post for additional discussion.

Steps -

Determines how far the script moves vertices towards thier target / goal locations, for any given itteration.  Higher step values can sometime produce smoother results, with less shrinkage /deformation, but the affect is not as drastic as the early versions of this script - you can generally just leave this at the default value.

Passes -

As mentioned above, you might want to run multiple passes at the same Threshold value... you can now do that without having to run the script multiple times.

Have fun!

...one more tip, related to multiple passes... As the script is processing, you'll see the status area at the bottom updating...

Running Pass: X Repetition: Y...

...as it goes through each itteration (or Repetition).  For very loose Threshold values, the Repetition count may only go up to 20 - 40 or so and for tighter Threshold values, the count may go up to 100+ (or more - lots of variables determine how high, including how badly the mesh is mangled to start with).

"Generally", you might get the best results if that count drops down to the single-digits (or something approaching the Steps value), for a given Threshold value.  My suggestion is to experiment with the Passes value - run 3 or 10 passes at the same Threshold and see if that's better or worse than one pass.  It might start counting up to 100 or more on the first pass, then drop to 74, then 52, then 30, etc... in other words, each pass should (normally) affect (fine tune) fewer and fewer vertices. 

[The above comments are mostly related to small / dense polygon areas, using a small Threshold - remember that large polygons will move more and more towards the base shape with each pass]

Hi,
I am curious to know how you create the VMF correlation files ? 
regards,
Andrew

Hi mathman,

The files are created using the TDMT "Compare" script(s). And then there's a separate "Transfer" script to transfer morphs and shapes between figures, based on those .vmf files.  This particular thread is related to a script that helps you clean-up shape transfers, either after the fact, or as an interim step in fine-tuning the shapes for the "Compare" script.

The best place to look is at the "TDMT_Morph_Transfer" link in Cage's signature (just look for his post(s) above)  - he drove the development of the process and has all the various scripts (and many others) linked there, along with links to various threads about the process.

Cheers,

Keith

This might be a good thread to dust off with the imminent arriaval of Miki 3, as Miki 2 has some nice morphs available that could be transfered.

Are you ready to again twist some vertices, Monsieur Cage?  

Wow!  Nineteen pages and intensive math!  It looks like a wonderful tool, and apparently, one that I have to read another thread to properly understand and use.

It appears that the tutorials on Cage's page are gone.  It also appears that the link to Spanki's _tdmt.py archive is broken.

Anyone have any ideas as to what happened there?

I'm very sorry to read about the communications difficulties that Cage and Spanki, but I can also understand how such things can happen.  I myself have some difficulties in fully understanding some social interactions, and have lost a few good friends over the years due to them.

They are a brilliant team, and I hope they can reconcile their different methods well enough to restore the team.

Attached Link: tdmt_pyd.zip

Thanks for the comments... the file was missing, but I just replaced it (see link above).

Cheers,

Keith

You're quite welcome, Keith.  And thank YOU for restoring the broken link.

I look forward to trying out the tools soon; you've both put an enormous amount of work into them, and I'm very grateful.

Came across this thread and the old one and was curious to try "tdmt".

One question I have regarding 64 bit Win 7 OS and the _tdmt.pyd dll.

The scripts can not load it. For testing I changed the TDMT_Match6.py script (removed the try..except to get a python traceback).

no_pyd = 0 # With this script, we only use the .pyd minimally ...

try:

from _tdmt import *

except:

   # no_pyd = 1
if (poser.Version() < 7.0) and (not poser.IsPro()):
...

The message I get then is:

Traceback (most recent call last):
  File "C:Program FilesSmith MicroPoser Pro 2010RuntimePythonposerScriptsScriptsMenuTDMTfilesTDMT_Match6.py", line 7, in ?
    from _tdmt import *
ImportError: DLL load failed with error code 193

could it be that the dll does not support 64 bit OS?

Quote - ...could it be that the dll does not support 64 bit OS?

Simple answer... yes (32bit only).

Quote - could it be that the dll does not support 64 bit OS?

I suspect you'll only be able to use it with the 32-bit version of PPro2010.

Poser Physics has the same problem: 32 bit only.

Ok,

thanks for the answer.

Need help please!

Im pretty much beginner working with Poser and im trying to transfer morphs from Victoria3 to Victoria4. Therefore I run TDMT_Match6b.py and get quite a good correlation with distance cutoff 0,005 and ray-casting. Than I use the newly created .vmf and run TDMT_match_transfer1g but it always says "Morph Creation Failed" and Im not able to transfer anything. I tried it many times with different morphs and .vmf files but nothing worked.

Anyone got an idea what the problem is??

I don't much about this software at all yet.  Let's start with the discussion above:  are you running it on a 64 bit version of Poser?

Hi Cage, if you made it over this way from the Antonia thread.

OK, so I think I got it all correct in Poser 9. 

I downloaded: TDMT_Match_Compare1.zip, and TDMT_Match_Transfer2.zip and installed them.

I also downloaded: V3_Antonia_VMF.zip, which lined them up really nice.

I then ran Match_Compare, cause the transfer script would not pickup any of the existing compares. 

Got a result.  Ran the transfer.  It said it transferred in1.438 seconds or something.  So all looks like it worked...but is Antonia's head supposed to be different then?  Morphed?  ...if so, then that aprt is not working for me. 

All looked real good until the results!  it just did not change anything on Antonia.  Unless...it made a morph and saved it somewhere?  Maybe I should look for that?

bookmark

Quote - Need help please!

Im pretty much beginner working with Poser and im trying to transfer morphs from Victoria3 to Victoria4. Therefore I run TDMT_Match6b.py and get quite a good correlation with distance cutoff 0,005 and ray-casting. Than I use the newly created .vmf and run TDMT_match_transfer1g but it always says "Morph Creation Failed" and Im not able to transfer anything. I tried it many times with different morphs and .vmf files but nothing worked.

Anyone got an idea what the problem is??

The morphs you want to transfer should have a value other than zero - just dial them up

I've been having a ball just transferring morphs between identical-in-shape-but-different-in-polycount models, such as V3 and M3 Reduced Resolution, bringing their morphs over to the full-poly version, because I was always too cheap to buy the expansion packs... :tongue2: And some clone legacy shapes for Genesis, too; it takes morphs surprisingly well.

Unfortunately, the VMF editor gives me this error when I try to use it:

Exception in Tkinter callback
Traceback (most recent call last):
File "D:Poser 9RuntimePythonliblib-tkTkinter.py", line 1410, in call
return self.func(*args)
File "D:Poser 9RuntimePythonposerScriptsCageTDMTTDMT_Match_VMF_Editor2b.py", line 118, in mergefile
gz = check_gzip(fname)
File "D:Poser 9RuntimePythonposerScriptsCageTDMTTDMT_Match_VMF_Editor2b.py", line 145, in check_gzip
f = open(dataPath,"rb")
IOError: [Errno 2] No such file or directory: u'{'

It's in my native runtime. 2b is the most recent, isn't it? I suspect it may not have been updated for Poser 9/2012? I have the latest updates from http://www.the.cage.page.phantom3d.net/TDMT_Match/TDMT.html, but I notice the editor has an earlier date than the rest...

Anyway, I've had good results combining them by hand, but I'm not sure I'm not missing out on some specialty that the VMF Editor has..?

Meanwhile, here's a new one - Jessi to Vicky 1. Chewed up her eyesockets and mouth/tongue/teeth, but this is pretty impressive as it is.  I could refine it, but for now it'll clean up by hand quite nicely.

Ooh.  I missed that bug when I did the P9 updates.  The version of Tkinter included with P9/P2012 Python has a bug which screws up the formatting of file names returned by the multiple file selection feature.  It's an easy fix, but my Python is... seriously rusty after some months away from Poser and Python.  I'll see if I can fix the problem in the next couple of days.

Unfortunately, I'm not sure I have full access right now to my upload server.  I may have to upload a corrected script to this thread, in the short term.

Ah. It's okay, no rush or anything -- throwing all the lines into a text editor works for the moment. I mostly just wanted to enthuse about TDMT, it's wonderful. I've wanted something like this for a long time. :m_bouncy:    I definitely want to make more correlation files, when I have the time. :biggrin:

well i haven't tried it because if it uses Tkinter then it won't work on my mac in poser pro 2012 unfortunately.

Love esther

Quote - well i haven't tried it because if it uses Tkinter then it won't work on my mac in poser pro 2012 unfortunately.

Love esther

Well, fair enough, I say!  :lol:  While I try to keep the existing scripts running, further development of the scripts in the TDMT set is not something I'm prepared to approach.  That means a I won't be writing new Wx GUIs for all of the scripts.  For most purposes, Morphing Clothes is probably desirable, anyway.  A different workflow is required, but I understand that it can actually transfer morphs between different heads as long as the geometry shapes involved approach one another closely.

I haev morphing clothes.  I use it on my mac using a program called crossover that makes windows think mac is installed.  so you think morphing clothes would transfer head morphs?

Love esther

so could I make miki 4 look like Vickie 4 head?  I quite like Miki 4 body.

Love esther

It was discovered in the Antonia: Opinions thread some time ago that Morphing Clothes actually can transfer head morphs, contrary to what was previously believed.  The test case, however, used the regular and low-resolution versions of Antonia.  The conclusion was that it could transfer morphs between heads, but, as with other cases involving MC as well as all cases involving TDMT, results would vary depending on how well the geometries lined up.  The shapes would have to match.  Where MC would differ from TDMT is that it only uses the base geometry to do the geometry comparisons, and that it is a separate program and can't be used within Poser.

It's an interesting matter in itself, for which I would create a separate thread, if you want to pursue it.  This one is long enough already, was actually about the Restore Detail script, and has good reasons for having been abandoned.  I'd prefer to restrict any of my posts to this thread to addressing cases where the existing TDMT scripts are broken due to Poser updates.

okay thanks.

Hey Cage

I think Mike (Phantom's site is down again). I went looking for your Python page-and it won't load

Eric

Quote - It was discovered in the Antonia: Opinions thread some time ago that Morphing Clothes actually can transfer head morphs, contrary to what was previously believed.  The test case, however, used the regular and low-resolution versions of Antonia.  The conclusion was that it could transfer morphs between heads, but, as with other cases involving MC as well as all cases involving TDMT, results would vary depending on how well the geometries lined up.  The shapes would have to match.  Where MC would differ from TDMT is that it only uses the base geometry to do the geometry comparisons, and that it is a separate program and can't be used within Poser.

It's an interesting matter in itself, for which I would create a separate thread, if you want to pursue it.  This one is long enough already, was actually about the Restore Detail script, and has good reasons for having been abandoned.  I'd prefer to restrict any of my posts to this thread to addressing cases where the existing TDMT scripts are broken due to Poser updates.

Yes, I think his site is down.  Hopefully he'll notice and address the matter.  He's been busy with real-world matters, so I hesitate to trouble him about it at the moment.  If you need certain scripts, PM me with an e-mail address that can accept attachments.

Mike's site seems to be back up, Cage...