I think this UV stuff has revealed a limitation in the weighting process, when dealing with edge intersections.  I think this may contribute to the "lumpy" morph problem, and it complicates UV transfer (which will be better than expected, if this problem can be dealt with).

When we intersect an edge, which tri do we favor?  I assume the correct answer for deltas should take both into account.  See the attached image for my effort to illustrate the problem.  Depending on which tri we've correlated with, the deltas could be different.  Likewise with UVs on a seam.  If we log tri indices and weights for both tri-edge neighbors, we can average them for the morph and choose between them for the UVs.

I wanted to throw this at you before I start mucking about with your code or changing the datafiles....

Whaday think?

That's an interesting theory, but I don't think it's correct...

The reason is this... when an intersection happens on an edge, then it is only influenced by the two vertices that make up that edge - in your illustration, the neither the far left or far right vertices would have any influence (they'd have a zero weight value, either case).  So for morphing at least, averaging the weights of those two vertices would do no good at all (and I don't believe it's contributing to the lumpiness either - sorry).

I'll have to think more about your UV issue, but one thing to keep in mind is that UVs are for each vertex of every polygon and not just one UV per vertex (each vertex may have as many corresponding UV values as there are polygons connected to it).

Okay.  What you say makes sense.  I'm deriving the idea from the UVs, in which a direct transfer based on weighting after the texverts have been properly split reveals that the corresponding tri makes a difference.  But it wouldn't matter in the case of deltas.  Darn.  I thought I had another morph correction trick.

In Poser, at least, the texvertices are not pre-split for every vertex.  A vertex may have anywhere between 1 texvertex and one textvertex for each vertneighbor poly.  So I have to split and weld the texvertices before I can work with the seams at all.  It would be easier if what you say above were true, and that's what I had expected.

I think I can deal with the problem by sorting through edge neighbors, then.  I have an idea of where I'm going....

Correct.. I should have emphasized that vertices may have more than one corresponding txvertex.  Most of them (the ones not at a seam) will only have one.  Anywhere there's a seam/split, there's at least 2.

The whole trouble being that I have to ignore the old seams and create new ones.  I'm now getting 95% correct results in my tests, anyway.  I have ten texverts which aren't cooperating.  Eight of them have been tested to be on the edge between two tris, and associated with the source tri with the incorrect texverts.  Such a case is easy enough to fix, by finding the proper neighbor tri.  The other two are more puzzling, and that's what's taking me so long with this.  I've had to come up with some... interesting testing procedures to try to get a grip on what's happening with these.  I'm beginning to think that something along the lines of a smoothing correction to pull them into line might be best, but that may not be correct.  I really need to locate the proper tri for them so I can apply the weights.

Slow, slow, slow.  That last five percent, debugging and fiddling, is the drag of it.  So close, but not there yet, and all the easy answers are already exhausted....

Aside from that, I slightly changed the GUI refresh handling after morph loading, so the settings aren't lost.  I haven't taken the time to test this extensively, so if anyone should find that the changes create problems (say, bad correlation filepaths defined), let me know.

Thanks for the update.  I'm afraid my PC got fried last week, so I'm out of action for a while (waiting on replacement parts), but the list handling changes sound great.

If you can do a uv transfer, could you also convert a texture from say V3 to Miki so it could be saved as a .jpg file using?

*"If you can do a uv transfer, could you also convert a texture from say V3 to Miki so it could be saved as a .jpg file using?"

*Hypothetically the weighting methods used here could be adapted to something that would try to create a new texture graphic, moving the pixels around, but this actually works from the opposite direction.  Creating a new graphic file is an interesting idea, which I might put on my list of ideas, but it's something I'd deal with after finalizing all of the core morph transfer functions and the current UV transfer.  (Assuming I understand your question.  If you're asking whether this will save a new UV template, then no.  That can be created using UV Mapper or whatever.)

The current UV transfer creates a new OBJ file for the target actor which has it's UV texverts repositioned to allow the OBJ to use textures used by the source.  The current version of the process is still WIP.  I have a decent idea of what I need to do in these final phases, but actually doing it will involve some experimentation and won't happen overnight.  The update posted above will handle most of the UVs correctly on a dense mesh.  It's having some trouble with UV seams in some cases, so a less dense mesh or a mesh with more UV seams defined will have more failures.  And the export handling for the new OBJ it creates is not finalized.  Right now it will just put the new OBJ in the poser.AppLocation() folder.

Sorry to hear about your hardware meltdown, Spanki.  I live in fear of that.  I suppose must of us do.  I need to be better about backups.  I'm a few months behind on my backups and I'm relying on a backup storage drive which is getting a bit long in the tooth....  As I said, I haven't tested the GUI changes I made very extensively.  I did identify a conflict with the path handling for datafile creation when the changes are in place, and I've tried to fix that, but I'm not absolutely sure it's been corrected for all cases.  I'm moving into the final steps with the UV junk, so hopefully I can get back to the main stuff in the not-too-distant future.

ccotwist3D, I've thought some more about your question, and I'm not sure the results would be very good.  Given the methods in use, I think we'd have to go through texpolygons to calculate the new positions for the pixels in a texture graphic transfer/conversion.  So any re-sizing or change in shape of the texpolygons would result in stretching or distortion of the texture.  One would need to develop a way to smooth out the pixels after the conversion in order to get decent results out of it, and depending on the method used and the amount of distortion which it tries to fix, the results might not be very good.  I'm not sure this is an area in which I'd try to take the process, myself.  I'd have to study 2D graphic formats before I could decide whether it would be worth the struggle.

Anyone who wants to try to do something like that using the foundations presented by this script is welcome to do so, however.

This thread gets even more interesting with time. I'm looking forward to the final version.

Hey, neato.  A correspondent just asked me about sending him a copy of the Vicky 1 genital swap hip I built using Traveler's vgenkit.  But the vgenkit readme makes it non-redistributable.  The request made me think, however, and I was able to use this script and Wings 3D to create a new swap hip in under an hour, transferring Traveler's Victoria Femina morphs, which are redistributable, to the new hip.  The only trouble is that the UV transfer is incomplete, so I can't pass over the mapping yet.  Anyway, a new freebie was easily created using these tools.

Spanki, it looks like the GUI change for transferring morphs works fine, as long as you keep using the same source-target actor sets.  If you want to switch actor sets, you'll probably either want to re-start the script or manually select a new datafile using the browse option.  I'll think about how I can revise the process to allow us to retain the GUI selections and datafile path when we want it, but also have it change when it should (when actor selections change).

The UV transfer seems to need a method to locate "islands" of UVs on a map, given the polygons/tris and texverts on the seam.  This is basically an edge loop problem, as far as I can tell.  It needs to loop around the seam edges to identify the "island".  I need this to be able to determine which tri should correspond with which poly after splitting texverts at vertex intersections.  If anyone listening out there has any thoughts on this, please let me know.  I'd like to finish this UV business, which seems to show a lot of promise, and move on to perfecting the morph transfer aspects of the script. 

This does add a new version of shape transfer, which transfers the actual current morphed shape of the source to the target.  This sort of transfer seems to suffer less from the "lumpy" morphs effect seen in straight delta transfer.  A function to trim a morph, using the selection and exclusion methods used elsewhere in the script, is also added, as well as some changes and refinements to the smoothing functions and morph unique name protections.

I thought we could upload .txt files now, but the upload fails.  What gives?

Thanks Cage!!  I'll give your script a try.

Hi. I downloaded "tdmt_16a_UV6k18.py" and gave it try in Poser 6 running on a MacMini OSX4. This is the error I got: Traceback (most recent call last): File "", line 3, in ? File "MacMini HD:Applications:Poser 6:Runtime:Python:Lib:lib-tk:Tkinter.py", line 35, in ? import _tkinter # If this fails your Python may not be configured for Tk ImportError: No module named _tkinter Looks like I'm SOL, right? :( bB

*"Looks like I'm SOL, right? :("

*I don't know any solution for this.  I did a search of this forum for Mac and Tkinter and learned that the version of OSX supported by Poser 5/6 does not support Tk.  So that's a Mac issue.  You might post a general inquiry to this (Poser Python) forum to see if one of the experts may have any suggestions.

Another solution would be a version of the script which uses the Poser Python gui options introduced in Poser 6, but I can't help with that.  I only have Poser 5.  :(  There's pretty much no way to avoid the need for a gui with this script.

Bummer.  My apologies.

*Please let me know if any problems crop up.  I apologize for the lack of documentation and the complexity of the script overall.  I don't seem to be able to keep things simple, and I haven't had time for any docs.

Here's a test of the new shape transfer used as an alternative method for morph transfer.  This is the same Vicky 1 to Vicky 3 character morph which previously had trouble with the "long delta" lumpiness.  As Spanki predicted, shape transfer flattens out the target verts along the corresponding polygon planes, leading to a flattening or "faceted" effect.  But this actually helps in the case of the lumpy morphs, and the facets are easier to fix than the lumps.  This image shows the shape-transferred morph after one run of laplace smoothing set for three passes.  No more lumps, no facets.  I'm happy.

But the lips and nostrils and eyebrows are proving to be a problem to correlate.  Paging JoePublic!  You've used the script features more than I have.  Have you tried to correlate any head meshes using nostrils, inner mouth, or any of the material regions other than the skin surface?  If so, have you developed any tricks?

Cage, first of all thank you to have suggested your script as an answer to my "V3 to V4 face conversion" problem. I have downloaded your script and tried to execute it, but I have encountered some problems.

My goal: transfer the "hdAsian2" morph from V3 to V4 (just the first of many)

My procedure:

1. loaded V3 morphed  (my Keilani character) and V4 default together
2. launched the script
3. selected the V3 in "source figure"
4. selected "Head" in "source actor"
5. selected the V4 in "target figure"
6. selected "Head" in "target actor"
7. selected "hdAsian2" in morph list
8. Clicked on "Analyze meshes": the button stay depressed for around 20 seconds.

9).... the whole window resets to nothing selected.  ???  (on second thought, maybe I've understood the behaviour...)

1. repeat 3..7

2. Clicked on "Transfer morph"

3. A window appears saying that "Either that morph did not exist, or there was no valid vertex weightmap info for that area of the mesh".

I am using Poser 7 SR1 and I am SURE I am missing something really simple, but I am so a newbie!  ^_^

Thanks,
Giorgio

Hmm.  Let's see.  A few thoughts....

• Mesh comparisons are run based on positions of the two selected actors in the 3D view window.  They need to be "lined up" as well as possible.  Some complex actors (like heads) may require several different comparison runs with various of the script's "screening" methods applied, and with the resulting datafiles merged at the end of the process.  What you see in my last post is my own gradual effort to run through that process with two comparatively "easy" head actors.

• After a comparison run, the script GUI refreshes itself, to prevent any subsequent actions from using the wrong datafile.  If you compare one actor set, then try to transfer morphs between another set of actors, the datafile path needs to have changed or you'll have problems.  I'm thinking about how I can adjust that process.  In the meantime, after a comparison you need to re-select the same actor set and then select the desired morph before you can do a transfer run.  It sounds like you may have done that, however.

• 20 seconds doesn't sound like a very significant comparison time.  Between that and the error you encountered at the end, I would say either the meshes weren't lined up adequately to produce any valid data in the datafile, or there may have been some error with the actor selection and subsequent datafile handling.  At the end of a morph transfer run, the script should still display the datafile path it used at the top of the GUI.  If you browse to that path location, you can check to see if a datafile exists.  Or you can make note of that location and try to select the appropriate datafile manually with the browse option.  Or, in the "file" menu on the gui, there is an option to edit a datafile.  If you open the datafile listed on the GUI using that edit option, you can check it to see if it contains any data.

It might help if you post a screen capture of the way you have your actors lined up.  I think this is probably a simple problem, but with all of this still in development, it seems possible that you may have discovered some flaw in the process.  Any more information you can give me might help me provide advice or a solution....

Also, I like Spanki's idea of sharing datafiles.  They can be hard to set up.  I'd like to create a page on my website where completed datafile sets can be posted for use by others.  I'll put up my V1-V3 once it's done.  If anyone else has any good datafiles, I will post them for everyone to use if you e-mail them to me.  If we can build up a database of comparison files, perhaps this can offset some problems witht he script, like the fact that Mac users simply won't be able to use it to run comparisons....

---quote--
The problem is that most meshes don't line up very well without some work.  Some actors may require rotation, translation, morphing, or magnets or other deformation in order to get a decent correlation run out of the script.
--end quote--

Maybe I can try running a test in p5 on a XP machine.

Can you show examples of how to line up heads, and/or figures?

Have you tried changing the scaling for a better transfer? That's a trick that worked out well for Wardrobe Wizard clothing transfers of adult to child. Looking at the Monkey head transfer, I'm thinking something like that will improve transfers.

Also, I can clean up a morph transfer in Blacksmith. So errors on places like the teeth, tongue, inner mouth, eyelashes, etc, can easily unmorphed back to the default. Lumps can be smoothed, etc.

I would really love to give it try.  ^^

bB

*I've been trying that with the comparison pictured above.  I scaled significantly on x and y to compare the eyelashes, but this resulted in bad correlations and very unexpected morph results.  Some parts of this process are still rather experimental, and I suspect a slighly different approach may be needed for each situation.  There may be something to Spanki's statement that the process could be so cimplicated that you may be better off recreating the morph by hand under certain circumstances.  One of the reasons that a public database of completed datafiles has some appeal....

If anyone develops any comparison methods or tricks, by all means post your process!  I will, once I have one....  Right now, I'm basically doing what Spanki did when he made that monkey morph.  Zero the figures, zero their morphs, drop both to the floor, move one of them using hip or Body until the heads overlap as effectively as possible in the 3D space.  But that process may need to change depending on the meshes.  Drop to floor helps us with V1-V3, but may not with other figures who have a notable difference in height.  The above image shows how the figures are lined up.  The source is the red wireframe; the target is shaded.

Switching to an XP machine should fix the Tkinter error you were getting.  Sadly, this is not Mac compatible, although the question of whether Poser 7 fixes the Mac-Tk problem is yet to be answered....

Cage, I have discovered the severe bug that caused the error message. The bug is that I am an idiot. I simply had NOT understood that I need to overlap the two faces! I had loaded them, then very naively I had translated one of them apart "to see them better". Basically I thought that axis translation was irrilevant.

Now I have them properly aligned and the script is doing its job. I cannot yet say anything about the quality of the result because it is still analyzing the meshes, but tomorrow I'll keep you informed (it's almost midnight here and I desperately want a bed).

This project definitely needs a tutorial and an help file. Let me think... I knew someone who worked as a documentation technical writer and was skilled with RoboHelp... who was he? Mmmm.... wait a minute.... oh, yes, I remember! It's me!   Can I help?

Giorgio

giorgio_2004 - the problem isn't really a matter of intelligence on anyone's part, but probably more of inadequate communication, right?  So your statement about a help file is right on target.  I welcome any help that is offered!  The difficulty, of course, would be that anyone contributing any help to this script now needs to learn how it works, and it is complicated.  Spanki joined the process when the script was still fairly simple.  I'm afraid anyone might have a bit of a struggle now to make sense of some bits.  But in terms of writing tutorials or other documentation, I like your idea a lot.  :)  I'll try to answer any questions I can to help you produce any documentation, and I'm sure Spanki's still around here somewhere, with even better answers than mine for many questions.  Let me know what I can do.  As you may have noted, I'm not the best communicator around.  Hopefully I can make things clear enough for someone else to make them truly understandable.  :)

BastBlack - I re-read your post and realized that I misunderstood.  Yes, scaling can be part of the process, too.  I accidentally left that out of my list in the post to the other thread.  I really wish Renderosity didn't have a post editing time limit.  :(  And my response above, about the trouble I've had using scaling with comparisons, should be disregarded.  It seems I misunderstood the results of my own tests.  Sadly, I do that a lot.  Spanki has been very helpful in setting me straight when I readily jump to the wrong conclusions about something.  As I've pointed out, he's put the brainy bits into this project.  I've mainly just thrown a lot of time (and puzzlement, frustration, and cursing) at it.

Oh yes, a tutorial or picture examples would be great!

I was wondering about the V1 ape morph to V3. It looks amazing! So I was thinking, whatever made that morph transfer well, should be used for other morph conversions.

If the morph transferred because the nose, mouth and jaw were pulled out away from the face, then one could do some magnet trickery to make other head morphs transfer just as well.

So I'm thinking:

1. Make a magnet that pulls the nose, mouth, and jaw away from the face.
2. Save magnet.
3. On V1 head, apply magnet with desired morph also on. Spawn new morph.
4. On V3 head, appy magnet. Spawn new morph.
5. Do the conversion of the V1 morph to V3 head.
6. On new V3 head set the magnet generated morph to -1 on the dial (that should subtract out the magnet's effect).

Make sense?
Would a trick like this work?

The other trick could be to make one of the heads 200%. Convert. Then reduce converted head by 50%.

bB

*That sort of process could be helpful in some cases, where changes may need to be made to the contours of the two meshes in order to line them up for a comparison.  Happily, such complexity isn't really needed for a simple case like Vicky 1 to Vicky 3 or vice versa.  The Vicky 1/2 and Vicky 3 head meshes are close enough in shape that one can mainly use slight translation and scaling to get good correlations.  For the monkey transfer, the source figure was translated -0.003 on z, I believe.  I've had to translate slightly on positive y for the mouth and scale down slightly on x for the ears with the same actor-actor comparisons.  So it can be fairly simple to get good comparisons.

The above image shows a shape transfer derived from comparison files created from the alignment I posted above, with the red mesh outline.  Here, I've merged several datafiles, which were created separately, for different material zones.  You can see that the correlation was obviously pretty good, but there are some missed verts on the edges between the material zones.  So the comparison process really doesn't have to be too complicated, but one will need to use whatever tricks one can to line up any given pair of actors as well as possible.

I think I should have pointed out earlier that mesh comparisons can be sped up by raising the value entered in the "Octree regions" entry field of the GUI.  The default value is 4, which is good for most cases, perhaps.  But Spanki's tests revealed that a value of 7 is quite good for heads.  Raising the value even more may help with higher resolution meshes, but eventually there is some tradeoff between the number of verts in each octree region versus the number of region comparisons being run, so diminishing returns will apply.  At any rate, 7 is better than 4 for head comparisons.

1. Load V4 to V3.
2. Load V3.
3. Set V3's Head as my source.
4. Set V4 to V3's Head as my destination.
5. Analyze meshes.
6. Copy Shape.
7. Set Head_shape Morph to 1.

Nothing happens when I try smoothing.  Maybe I'm doing something wrong.  Can you advise me, please?

Umm.  Let's see.  

First, you'll probably want to try transfer morph first and only use transfer shape if you end up with a morph which suffers from the condition I've been calling "lumpiness".  This tends to affect only homemade morphs in which the quality may be iffy (like my own custom morph).  Generally, transferring the morph rather than the shape should be preferable.

If you're going to transfer the shape, you want to set the source morph that you want to copy before running the shape transfer.  Otherwise you'll end up copying the unmorphed shape.

To smooth, you need to select both a source and target actor (for reasons pertaining to screening box handling), but only the source listbox selection will be smoothed.  Smoothing also works on a morph target, so you'll have to select a morph to get it to run.  I know it's confusing that the destination actor for the smoothing is selected as source in this function, but the source actor is the one which displays its morphs for selection.

It looks like you may have ended up with some incorrect correlations in your datafile.  With heads, it generally seems to be best to screen out certain materials for a run.  You'd want to compare headskin to headskin, for instance, and leave the inner mouth and nostrils and lacrimal and eyelash geometries out of it, to be sure the skin doesn't decide it's found a best match inside the mouth, or elsewhere.  It kind of looks here like you've ended up with eyelashes correlated to the forehead and nostrils to the lips, and what-all.  I would suggest trying a run with just the skin surfaces for both actors being compared.

One point about the materials screening.  I've just discovered in my own efforts that when screening mats, you need to include a material which is adjacent to the correct material, or you can get dropped verts on material joins.  That is, when screening to compare only the lips to lips, you'd want to select only lips for the target, but lips and innermouth and face skin for the source.  Otherwise you'll get what I have pictured above, where there are verts missed anywhere one material joins with another, once the datafiles are merged together.

Ah.  I hope that isn't too confusing.  See what I mean when I say I'm not the best communicator in the world?

Here's a basic process.

1)  Line up the source and target actors as well as possible in the 3D view.  This may involve any or all of the transforms, as well as morphing or using deformers. 
2)  Start the script.  Select source and target actors.
3)  For complex meshes with ovelapping or internal geometry, such as heads, it may be best to use the materials screening option.
4)  One may also wish to use region box screening to restrict an area of comparison (I've done this with the ears, above).
5)  Analyze the meshes.
6)  Transfer morph and transfer shape produce somewhat different results.  Try using either to see which one may be best for your needs.  When running transfer morph, a morph needs to be selected in the listbox.  When running transfer shape, the desired morph (shape) needs to be set on the source actor.
7)  In cases where materials or regions were screened, more than one comparison will need to be run for the meshes, to catch all the verts, eventually.  This is the "lather, rinse, repeat" step.
8)  Once you have a good series of datafiles for actors which were screened, you can merge them into a single datafile using the merge option in the file menu.
9)  Smoothing (and the other "extra" functions) work on the source listbox selection - or, more specifically, on the selected morph for the source actor selection.  All of the extra functions also require that both a source and a target actor be selected. 

I'm sure I've left something out.  That covers the basics....

Two quick questions:

1. Before transfering a morph, should I set to zero its dial in the source figure?  (and by extension: would be better to set to zero ALL source morphs?)

2. I am starting the documentation project. My idea would be to create a .CHM file, that is, a compiled HTML Help File. It is the standard help format used in Windows applications, it's highly customizable and I know it very well because I write online helps with RoboHelp. But I need to know a couple of things:
          a) I assume Python will have no problems with invoking the help file, right? It just needs to call "windirHH.EXE helpfile.chm" from the GUI help option.
          b) Is the CHM format readable by Mac too?

Giorgio

Attached Link: http://phantomgirl.altervista.org/tdmt.zip

Giorgio

Wow!  The template looks great!  It would have taken me forever to organize my thoughts enough to even create a template form for this.  :-P  I'm not very good at explaining myself to others.  I'll try to do my best, though.  Thank you for helping with the help.

Regarding the questions.  

1)  The script will automatically zero all morphs where appropriate for morph/shape transfer and the "extra" functions and will generally reset them after the run.  For the actual correlation process, when comparing the geometries, you may need to zero all morphs or selectively set some or create magnet deformations - whatever is required to get the best "match" between the two actors in the 3D view.  This will really vary on a case-by-case basis, depending on the actor meshes.  Mesh comparisons really are the hard part of this process, on the user's end.  And when transferring a shape, you actually want to have the desired morph set in the source in order to transfer it.

2)  I've had no experience with .chm files and Python, but I'll see what I can find out.  I would assume that it should be able to work.  As far as Macs are concerned, however, I hesitate to even speculate.  At this point, the script itself is not compatible with Poser Python for the Mac, because of problems with Tkinter.  So in the short term, at least, this doesn't seem like it needs to be an issue.  Again, I'll see what I can find out abouot this. 

Giorgio, the help file tree looks very good.  Thank you!  I think maybe a couple of topics should be listed outside of the context of file menu or button handling.  Selection and exclusion bounding boxes are used a great deal, for instance, and it might help if something like that has its own entry.  Perhaps that's the sort of thing that would fall under "What is TDMT"?  See, I'm terrible at organizing anything like that.  :-P

Cage,
thanks for the suggestion: it is very good. Actually the concept behind the online help is that you have to present information in two ways:  the referencial way, that is the list of avalable commands, and the procedural way, that is the "How to" section, where you say "if you want to do this operation, follow this procedure". So I'll add more tree branches to this section, for example "How to > Exclude regions" or "How to > Use bounding boxes". The REAL problem is that I am by no means an expert of the tool, so it's hard to write help for something that I need help too!  ^_^  But I'll do my best!

Giorgio

*"The REAL problem is that I am by no means an expert of the tool, so it's hard to write help for something that I need help too!  ^_^  But I'll do my best!"

*I'm just throwing ideas around.  That's kind of how this thread has worked.  I appreciate any contribution you might make, and I'll try to explain anything that is unclear.  Please don't let me offend you with any of my thoughts or suggestions.  I'm afraid I seem to be able to offend people rather easily.  :(

This update finally adds support for multiple morph transfers in a single run, as well as automated mesh comparison checks of welded source neighbors.  So a comparison run can check the neck as well as the head, for instance, if the two are welded and if the neck welds lie within the bounding box of the target actor.  This option is on by default, but can be turned off in the options menu.  It is currently disabled if there is an exclusion box in use for the comparison.  I may change that.

This also adds support for the TDMT.chm helpfile on which giorgio is working, if that file is located at :Runtime:Python:TDMT:TDMT.chm.

This also adds some corrections for prop handling to the smoothing and transfer_shape2 functions and makes a few changes to smoothing which seem to do away with the worst of the RAM leaks previously associated with the smoothing functions.

I'm going to do a bit more refinement and then probably have another try at finishing the UV transfer functions.

Whoof!  The script now exceeds the file size limits.  I'm going to have to start posting it to my website....

http://www.kuroyumes-developmentzone.com/~Cage/TDMT/tdmt_16a_UV6k27.py

Hmm.  Now that I'm posting these on my site, I think it's time to start breaking the script up into modules....

http://www.kuroyumes-developmentzone.com/~Cage/TDMT/TDMT_module_v1.zip

This update fixes shape_transfer, which had been broken by the addition of the new multiple morph transfer capabilities.  Oopsie.  It also splits the script into modules, so now placement of the files is somewhat important.  The script package folder can be placed anywhere, as far as I can tell, but the package folder structure has to remain intact, so the main script can locate the modules.  So when you place these files, it's best to use the folder structure used in the zip file.  Or, at least, to be sure to keep everything inside the TDMT_script folder together, as they are in the zip.  The actual folder, "TDMT_script" can be placed anywhere or re-named.

I also include a run_TDMT.py, which can be placed anywhere and used to run the actual script - assuming you've placed the script package as shown in the zip file.

I've tested all of the functions and it looks like everything is still working after the split into modules, but if anyone encounters an error, please let me know.  There may still be namespace issues which I haven't found yet.

This also removes some of the old testing functions which Spanki and I were using during the development of the mesh comparison process.  They were no longer needed and the module split broke the process.

Attached Link: http://phantomgirl.altervista.org/tdmt.zip

My schedule (in random order) would be:

1. descriptions for all the commands
2. main procedures (transfer morphs and shapes)
3. exclusions and bounding boxes (if I manage to understand something about them)
4. capturing some images (or borrowing some of them from this thread)
5. being a bit more specific with copyrights and disclaimer, because thieves are everywhere even for free stuff (maybe a Creative Commons license or something like that?)
6. proofreading and boosting up the detail level.

Obviously suggestions and ideas are always welcomed (I am just an humble worker for the Great Project!  ^_^  )

Giorgio

P.S. flush your browser cache if downloading the zip you find the old version....

The changes to the help file look good, giorgio_2004.  Thank you.  Regarding the instructions for how to update the script.  I'm going to put up a page at my site, in the next week or so, where different versions of the script can have a home.  The direct link to the current version, posted above and included in the .chm, won't always point to the latest version.  I'll try to get a page together so a prope rlink can be included in the documentation.

If you have any questions about tools, interface, or processes for using the script, let me know.  Much is covered in this thread, but a lot of that is less instructive than speculativeeveryone thinking on their feet, as it were.  There really isn't any solid documentation, as yet, for a lot of this....  So let me know if you have questions. 

http://phantomgirl.altervista.org/tdmt.zip

Link doesn't work

http://www.kuroyumes-developmentzone.com/~Cage/TDMT/tdmt_help.zip

Here's the last version giorgio_2004 posted.

Quote -
http://phantomgirl.altervista.org/tdmt.zip
Link doesn't work

How strange. I have tried it now and it works...
Anyway that version is outdated (just a template). I am writing the new one, but at the same time I am moving (leaving my old house for a bigger one) so I have zero spare time. But I have not forgotten my "duties".   ^_^  Just leave me some days and the help will be ready!

Giorgio

I grabbed it from another link. Thanks for your efforts. :O)

*"Just leave me some days and the help will be ready!"
*No rush.  Sorry: perhaps I should have contacted you before posting the older version.... 

The module worked fine for me going between 2 figures, P4 dork and Apollo maximus. Two more different figures you could not find. I'm having problems moving morphs between two props heads, one full rez and the other with a ton of unneeded geometry removed. TDMT asks me to find the geometry file on the lower rez prop. I dutifully find it but Poser/TDMT has been crashing. Any thoughts?

*"I dutifully find it but Poser/TDMT has been crashing. Any thoughts?"
*When the script asks you to browse for the geometry, it's really looking for a point of reference for folder naming, so it can create the datafile when running a comparison or refer to that datafile when transferring morphs.  If your decimated head prop is simply imported into Poser and has not been saved to the props library and loaded (or used as part of a figure), then Poser Python finds no geometry file for the geometry.  I would try either declining to browse for the geometry or saving the object as a library prop, re-loading it into the scene, and working with that.

Can you tell me anything more about the circumstances under which the script and Poser crash?  Do you get error messages?  At what point in the process does this happen?  What version of Poser are you running?  Any details you can offer may help solve your trouble, and maybe show me how I can change things to keep this from happening at all.

This is a problem I haven't seen before, myself....

Well I thought that might be the problem since I posted this, so I parked the .obj and .mtl files in the right props folder and hacked the .pp2 so it would reference properly. Loads fine, no problem. But I haven't gotten thru the analyze meshes faze. Poser and the TDMT interface whites out fairly quick and I eventually have to ctrl+alt+del out of them. Now the original prop head is huge 7+ mbs. That's why I want to cull some of the excessive geometry. If you have any thoughts, I'd appreciate it.

I've gotten the utility to work fine on a couple different figure combinations. Worst case scenario, I do the whole process morph-by-morph manually. But this is the head I use on all my characters. I think it's the best on the market, just rez-heavy in places where I just don't need it.

Okay.  When the script seems to have frozen during a comparison run, if may be doing what it's supposed to do.  You can usually speed up the comparison by raising the "octree" entry box setting.  It defaults to 4, but a value of 7 has been tested to work well for intensive meshes like heads.  Raising this value increases the number of separate regions used in the comparison, placing fewer vertices from either mesh in each region.  Sooner or later a higher octree value will stop returning faster results because the number of regions can become too high and any efficiency gain is lost.  Try using 7, then perhaps raising it a bit, if that doesn't help.

Next, you may need to screen out certain materials when you run the comparison.  Commonly inner mouth, tongue, and teeth materials are screened out.  Including these in a run with the rest of the head can actually create problems with "false hits", as well as a slowdown.  A vertex in the nose may decide that it's found the best match in the tongue, for instance.  Screened materials can be compared in a separate run and the datafiles from repeated comparisons can be combined at the end of the process.  It can also speed things up to omit ears from a comparison.  This would need to be done using the exclusion boxes.  If you need better instructions for any of this, let me know.

These two geometries should have the same shape, however, so I would assume that the octree setting changes may help the most. 

Perhaps I should turn the progress print statements back on while comparisons are being run, so one can tell that the script hasn't frozen....

I don't seem to be receiving response e-bots.  My apologies if I am not promt to respond to any inquiries, as a result....

I've still had the same problems excluding mouth related materials and ramping up the octree to 8 and then13. Looks like I'll need a step thru on the exclusion boxes and compiling the files. Here's hoping I can get this to work. I love the head at 7 mb, I'll love it more at 2 mb. :O)

Sorry for the delay.  The e-bots seem to be rebelling lately.  Perhaps I need to clear my AOL cache, as instructed on the Rosity front page.  Hmm.

The two meshes you're comparing have the same shape, correct?  You altered the vertex and polygon structure without changing the countours, as it were.  Hmm.  I've not yet encountered a situation where two identically-shaped meshes caused trouble.  And the error you get is simply that the script seems to stop responding?  How long have you let it run, in any given case, before bailing out?  And it may not make much difference, but what version of Poser are you using for this? 

Are you lining up the heads in the 3D view before running the script?  You shouldn't have to do that, I suppose, if the shapes are the same.  A common problem people have had is failing to align the meshes as well as popssible before comparing them.

Step-by-step, what is the process you are applying?  I know that's a broad question, but I'm kind of groping for an explanation, now.  I don't know enough about what you're encountering to know what else to suggest.

The two meshes you're comparing have the same shape, correct?  Yes, the only difference is the target has had all eyelashes vertices deleted. Otherwise, they are exactly the same.

And the error you get is simply that the script seems to stop responding?  Yes, no more error messages after fixing the referencing in the  .pp2 file.

How long have you let it run, in any given case, before bailing out?  A good hour I'd estimate, just gotten up and did something else.

And it may not make much difference, but what version of Poser are you using for this? Version 6.0.0.38

Are you lining up the heads in the 3D view before running the script?  Yes, they are precisely in the same position.

Step-by-step, what is the process you are applying?  **I popped the run_tdmt.py along this path C:Program FilesCurious LabsPoser 6RuntimePythonposerScriptsGeomMods and access it thru the python scripts window. The dialog box pops up, I select the source/target prop and then actor in the next fields over. Then I screen the mats, including only lips/skinhead/lacrimals, raise the octree to 12, then hit analyze meshes. I don't think I'm doing anything wrong here because I have gotten the script to work with other meshes.
**Perhaps I should turn the progress print statements back on while comparisons are being run, so one can tell that the script hasn't frozen....
That would be great.

Browse to your TDMT scripts folder at 

...RuntimePythonTDMTTDMT_scriptTDMT

Re-name tdmt.Spanki.py to something else.  Delete the .pyc files in the folder.  Then place this script in the folder under the name tdmt.Spanki.py.

This version will print the progress for region comparisons.  There will be no printed statements for progress for creating the geometry comparison lists, so there may be a delay of a couple of minutes (depending on mesh sizes) before the region comparisons start and start printing anything.  This should at least give us some idea where in the process your problems are coming in.