Cage (and others):

At some point, will it be possible to get reference files for Antonia's and V1/2's bodies, so that body morphs can be transferred from V1/2 to Antonia? It would be interesting to see if a process designed specifically to transfer morphs would work better than using WW2 or CrossDresser. Also, seeing that Antonia is still a work in progress, it might be some time before WW2 and/or CrossDresser can support the figure.

I foresee a possible problem with the smoothing utility. One must choose specific body actors, not the whole body, or at least multiple body parts. Many body morphs will alter more than one actor at a time. Certainly full body morphs will do so. Being able to choose everything from the neck down would be a real plus.

Thanks for all the hard work.

LMK

Right now the main problem with trying to do full body morphs with TDMT (any version) is that the process doesn't take into account welded vertices between body parts.  These vertices can end up with transferred morph influence from both actors, with resulting bulging or distortion at body part seams.  The TDMT version that I uploaded to my site, on page 1 of this thread, has a certain level of batch processing built in, but only insofar as it will allow multiple source actors to be compared to one target actor in a single run.  I've tried reworking versions of TDMT to handle multiple actors, and the result was a confusing, messy script. 

Which is not to say that I shouldn't consider trying to add the potential.  I think Spanki was right when he suggested that the way to approach it would be to cross-reference vertices through the unimesh for the figure.  I'll start thinking about how I could do that.

By "smoothing utility", do you mean the Restore Detail script which spawned this thread, or the tdmt.pyd Smoother script which I posted later in the thread?  I'd never considered using Restore Detail in any sort of batch processing context.  It can work on props, so I would probably have spawned the FBM on the unimesh base geometry for the figure, then processed that and ported back only the morphs for the desired actors.  That approach could be used now, at least until such a time as I work out a good full-body approach for my scripts.

These are good suggestions.  Thank you.  :D  Left to myself, they wouldn't have occurred to me, but they are probably things I should be thinking about.

A sort of afterthought:  can't some combination of Wardrobe Wizard and Morphing Clothes be used to alter a figure enough to be able to port body morphs over?  I haven't tried it, but it seems like it might work.  I'm not sure I'd expect better results from the new version of TDMT than I know can be had from Morphing Clothes.

Mike1950:  I figured out what I was thinking of, in terms of a Blender tool that's similar to what you're doing with the ZBrush transpose tool.  I believe Blender has recently added what they call "retopology" or "retopo" possibilities, but IIRC it isn't like retopo in ZBrush or 3D-Coat.  The Blender process involves a user-controlled shrink-wrapping of one actor onto another.  

So users who don't have ZBrush and who trust and understand Blender (not me, usually :lol:) could try using Blender's tool to do something similar to what you've been doing.

Cage wrote:

"By "smoothing utility", do you mean the Restore Detail script which spawned this thread…"

Yes, sorry, the terminology and vocabulary used in this and related threads are swimming around in my head, and keeping me copnfused.

Cage wrote:

*"A sort of afterthought: can't some combination of Wardrobe Wizard and Morphing Clothes be used to alter a figure enough to be able to port body morphs over? I haven't tried it, but it seems like it might work. I'm not sure I'd expect better results from the new version of TDMT than I know can be had from Morphing Clothes."
 *

Yes, I normally use 2ndSkin by Dimension3D to make a second skin from the host figure containing the body morphs (but not eyes, teeth, tongue, etc.) and then reshape it to the target figure using WW2. This reshaping of the mesh to match the shape of the target figure, changes how the morph will work to be more compatible with the target figure. In effect, WW2 and CrossDresser compare and shrink-wrap the second skin mesh of one figure to fit the target.

I then use Morphing Cloths by Dimension3D to make injection morphs for the target figure, which I save. I immediately try the morph out to see if I like it, and if it doesn’t look like it contributes anything useful, I delete it.

I like to add just the morphs I want, so making a big directory of individual morphs works for me. But, one can make an injectable file that contains several, or even all of the morphs. So, Morphing Cloths simply transfers the converted morphs, or saves them as an injectable file.

M2 has some really good morphs that work well with M4 (especially the upper arm morphs which are not very good on M4), and D3 also has some good morphs. I should credit BadPenguin for this idea, as I learned this process from his posts.

The problem with using WW2 or CrossDresser with Antonia (or Brad) is that neither PhilC nor EvilInnocence have made a support file for these figures. Without a support file, one cannot use those two programs. And, we must wait until one or both of those programmers make a support file. A second problem is that WW2, and Crossdresser do not work on facial morphs.

Was Spanki suggesting that one of the uni-mesh figures could be used as a sort of universal reference to which all other figures could be compared? That is, a kind of universal comparison figure? It wouldn’t be a bad idea, because right now all of the base DAZ figures are free for versions 1, 2, and 3. One could be chosen as the reference figure, or one male, and one female.

LMK

@Ikendall - Just to save Cage some typing: the term unimesh has a different, technical meaning within Poser. If I understand correctly, it's a fully welded version of the current figure mesh that can be accessed via the Python API. That usage of the term has nothing to do with the generation 3 DAZ figures.

Quote - A second problem is that WW2, and Crossdresser do not work on facial morphs.

Hopefully that's where this new version of TDMT can help.  Through most of its development (since late 2006), the focus has been on trying to specialize on transfers between heads and faces.  This latest version seems to get us there fairly well.

I'm not sure I'll manage to add any batch handling before the point at which PhilC has added WW support for Antonia and/or Brad.  I'll need to think about how to approach it and, as noted, I tend to develop new ideas rather slowly. 

Quote - Was Spanki suggesting that one of the uni-mesh figures could be used as a sort of universal reference to which all other figures could be compared?

Sorry, there's some confusion of terminology surrounding the word "unimesh".  Long before Vicky 3 and the Daz Unimesh figures, PoserPython was referring to a figure's base geometry as a "unimesh."  The PPy command UniMeshInfo() allows the programmer to access information about how an individual actor's Geometry() fits into the figure's unimesh.  It's largely to do with converting vertex indices between the base geometry and the actor geometry.  Spanki was suggesting that I work with the base geometry and do index conversions back and forth, to deal with weld seams between actors.

Odf has suggested using a universal reference figure, and I can see merit in the idea.  But as I think about it, I wonder if it is helpful.  It would depend on how it is approached.  I may not be thinking about the idea the same way odf is.  I can imagine some problems and complications, mainly resulting from the fact that the current morph transfer script doesn't seem to transfer shapes anywhere near as effectively as morphs.  :(

Quote - @Ikendall - Just to save Cage some typing: the term unimesh has a different, technical meaning within Poser. If I understand correctly, it's a fully welded version of the current figure mesh that can be accessed via the Python API. That usage of the term has nothing to do with the generation 3 DAZ figures.

D'Oh!  Cross-post with odf.  :laugh:

What he said.  :lol:

I've updated the comparison script to include the "Mouth Open" morph which was included with Antonia-118.  Thanks to JOELGLAINE for giving permission to include this.  Now the conditions under which I created the example .vmf files can be fully recreated by a user, as I'd hoped.

http://www.the.cage.page.phantom3d.net/TDMT_Match/TDMT_Match_Compare1.zip

(Link is the same as in the initial release post, above on this page.)

 If anyone can use those morphs that went wonky for anything useful on Antonia, anyone who wishes to fix them or use them in any useful way has my permission and blessing to go forth and help make a usable figure!  Go for it! :laugh:

Just a comment on the "going wonky" part: I think any one of those morphs by itself would be fine for most applications. What I'm concerned about is that when people take these as a basis for other morphs, the same shift of the head will be present in a lot of morphs, and then when several morphs that all have that shift are combined to form a character, an expression or both, we'll get some "unexplainable" ugliness out of that.

I've tried to repair the shift, but it's too irregular. Just one of those weird deformations Poser sometimes produces. Maybe someone more talented than I can find a way. Also, some kind of filtering could maybe alleviate the effect.

Quote - If anyone can use those morphs that went wonky for anything useful on Antonia, anyone who wishes to fix them or use them in any useful way has my permission and blessing to go forth and help make a usable figure!  Go for it!

Many thanks, Joel!  :D

Quote - I've tried to repair the shift, but it's too irregular. Just one of those weird deformations Poser sometimes produces. Maybe someone more talented than I can find a way. Also, some kind of filtering could maybe alleviate the effect.

Do you remember for which version of Antonia these were created?

I'm looking at the morphs, and they seem to have an embedded rotation on X.  I've ended up with this sort of thing before when I've exported an actor on a figure I though was zeroed, but wasn't, and I didn't check the "export as morph target" box.  The movement also looks consistent across morphs.  If that's so, then the morphs can be analyzed and a base movement for each vertex can be determined, because every vertex is affected by only this unwanted motion (as opposed to the intended morph) in at least one of the morphs.  If that unwanted movement can be isolated, it can be subtracted from the whole set of morphs.

Assuming the motion actually is as consistent as it seems. 

How do you mean it is "irregular", odf?

Quote - Do you remember for which version of Antonia these were created?

Nope, but I could probably guesstimate.

Quote - The movement also looks consistent across morphs.  If that's so, then the morphs can be analyzed and a base movement for each vertex can be determined, because every vertex is affected by only this unwanted motion (as opposed to the intended morph) in at least one of the morphs.  If that unwanted movement can be isolated, it can be subtracted from the whole set of morphs.

That's an excellent idea. I like the way you think.

Quote - How do you mean it is "irregular", odf?

I mean that at first I thought it was just a simple transformation, such as a rotation plus translation. But I tried to match the morphed head to the original in Wings and found it was more complicated than that.

I didn't think of comparing the morphs to each other. I'm not sure that the deformation is always the same, but it seems that way. Definitely worth the try, if you can be bothered to do the coding.

Hmm.  I do find irregularity when I try to combine a morph from the lower face with one from the upper face to create a simple test screening morph.  The motion differs in the two morphs.  It looks the same, but if you mix parts of different morphs or dial the morphs up to 10, the difference shows.  So that first idea might work, but only with more difficulty than I had hoped.

A quicker way might be to write a script which trims out all deltas which are smaller than a given threshold value.  Presumably the intentional deltas in the morphs are more pronounced than the background noise.

I'll tinker with the two ideas.

Quote - A quicker way might be to write a script which trims out all deltas which are smaller than a given threshold value.  Presumably the intentional deltas in the morphs are more pronounced than the background noise.

That should be useful, although there might still be problems if, say, all the morphs for the mouth have an extra shift that moves the mouth in the same direction.

Maybe one could combine both ideas and use the trimmed deltas to extrapolate the drift in the remaining vertices (assuming it is some systematic deformation and not just random noise). How good are you with least-square approximation? :laugh:

Erm.  Can you hum a few bars?  Maybe I can fake my way through it.  :lol:

Did you, in working on a cleanup effort previously, find an extra shift of that type?  Is there more to this than I understand?  :unsure:

I've managed to remove the unwanted shift from the vertices which shouldn't move at all, using the attached script.  But if you already know the vertices which should be morphed have a problem, I'll stop tinkering with this.... 

The results of the script look pretty good as far as I can tell, at least.  There's still some trouble at the back of the head, where it looks like vertices vere moved in error along with the eyebrows in the brow morphs.  That's easily trimmed out, though.

I'm not sure whether I've rescued the morphs or not.  :unsure: :laugh:

Quote - Did you, in working on a cleanup effort previously, find an extra shift of that type?  Is there more to this than I understand?  :unsure:

No, I haven't spend that much time on it, to be honest. I was basically just thinking out loud.

I imagine Poser would have shifted the whole head and then the morph would have gone on top of that. If that's true, then even if you remove the shift from the vertices that are not part of the morph, it would still remain in the rest of the vertices.

But that's much less problematic than the shifting of regions that are not part of the morph. And even if there's an unwanted shift in the morphed region, that could probably be fixed by hand fairly easily.

So, I'd say it sounds pretty good, overall. I'll have a look at the cleaned up morphs and maybe I'll put them back online. I really liked Joel's "mouth open" morph, for example, and if I could snatch it and convert it to low-res, that might save me some headaches.

I understand that Vicky 3 is part of the Daz unimesh figure series?  Is that correct?  If so, then a V3 transfer can be used for all the other unimesh figures as well.  I've downloaded all of them from Daz, since they're free, but I haven't installed any of them.

So... does anybody know the names of the various unimesh base geometry .obj files?  If I can have the names of the files, I can set up the TDMT data files for all the unimesh figures without having to load a bunch of figures.

That is, assuming V3 is unimesh.  :unsure:

To accomplish this, I raised the "Cutoff Distance" threshold to 0.008 and the "Number of Influences" to 7, for the comparison.  I made a slight change to the shape transfer code in the transfer script, to use worldspace vertices for the target actor, rather than localspace.  Then I ran Restore Detail on the resulting transferred shape, using the "one pass" default settings except for the "Threshold" setting, which I raised to 0.075.  (This accomplished the cleanup without pulling the mesh back toward Antonia's shape nearly as much.)

So perhaps my qualms about shape transfer with this process were unfounded.  I just hadn't found the optimal settings for my own scripts.  :lol:

The eyelashes line up!  Zoot!  :woot:

Edit:  I've uploaded the edited transfer script to my site.  The link remains the same as before.

That looks pretty damn awesome.

Quote - That looks pretty damn awesome.

I'm impressed by it, too.  :lol:  I was beginning to convince myself that shape transfer would inevitably be messy, with this process.  Happily, I seem to have been wrong.

I'll prep the comparison files for upload tomorrow.  In the meantime, who here knows about unimesh figures?  Is Vicky 3 definitely one of them?  What are the others?  I'll go ahead and load them for testing, if I know which ones they are.

The unimesh figures are V3, S3, SF3, A3, M3, D3, F3, H3, and a few other characters based on one of these (Vittorio?).

M3 and F3 are in one group, and V3, S3, A3, D3, and SF3 are in the other. Morphs can be injected into other figures in the same group, but not into figures in the other group. I assume that H3 is also in the same group as Aiko3.

There is a utility here at Renderosity to handle exchanging morphs between the two groups:

http://www.renderosity.com/mod/bcs/index.php?ViewImage=32666

The geometry files are loaded into this directory:

"RuntimeGeometriesDAZPropsDAZPeople"

V3's geometry file is "blMilWom_v3.obj"

Hope this helps.

LMK

 Hey, Cage--those are pretty damned awesome. What do you need my crappy morphs for?:laugh:

Looking very good. I will need to try this out with Brad-M3.  

Cage, I think you and Spanki have made a major breakthrough without even knowing it...lolol.

Good on ya ;o). And thanks a million! (Give Spanki a kiss for me ;o)).

Laurie

Quote - The unimesh figures are V3, S3, SF3, A3, M3, D3, F3, H3, and a few other characters based on one of these (Vittorio?).

M3 and F3 are in one group, and V3, S3, A3, D3, and SF3 are in the other. Morphs can be injected into other figures in the same group, but not into figures in the other group. I assume that H3 is also in the same group as Aiko3.

Thanks, lkendall!  For the purposes of this script, presumably the two sets will require separate comparison data files.

All I really need for the figures in the V3 set is the name of the .obj file for each one.  The morph transfer scripts place and locate the comparison data files using a folder path which includes names of the base geometries under comparison, for one of the folders.  So once I have V3 all set, I can create the additional folder paths and copy over the V3 comparison file.  Then several figures are ready in one go.

Kind of neat of Daz, to have done the unimesh thing.  I never really thought about it much, before.

Quote - Hey, Cage--those are pretty damned awesome. What do you need my crappy morphs for?

I actually find them to be of good quality.  There are just some bugs built in.  I've been able to trim out all the unwanted motion in the vertices which shouldn't move, from your morphs.  Odf was going to look at them and consider making them available again for Antonia, depending on whether there's any unwanted motion still mixed in with the deltas which remain in the morphs.  All of them are better than anything I could ever hope to create, on my own.  (That's why I write scripts to borrow morphs from other figures.  :lol:)

But I really needed a Mouth Open morph for Antonia, as part of the process.  Since these scripts are working with closest vertices, the mouths need to be opened for a comparison, to keep upper and lower lips from interfering with one another.  Without your morph, Antonia lacks a way to open her mouth, in recent releases.

Thank you again for permission to share your morphs. 

Quote - Looking very good. I will need to try this out with Brad-M3.

If and when you do, let me know how it works out for you!  If there's an optimal work flow or the scripts can be improved in any way that you may note, let me know.  So far, I haven't learned of anyone else actually trying to run a comparison.  :unsure:

Quote - Cage, I think you and Spanki have made a major breakthrough without even knowing it...lolol.

Good on ya ;o). And thanks a million! (Give Spanki a kiss for me ;o)).

Laurie

We sort of knew at the time, but the process which used normals for the comparison had obvious complications and limitations, which have finally been overcome.  (Yay!)

I'm not sure Spanki would want a smooch from me.  :lol:  I think he's busy, lately, and hasn't been around 'Rosity for awhile, unfortunately.  :(

 If you got rid of the weird movements that crept into the morphs I did, good on ya! Give 'em to Olaf and he can make with them , what he will.

So much in my life is completely screwed up, if you managed to salvage anything, bless ya. I appreciate it, especially since no one knows how they went south in the first place.

I'm still following this stuff KEENLY. This is still one of the most interesting things in years, around here.

I don't know that this might become as big as Bagginsbill's VSS, but I find it pretty damned facinating!:laugh:

I need to test doing the shape transfer back from Antonia to V3, but if all goes well, I think I'm on board with odf's idea for a base reference figure for use in comparisons.  The obvious nominee seems to be Antonia, assuming her head shape and vertex count or vertex order won't be changing before Antonia version 2.  The Antonia shape can be shared freely and users could shape a geometry as Antonia and distribute that as a morph.  If a library of Antonia-shaping morphs is built up for different figures, the figures can be compared to Antonia or to one another by going through the Antonia shape.

That is, assuming the shape transfer still handles well in tests beyond this first one with V3 to Antonia.  If we can't easily get the base shape of a geometry, going through a common shape won't help as much when you want to create transfers from, for instance, V2 to V3.

If we were to go through Antonia as a universal reference, I wonder whether it is appropriate to use her geometry as a base for male figures.  For the head, I'd see no problem, but the body might not be as effective.  If a separate male base needs to be used, the obvious candidate would seem to be Brad, once he's released, and assuming phantom3D approves and Brad reaches a point where his base geometry won't be changing.

A website could be set up for the scripts, where comparison files and universal reference morphs for figures can be hosted (or linked), hopefully providing a nice resource for morph transfer, once an adequate library of shapings and comparisons is built up.

I assume this was basically what odf was suggesting, earlier.  (Am I correct in that, odf?)

So I need to do more testing with shape transfer.

Quote - If you got rid of the weird movements that crept into the morphs I did, good on ya! Give 'em to Olaf and he can make with them , what he will.

So much in my life is completely screwed up, if you managed to salvage anything, bless ya. I appreciate it, especially since no one knows how they went south in the first place.

I'm still following this stuff KEENLY. This is still one of the most interesting things in years, around here.

I don't know that this might become as big as Bagginsbill's VSS, but I find it pretty damned facinating!

I'm not so worried about whether it becomes popular or not.  I just want the best results and most versatility possible.  :laugh:  I'm very glad you're interested.  :woot:  If you have any ideas or testing feedback, let me know.  I'm prepared to integrate others' improvements, with credit.

I've salvaged the morphs enough that I'll readily use them now, myself.  Odf was concerned about having any remaining unwanted motion in them, which might become combined with any mixed morphs others could spawn using them.  I can see his point.  And I have no idea how to swing a least-square approximation.  :lol:  Not sure I can fix them any further.

This first image shows the straight V3 shape transfer to Antonia.  It's pretty good, but could use some cleanup.  The following images will show different Restore Detail settings and how the results differ.

The results for this transfer were much messier than for V3 to Antonia, but they clean up well with Restore Detail.  So it looks like Restore Detail may be a necessary part of the work flow, at least for shape transfers.

I'm confident that the process works and my initial success wasn't just a fluke, however.  I'm happy to embrace the "universal reference figure" idea for the script.

I thought about the universal reference figure idea for a bit. I think the reference figure would need to have a sufficiently dense mesh as not to lose too much detail in the transfer process. I'm not sure the original Antonia mesh fits that bill. I guess we could always subdivide once more, bringing her to 160k polygons or - I think - around 26k for just the head, but you'll have to decide whether that's still a workable size. I think a figure like V3 would probably not be so good because of all the poles.

I also think the reference figure should have a fairly simple shape. It should be defined enough for one to recognize all the important features so that they can be properly aligned, but not more. Antonia has some tricky bits, mostly around the nose, that might not be ideal for adjusted another figure to her shape.

So I'm thinking a higher-density version of Antonia with a simplified shape might do. And it doesn't matter whether the original Antonia changes. The reference mesh would be completely independent of the official Antonia.

Quote - I thought about the universal reference figure idea for a bit. I think the reference figure would need to have a sufficiently dense mesh as not to lose too much detail in the transfer process. I'm not sure the original Antonia mesh fits that bill. I guess we could always subdivide once more, bringing her to 160k polygons or - I think - around 26k for just the head, but you'll have to decide whether that's still a workable size. I think a figure like V3 would probably not be so good because of all the poles.

I also think the reference figure should have a fairly simple shape. It should be defined enough for one to recognize all the important features so that they can be properly aligned, but not more. Antonia has some tricky bits, mostly around the nose, that might not be ideal for adjusted another figure to her shape.

So I'm thinking a higher-density version of Antonia with a simplified shape might do. And it doesn't matter whether the original Antonia changes. The reference mesh would be completely independent of the official Antonia.

That makes some sense.  Hmm.  I'm not sure I follow the need for the mesh density, however.  My thought was that the common shape will enable comparisons between any actors which have the reference shape prepared.  I think processing through the reference shape actor as an intermediary would just add complications and the risk of distortion.  That is, for actor A to actor B, if both share the shape of actor C, you'd compare A to B directly.  Rather than run as A to C to B.  Once the common shape is in place, it's a matter of comparing actors directly.

My main concern about the process was being able to transfer shapes between A and B if neither of them had started out shaped as the other.  Happily, I don't think that's a problem.

Erm.  Am I making sense?  (I can't always tell.  :lol:)  Possibly we're talking about the same process.  I'm not sure I understand why higher resolution would be needed, however.  The simplified shape makes sense to me, and is easy enough to arrange.

http://www.the.cage.page.phantom3d.net/TDMT_Match/VMF/V3_Antonia_VMF.zip

http://www.the.cage.page.phantom3d.net/TDMT_Match/INJREM/V3_Antonia_PMD.zip

Here are the comparison files I've worked out for Vicky 3 to Antonia, and vice versa.  Apparently these files should work between Antonia 120, 121, 122 and any of the Daz unimesh figures which are V3 compatible.  I haven't worked out the names yet for the other unimesh figures, so this is only set up for V3.  You should be able to process Aiko or Stephanie or the others, but you'll need to use the "Browse for datafile folder" button on the transfer script, locate the V3 data file, and use that for the transfer.  You'll also have to browse if you use Antonia-120 (aka 121 Old UV's).

I'll try to get the folder paths set for the others, then upload files for them, as well.

I've also uploaded a .pmd to inject the Antonia head shape into V3 (or compatible unimesh figures).  I prepared this thinking Antonia might be the common reference figure, but it might still prove useful to someone.

Quote - My thought was that the common shape will enable comparisons between any actors which have the reference shape prepared.  I think processing through the reference shape actor as an intermediary would just add complications and the risk of distortion.  That is, for actor A to actor B, if both share the shape of actor C, you'd compare A to B directly.  Rather than run as A to C to B.  Once the common shape is in place, it's a matter of comparing actors directly.

I think I should just stop talking at you. You're way ahead of me in these matters. Shaping A and B toward the reference actor and then doing the comparison and transfer between them directly is a much better idea than going through C explicitly.

That also means that the density of the reference mesh would be less of an issue. You wouldn't want lo-res Antonia, but anything sufficiently smooth to recognize the intended  shape would in fact be fine.

 Unless I am way off base--the script analyzes the SHAPE of the actor, NOT the vertexes or polygons or their count?  Is this right? It seems a bit simplistic, but if it does exactly that, it's more marvelous than I thought.

I thought it pretty damned spiffy to begin with.:laugh:

Quote - I think I should just stop talking at you. You're way ahead of me in these matters. Shaping A and B toward the reference actor and then doing the comparison and transfer between them directly is a much better idea than going through C explicitly.

That also means that the density of the reference mesh would be less of an issue. You wouldn't want lo-res Antonia, but anything sufficiently smooth to recognize the intended  shape would in fact be fine.

  Oopsie.  I hope I didn't seem terse in the last post.  My apologies, if I did.  I think I may be too wound up.  :lol:  I was thinking in terms of an intermediary actor at first, but it seems like that would be unnecessary.  Your input has been extremely important throughout this whole process.  :thumbupboth:  Thank you!

Is using some re-shaped version of Antonia as reference something you agree with?  Really, there just needs to be a shape which is redistributable which anyone wanting to contribute a reference morph could use.

It now occurs to me that the .pmd for the Antonia shape wouldn't work on unimesh figures other than V3.  The deltas won't be right.  Hmm.  Oopsie.    Well, they'll inject, at any rate....

Quote - Unless I am way off base--the script analyzes the SHAPE of the actor, NOT the vertexes or polygons or their count?  Is this right? It seems a bit simplistic, but if it does exactly that, it's more marvelous than I thought.

I thought it pretty damned spiffy to begin with.

Well, it compares one actor to another, trying to locate a set of closest vertices, which then are assigned weighted values based on distance.  These contribute, according to their weights, to the transferred delta or shape.  So the vertices are involved, but the key to the comparison process is having two actors which are close in shape and position in the Poser workspace, when they're compared.  The close vertices and their weights are saved to the data file, which can then be used to transfer the shapes or morphs later, with no need at the time of transfer to be concerned about the actors' relative shapes.

The actors don't need to have any sort of compatible vertex or polygon structure or count, as long as their shapes can be compared.  The data files, however, will only work with the actors for which they were prepared.

The essential idea (weighted influence of correlated vertices) was developed by Spanki for the original form of TDMT, and apparently Morphing Clothes does something similar, minus the data file storage of the information.

Don't worry! I wasn't serious about me stopping to talk to you. Here's the smiley I should have included: :lol: The thing is, you understand and have thought through your process much better than I have, so feel free to ignore any part of my ramblings that doesn't make sense to you.

You're welcome to reshape and mangle Antonia in any way you see fit and use that as your reference figure. You might want to get rid of the toecaps, by the way, since no other figure has them. :laugh:

Quote - Don't worry! I wasn't serious about me stopping to talk to you. Here's the smiley I should have included:  The thing is, you understand and have thought through your process much better than I have, so feel free to ignore any part of my ramblings that doesn't make sense to you.

You're welcome to reshape and mangle Antonia in any way you see fit and use that as your reference figure. You might want to get rid of the toecaps, by the way, since no other figure has them.

Oh, good.  I'm always worried about offending someone.  Hence my disclaimer, in the sigline.  Danged internet.  Can lead to easy misunderstandings in the absence of emoticons.  :lol:

Hopefully I won't mangle her.  :lol:  What I had in mind was selective use of smoothing, to reduce some of the detail in the outer nostrils (which I've found hard to correlate; they may need cleanup in the V3 data files) and possibly the ears.  Antonia's shape is extremely flexible and should be highly effective as a reference base.  :woot:  Simplifying the shape is a great idea that wouldn't have occurred to me. 

Edit:  I think the toecaps and the jaws, tongue, and eyes would probably be unnecessary in this case.  On the other hand, I've been screening out the mouth bits.  Others may want to make use of them.  Hmm.

Quote - The close vertices and their weights are saved to the data file, which can then be used to transfer the shapes or morphs later, with no need at the time of transfer to be concerned about the actors' relative shapes.

The above quote of mine is poorly-stated and misleading.    The relative positions of the actors does remain important for a shape transfer, because that process uses worldspace positions of the actors.  For morph transfer, however, relative shapes and positions are irrelevant as long as both figures are currently in the Poser scene.

 Cage is already kicking ass WITHOUT toecaps already,Olaf. :laugh:

Quote - Cage is already kicking ass WITHOUT toecaps already,Olaf.

Thank you. 

I'm waiting for this stack of successes to collapse and reality to be restored.  I'm much more accustomed to having things not work.  (Like my muddled attempts at metaphor....)  :lol:

 I know the bitter taste of defeat all too well. Enjoy whatever successes you can squeeze from life!  Your house might collapse in the next earthquake. Life is NOT fair, but it IS seldom boring.

Frightening beyond belief, but seldom boring.:laugh:

Minor bug fix for the transfer script.  Sorry about that, folks. 

http://www.the.cage.page.phantom3d.net/TDMT_Match/TDMT_Match_Transfer2.zip

This is the same link as previously.  Overwrite the old version of the script, if you've installed it.

Corrected:

• Gzip was not being imported, causing error when trying to process .vmz data files.
• Vertex count mismatch between data file and actors was not being noted by script and would cause a Python error.  Now the script's status box notifies the user of the problem.

This image actually shows the Aiko head after being loaded as a morph on V3, then ported to Antonia that way.  The shape transfer directly from Aiko gets most of the way there, but the nose is very obviously wrong.  So I'm going to have to work a bit more on the V3 data file before it's fully effective, particularly for application across the unimesh line.

Some minor GUI debugging for both scripts, fixing situations which could cause Python errors.

http://www.the.cage.page.phantom3d.net/TDMT_Match/TDMT_Match_Transfer2.zip

http://www.the.cage.page.phantom3d.net/TDMT_Match/TDMT_Match_Compare1.zip

If you've previously installed the scripts, just overwrite the .py files.

The .pmd for V3 also had errors.  I neglected to put the .pmd extension on the filename in the INJ and REM poses.