Quote - " First problem is, the baby's head lines up with the freak's shin somewhere,"

Your thinking is much like having a background with Adobe Photoshop, but not Illustrator.  Photoshop is a Pixel based program, where the more you enlarge an image the more you lose the definition of that image.  Where as with a Vector based program like Illustrator you can take an image about the size of a any size and post it on a billboard, without any loss in the sharpness of the edges.

I'm quite aware that you can scale vertices infinately, but you missed my point completely. You are seeing things from a human/mind interface with no consideration of what you can or can not do or what you can or can not assume programatically.

*> *Quote - " We still have no idea how a chin morph gets transfered to the freak's chin,"

Well you've tried to go right to the edge of what the acceptable limits of Human form is.  I doubt the Freak is human, but and even if her were that's as far as you'd ever get...

I used those two figures as an the most extreme example I could think of, to illustate the more general problem that exists at the most minute levels.

You give the program 2 "meshes".  So far, the program knows (can assume) it has exactly that - 2 "meshes" and those meshes are made up of vertices.  If it looks at the group data, it can determine that they both have heads.  If it looks at the .cr2 data, it can determine the 'center' of the heads, so it could line them up to that extent.  Beyond that, it has no idea how well the contours of the shapes (that make up things like Ears, Nose, Lips, Chin, etc) relate to each other, it just knows that there's a bunch of vertices and polygons.

Your answer is that because they are vaguely similar (they both 'have' eyes, ears, nose, lips, chin, etc) that somehow there's this magical relationship that the program can work from - there's not.  

Something you (as a human) might do by hand in a modelling program - moving each vertex out to where it matches the other mesh, can not be done programatically, with the same precision, given just that information to go on.  

The fact is that the further apart in shape and position those features are from each other, the harder it's going to be to develop relationships between the coresponding vertices that make them up.

At some point (if better results are desired), then you have to give the program some sort of help/hinting...

Quote - I did agree that groups might help us along a little,

Corelating groups (or even as Cage thought of using bounding boxes) helps, but only to the extent that it restricts the set of vertices to try to match between (it refines 2 'head' groups down to 2 'lips' groups, for example), but it still doesn't fix the dis-similar positions of those vertices.

Quote -  but do'nt forget your still talking "Chin," "Nose," and "Ear."  And that you always have, and always will be.  Nobody is going to change that, nor the defaults of the Mil' Baby or Freak.  Kinda like my primitive excersize

Uhm... I'm afraid you lost me there - I'm not clear what your point is.  But taking a stab at that, we could be talking about an ashtray and a boat or even an apple and an orange meshes - again, as far as the program knows, it's just a bunch of vertices and polygons.  They may have 'generally' similar shapes, but due to the 'detail' differences between the two (assume one has a stem sloping to the left and one has a stem sloping to the right), you'd still run into problems moving morphs between them. 

Quote - *"time will tell"

*Indeed.  I just ca'nt believe I'm here, before it has already.  My hypothesis is that this is inevitable. 

And mine is that you're assuming too much :).

Quote - *"I took the liberty of lining up thier eyes"

*Close, but no cigar.  You ca'nt line up any one part, especially where any others suffer, like where the outline of one wonders in and out of the other's.  This is kinda where Groups or Sundivision fail, excpet to break the math up into digestable chunks...Make V3(because she is the higher resolution) slightly bigger, all the way around, so their outlines do'nt touch at any point(but just barely) Now replace each out"line" with paths of dots(pixels).  And if they are the same number of pixels this could get easy fast..., but otherwise just make sure the outer has more.  Then take the top dot of the outer figure, and push it to the top of the other figure.  Repeat this process for the bottom, left, right, and all the in betweens dots,  and you've converted V3 t V4...at least from orthagonal... you would then need to repeat this process, from each degree of the Y axis, then Z, and then X....more if you can get more tan one ray trajectory per degree...but then when you're done you would render anything different!

 

This is a prime example of the type of reasoning/assuming to much/misunderstanding I talk about above.  Even your example would have you (the human) making decisions as you moved the points around that would cause you to move them in a non-linear way. The process you describe here is easy to conceptualize as a human and maybe even easy to accomplish as a human in a modelling program (if not extremely tedious), but you'd be making decisions that the program has no way to know how to make and no idea that it even needed to make them.

Just so you know, while I'm not overly familiar with Python, I've been programming in C/C++ for 20+ years now (since the Commodore Amiga hit the stores) and some BASIC and assembler before that.  I've been doing 3D specific or related programming for a good 15 or more of those years.  I'm not the most math-oriented guy around and definately not the smartest guy around, but I do have a solid technical background and pretty good idea that I know what I'm talking about here :).

Cinema4D Plugins (Home of Riptide, Riptide Pro, Undertow, Morph Mill, KyamaSlide and I/Ogre plugins) Poser products Freelance Modelling, Poser Rigging, UV-mapping work for hire.