o.k., thx fr the new script, cage.  so this one does UV functions (OS X)?

This one should work on OS X, as far as I know.  It's going to be part of the TDMT suite, integrating the UV transfer from .vwt functions I experimented with during the first wave of TDMT development.  Right now, it just presents very basic UV editing tools: welding and splitting of texvertices, as well as translation of the texverts using mouse drag, and (currently passive) detection of backfacing (sometimes concave) texpolys (usually).

The reason for creating it is that .vwt-driven UV transfer ran up against the need to split the transferred UVs along new seams.  I wasn't able to solve the problem, and Spanki apparently couldn't either, in his C4D plugin - so I hold out little hope of an algorithmic, automated solution, and this script is meant to present an interface to enable making the necessary changes by hand.

Maybe you know UV Mapper better than I do - does it have a tool to split texverts?  I couldn't find one, which is why I started this UV editor in the first place....

Anyways, if you test it, let me know what happens.  There's always a good chance of undetected bugs when I'm the only one testing a script....  Cough.

there are sevl. softwares for uv unwrapping - uv layout, unwrap 3d, blender et al.
AFAIK uvmapper pro doesn't do that, but I can't verify, as cox never bothered to
provide an OS X version.

What do you mean by file/source and file/close?  I don't follow that part.  If you can clarify, I can do some testing here to see what I can fix.

The purpose is to develop some UV-editing capability which is specific to the TDMT conversion process, ultimately.  I haven't heard of UV layout, but I'll check it out.  Blender is a bad idea for OBJ I/O handling, IMO, because their import functions are not really predictably stable or effective....

Let's see.

• While the script was running, I tried File - Close from the Poser menu, closing the scene, which did create an error.  This is not really a good idea anyway while a script is running.  PPy scripts are generally linked to the currently open scene and closing that scene would seem to me to be a surefire way to crash most scripts.  I don't know if that's what you're reporting, however.

• I'm not sure about File/Source.  That may be a Poser option peculiar to OS X?  Were you trying to display the script's source code?  I think Windows does that with ctrl-click on the script menu button....  (Just tested that, and no crash here.  I suspect I'm testing the wrong things....)

• You won't see any changes to the vertices of the box in the preview window, because the script alters texvertices and doesn't do anything with vertex positions.

• The script doesn't currently alter the UVs of the selected actor.  It could be set up to do that, perhaps.  Right now, it creates a new copy, with the altered UVs, of the selected actor.  To make a copy, press the Make Copy button.  The new actor will be automatically selected by the script when created, so you can test the results by closing the script and opening it again.

Umm.  Does any of that help?  Ultimately, this is intended to work with some specific situations for TDMT, but I'm trying to integrate some broader utility....

Hmm.  How do you commonly use File-Source and File-Close?  Are they accessed while a script is running, or intended to do so?  Have you tested them with other Poser Python scripts?  To close the script, use the Quit button, at the bottom of the GUI.  If that works for you with TDMT, it should work with this.  I'll need to know more about what these options do before I can comment further on them...?

Thanks for the help and feedback,. BTW.  And I like your new avatar (is the flower-clown retired?).

file-close is for closing the script window.  I dunno what file-source is for, but it crashes poser
in some, as this one, but not in other beta scripts.  the script window is too large for me to see
below the horiz. scroll bar, and there's no way to resize it, hence can't see said buttons. 

somebody wanted us to do earth day images, so I replaced the klown.  users here fear the klown,
as it tends to cause self-referential ideation, but they need to be toughened up a bit IMVHO. :lol:

Ah!  You can't drag the window to move it around the screen?

Easily addressed.  This is a new one, specially edited with a smaller canvas for you - 500 X 500 instead of the 900 of the earliest version or the 750 of the most recent.

I'll post one with the 750 canvas size in the next post.

To change the dimensions, edit this line, near the top:

scale = 750 # Scale the UVs and the display area

This improves the polygon updating and changes the normals handling.  It also adds a menu bar, with save and close as options, as well as options to activate "blind scrolling", which will speed up the scrollbar handling if a large mesh is loaded - although you'll end up scrolling blindly, as it were.  I haven't come up with a better solution for that yet....

Hey, Spanki - I know you're probably busy, but is there any hope of a .pyd update in the (near?) future?  If the bug with weight calculations is fixed in a release, I can port the basics of TDMT for the .pyd.  Right now that's on hold, until it's working on the plugin level....

Hey Cage,

I am in fact kinda tied up right now and can't easily change gears atm to look into this again.  Once I find the time to look at this again, I'll look at that weight thing first.

Okay.  No rush!  I'm glad to know the project isn't dead.  :D  Thank you. 

cage:

this is the longest thread in history......

sent you this on site mail but you never answered, so i'm sending it here.

http://www.bestlogic.com/collage/pics/dne-main1--2008-06-05-19-31-53-PDT.jpg

Cage, you may want to talk to Dimension3D concerning his new "Morphing Clothes" application for transfering morphs from one figure to another (!).  He didn't divulge any secrets to moi but he did recommend a read of the documentation (wink, wink).

Quote - Cage, you may want to talk to Dimension3D concerning his new "Morphing Clothes" application for transfering morphs from one figure to another (!).  He didn't divulge any secrets to moi but he did recommend a read of the documentation (wink, wink).

I just read his manual and... it sounds like he's doing something similar to what we're doing (several source verts influence dest/clothing verts weighted by thier distance), except his approach is more straight-forward than the one I came up with...

• our version only ever uses the 3 (weighted) source vertices that make up the triangle/surface that a ray from each dest/clothing vertex (along it's normal) intersects.

• because of the above, our method is more dependant on the normal (which can cause trouble for some meshes).

• his method just computes weights for 'some number' (which may be definable? or within a definable distance, perhaps) of nearest vertices on the source mesh.

...we've discussed a nearest-point method a few times (and even some weighted group of nearby points), but I'd have to go back and find/re-read that to refresh my memory on any reasoning for not going that route.

Without having his tool, I can't comment on any relative speed comparisons, but (in case you hadn't followed this entire lengthy thread...) our latest effort, using the compiled python extension is really speedy - measured in seconds now, instead of what started out taking hours :).

His approach would definately have some advantages for generic clothing items, where ours needs some normal-tinkering to work well with cuffs and two-sided belts and such (anywhere the normals don't point directly out from the figure surface underneath the clothing).  Of course it was never designed to work with clothing either :).

I can imagine that his tool works very well for both clothing and figures - if it was around when we started this project, I might not have got involved at all - then again, there are a few other packages available with similar functionality.

[ @cage - sorry bud, I'm still too tied up with other things at the moment, but I haven't forgotten about this ]

I have purchased it but have not had time either to read the manual or try it out as I'm in the process of playing fireman (putting out fires both virtual and real world).  This app is receiving excellent reviews and, knowing the quality of his work so far, it should work quite efficiently.

But it seems that you are all thinking along the same lines and some additional insights may prove worthwhile.  I have considered something similar for my plugin but only in passing at this stage, thus the interest in the methodology.

Nonetheless, best of luck with this project as well! :D

Hell, when I get some spare duckies, I'll likely purchase it myself - it sounds useful :).

Sorry not to have responded in a timely manner to the comments.  Thank you, kuroyume, for the thought!  I haven't contacted Dimension3D, or looked into his script yet, but I did some testing of ideas which deal with the nearest vertex or polygon idea.  I'll keep tinkering with those and maybe post sample scripts.  Some approaches lead to interesting things, but not one so far has rendered results at all comparable with those seen from TDMT.  Which isn't to say they can't be better, just that I haven't stumbled onto a good approach....

In the meantime, I've finally gotten around to making a .pyd port for TDMT.

I've split it into two parts, comparison and transfer.  The comparator uses the .pyd extensively, but the transfer script can be run without it. 

Here's the morph comparison script.  Multiple source actors can now be selected for one run.  The complication is the materials screening handling, which I hopefully haven't made too confusing....

Here's the morph transfer script.

The .pyd version of TDMT, here, is faster and it seems more accurate.  I haven't had as many cases of skipped verts with these, in testing.

This uses the method once discussed, of mapping two actors to a common shape, in this case a high-res sphere, created by the script.  The script gets pyd comparisons between each actor and the sphere, then gets deltas for the difference in the two resulting sphere shapes, and moves the target actor verts according to the deltas of the nearest sphere poly.

It's good for general shaping (bringing two actors into better agreement for a TDMT run, for instance), and the results still depend on how well the actors are already lined up in the workspace, as with TDMT.  An extension of this approach would be to custom-design a mesh, some sort of common head shape, to work with the transfers, I think.  All of these are ideas I've mused about throughout this thread, but only begun to test now....

Results depend on how well the meshes were lined up before the run, as usual.

It looks like the key idea for Morphing Clothes is the use of influence points to generate weighted influence over the meshes, guiding correlation.  Weights are generated by distance, with falloff applied.  The falloff can be set by the user, as can the number of influence points.  The script is fast, because both meshes are being correlated to a limited number of control points, rather than one another.

I can see how these ideas, now proven to work, could be adapted for head shaping, our key problem, in my view.  Mix a bit of Face Shop with Morphing Clothes.  The user positions boxes to define control points at key locations for either head.  Corners of eyes, tip of nose, etc.  Derive weights from the control points.  Save these box positions and weights to data files.  Use the weights, with each head relative to its own control point placement, to correlate the vertex positions/delta transfers for the two heads.

Sounds feasible to me, but then I often oversimplify.  The problem, as far as I can tell, would be working out a good handling for deriving the weights.  The influence zones would have to overlap, presumably, to cover the entire mesh.

Anyway....  Hmm.

It's slower than TDMT Classic and pyd versions, but generates decent results in most cases.  The exception is when trying to find close verts for a vertex which is on a line split, as when a mesh is
intensified using Modo.  Then the position will be off for those particular vertices, because I can't think of a way to force a good range of "close" vertices.  (This problem reminds me of the difficulty in defining seam splits for UV transfer, when a vertex falls within a polygon.  I can't find a solution.)

This will generate a new file type, .vmf/.vmz, which is based on the .vwt type used by TDMT.

This script is also slow.  The basic concept works, but I'm not sure it can be refined effectively for use within Poser Python.  The posted script was abandoned before I fully refined the method, so I haven't fully removed worldspace displacements from the transfer results.  If the source actor is translated or rotated, these transforms will be "baked" into the transferred shape.

Attached Link: Morph Cleanup Script thread

Just for anyone who hasn't seen it yet, this thread/topic has been resurrected in a new thread (which is apparently over in the main Poser forum) - see link.

The PYD has been (fixed and) updated, the main script has been updated and Cage has come up with a very nice Restore Detail script (and a few others) - overall results are better than ever - also see Cage's Homepage link for details.

Quote - Holy Resurrection, Batman!

Just for anyone who hasn't seen it yet, this thread/topic has been resurrected in a new thread (which is apparently over in the main Poser forum) - see link.

The PYD has been (fixed and) updated, the main script has been updated and Cage has come up with a very nice Restore Detail script (and a few others) - overall results are better than ever - also see Cage's Homepage link for details.

Thumbs up and LOL for the Batman 66 reference.  :lol:  :thumbupboth:

Spanki has worked his usual magic, taking a new process which kind of-sort of worked and refining it to near-perfection.  All this in spite of my initial (and regrettable ) resistance.  Well done, old chum!  (Adam West voice.  Not meant to imply that anyone here is Batman and the other is Robin!  Just extending the Batman 66 reference.  :lol:)  :thumbupboth: