It's currently running at less than 20 seconds, but I've got to work on it a bit more. Not sure I can be bothered to make it a "for sale" product as the low number of sales could be embarrasing, so it might end up being a freebie**. We'll see. Either way it has to be "good enough" by my own eyes to let others use, and therein lies the rub with releasing it as a product - although it's taken me a bunch of work, that's more because I'm not an experienced Pythin progrmmer than because the problem is complex. I expect an initial release to be followed by "I want it to work this way" or "I want it to do that" type responses - quite valid ones - so I expect a 1.1 and maybe a 1.2 release in "short order"*.

Cheers,

Cliff

*"Short order" depending on my other commitments - which are slowing down this project somewhat, so far. I keep having to do WORK for a living! :(

 

EDIT to attach image - comments welcome(ish). I'm using ".tvs" for "Texture Vertex Set" as technically that's what these load and save, so it doesn't save, load, or change seams.

 

**Don't assume that's a promise. It might embarrass me to release something that doesn't sell, but I use money to buy bread n stuff. a little humiliation can sometimes be stomached for the greater good.

I'm a punster:  I would have made the icons images of TV sets with rabbit ear antennae.  [grin]

Looking good.  Congratulations on being able to wrestle it into the shape you want it to be.

LOL I hadn't even seen that! cute - mind if I steal the idea? I don't know exactly when I'd get around to it but I'm a fairly punny guy myself, so that kind of humour appeals to me (but more coding has to come first).

 

Cheers,

 

Cliff

[chuckle]  Take it as my gift to you.  [grin]

Sounds like a plan. I've had a few days where I couldn't look at the screen for long enough to accomplish much (really REALLY bad headache multi-days long, splitting through my head, nose, and one eye) but today I'm feeling brighter and hoping I'll catch some time to work on the scripts, which were coming along nicely befiore I stopped to fiddle about with thumbs!

 

Cheers,

 

Cliff

OK, well - that was easier than expected. I set myelf a specific hurdle to overcome each time and todays has been overcome. I can compile my scripts, so they can stay messy with variables declared that I no longer use and suchlike without embarrasing me too much, and it'll be harder for people to compalin that my coding is too convoluted/simple. I can call the scripts from library thumbs, which is A Good Thing so they don't have to be in a specific runtime or anything, and I can select what file to save to using a file browser.

 

How much documentation are we going to need for people to use this? A multi-line .txt file, one-page PDF showing them what to do, or do I need a figure with extra TVSet so they can practice and see that it works before getting into the deep and and modifying UVs themselves?

 

I THINK I can explain what the scripts do and how to use them in just a few lines of text, but a PDF with images would obviously be prettier (and larger than the actual scripts LOL).

 

I have yet to creat a "final" loader - there will be two, in fact. One will bring up a browsing window, like the save script does, and the other will specify a particular filename so that you can use a modified copy of the (not-compiled) script to double-click-load a specific TVSet.

 

Hmmm - a PDF manual might be best... comments appreciated.

 

Cheers,

Cliff

a pdf with pictures?

if this works out, i'm feeling a lil inspired to do a remap of Dork.

Yes definitely a pdf.

Maybe with pictures... big pictures... and some text... a few words... :lol: 

Since many people watch only the images... obviously it's a joke, I can't resist, sorry. :biggrin: 

The serious part of the post is at the beginning.

All the "difficult" bits are done now - stuff I haven't actually done before like compiling a python script, calling a script from a library thumb, calling up a file browser (no, not difficult - but until you've DONE something well, you've never done it before!) and so on. stepping through the figure and reading and writing the UV Vertices I'd already done thanks to the Genesis testing I did (I'm still using Genesis to test on actually - but any figure should work now that I've removed the "is there a Genesis selected" checks).

 

The hardest thing now is time - I've got to arrange the time to do stuff in, and tomorrow I know I'm busy. But yes - looks like I'll be writing a PDF with images. And designing new television-inspired icons. It won't be a long manual, and the worst part will probably producing some worthwhile images. The hardest part for a merchant will be something like:

 

B - Creating a Library Item to load your TVSet.

B.1 Copy "LoadTVs.py" and rename it to suit yourself (but don't change the .py extension).

B.2 Open the .py file in a text editor and find the line which reads "fname=":Runtime:Libraries:Pose:UVSwap:CustomUV.tvs" and edit it to point to the name and location of your .TVS file.

B.3 Copy "Load TVSet.pz2" and rename it to math your newly-edited .py file from B.1-B.2

B.4 Open the .pz2 file in a text editor and edit the line which reads " runPythonScript :Runtime:Libraries:Pose:UVSwap:LoadTVs.py"

B.5 create a new .png to match the location and filename of your new .pz2 - it's your choice whether you create a render or paint something up by hand.

 

Or, well, something like that anyway. Definitely the hardest part of the whole thing.

Cheers,

 

Cliff

Sorry to hear about the migraine; I have a friend who gets those.

Congratulations on accomplishing so much!

Thanks - I get headaches sometimes, fairly bad, but this one was a real doozy. Glad it's subsided!

 

Despite having a busy day, the scripts have actually progressed nicely today, with improvements to the load script, a second load script (so we have one with a browser and one without), and some silent error handling being added in. Remaining I think I have only:

 

1. Redesign of the icons.

2. Documentation.

3. Further testing and fixing (probably do this during documenting).

4. Package up and find a way to distribute it. As two sets, I think - one half that you have to get from me (to create TVSets) and one half that can be freely distributed (that loads TVSets).

As it's been a bunch of work (and will have been even more by the time it gets released) I'd quite like to make a buck off it if I can, but I'm reluctant to put this through DAZ if only because their minimum price is too high for this - a couple of scripts and some documentation isn't something I want to charge the Earth for. Releasing here at Rendo, if I can, would let me keep the price low enough if I recall what Richard said that I don't feel like I'm ripping people off, though it's going to vanish off the "what's new" page in about 1/4 of an hour I suspect. Ah well - them's the breaks. Oh! That would mean I'd also have to do:

 

1. Promo imagery and some marketing BS wordage.

 

Tomorrow's busy - but I can aim to do some of that over the weekend if I'm lucky.

Cheers,

Cliff

This is something of a good news/bad news kind of post. Our planned day-at-the-seaside-as-part-of-a-large-group has died a death due to the car ailing - it's not able to make the trip safely, so we're stuck at home at least for today. So - between my 11 year old son and myself, we've come up with some potential new icons that tickle us both somewhat (see image if I remember to attach a screen shot). Thanks to Thalek for the idea :D

As you can see, there's a "Save", a "Load", and a customizeable/copyable "Load My" icon, each of which is backed up by the corresponding Python script.

Now, to date I've been using a Genesis figure that I'd previously used to develop the initial UV Swapping tests out as my testbed, so obviously I have two different sets of UV Data that are compatible with the same figure. I've just spent hours testing futily to edit various other figures without changing anything except the position of a few UV vertices and getting frustratd that my scripts don't seem to be working... only to discover that the Uv Mapper I am using is corrupting the UV vertex count and order, which (as with morphs) must NOT change in count or order! So. I'm in a bit of a pickle. I have no intention of writing a UV Editor that preserves the UV data in the same way that the XYZ data is preserved, but that's a basic requirement of this procedure.

Is there anyone willing to test their UV editing software to see if, when open and save a .OBJ file then re-open it, the number of texture verts is the same? I'm afraid I can't afford to buy the latest UV Mapper Pro and UV Layout and who-knows-what else to see if any of them preserve the UV verts, so I'm stuck at the documentation/testing phase until I know of a UV Editor that might work in combination with these scripts.  :(

Meanwhile, my son's building a simple T-Shirt for "The Girl" to act as a figure for documentation purposes.

Cheers,

Cliff

Is there anyone willing to test their UV editing software to see if, when open and save a .OBJ file then re-open it, the number of texture verts is the same

Do you mean the total count of vertices, the order of vertices in the count, or both?

I am unable to tell whether the order of vertices in the count has changed. My total count of vertices remains the same, but the total in the UV section of the obj. file is different from the total found when I select the UV map in Modo. (I’m assuming the vt listing in the obj. represent the Uvs because there are two values for the coordinates.)

 

I'm confused. It seems to me possible that a different UV mapping could require a change in the number of UV coordinates.

Most 3D vertices are assigned a single UV coordinate, but not those along a seam. Where there is a seam, each vertex gets two UV coordinates.

Now in an alternate mapping where the seams stay the same, and the UV's just move a bit, I can see keeping the number of UV coordinates.

But in a true alternate mapping where the seams move, if they move from one line of vertices with X points to another line with Y points, and X and Y are different, then it has to be that the number of UV coordinates is different.

And, if the number of seams changes altogether - well that's totally different.

Imagine switching from a V4 style pelt to a V3 style pelt.

 

Quote - Is there anyone willing to test their UV editing software to see if, when open and save a .OBJ file then re-open it, the number of texture verts is the sameDo you mean the total count of vertices, the order of vertices in the count, or both?

I am unable to tell whether the order of vertices in the count has changed. My total count of vertices remains the same, but the total in the UV section of the obj. file is different from the total found when I select the UV map in Modo. (I’m assuming the vt listing in the obj. represent the Uvs because there are two values for the coordinates.)

Ideally both, but just the UV count would be more promising than what I'm getting with UV Mapper V2 at the moment, where just loading and saving a .OBJ files - with no changes - alters the UV Count.

Could you possibly let me know what version of which mapping program you use?

Quote - I'm confused. It seems to me possible that a different UV mapping could require a change in the number of UV coordinates.

No need to be. I'm working within two sets of limitations - the Poser Python methods available to me, and my understanding of them. Within those limitations it seems I don't have the ability to simply change anything but the U and V values, so I can't achieve whole UV Set swappage but am limited, as I've said earlier in the thread I beleive, to retaining the seams and texture vertex counts. This is one of the limitations which made me wish for more control than I have managed, and to conclude (before being corrected) that what I HAVE managed was unsufficiently interesting to be worth bothering with.

So - I've progressed the project a little further but am still limited to morph-like limitations on the UV vertex count and group-like limitations on the existing seams, until someone cleverer than I can point the way :)

Cheers,

Cliff

Could you possibly let me know what version of which mapping program you use?

*I use Modo 601 and UV Master in Zbrush 4R2. I have UV Mapper version 0.25e, but I only use it to preserve material groups and parts when I send into Zbrush.

Mmmm, sounds a little expensive for this project. Anyone got anything a little less... pricey that might preserves UV Count and order? I know various programs have tended to reorder the XYZ vertices of .OBJ files in the past causing morphs that frankly looks like transporter accidents... I'd like to find a way to avoid UV transporter accidents :D

 

Cheers,

 

Cliff

The best way to go about this might be to see if theres a way to completely load a new obj into a figure. Since the uvmap comes along with the obj, that might 'trick" poser into using a new uv map.

If the only change to the figure is just uv maping, everything else should work properly, I'd think.

I did ask SM for this as a feature enhancement last year, when I saw the benefit of it to a figure like genesis, with extreme body morphs that would distort textures. No idea is thats on their to do list at all, or if it was forgotten.

The best way to go about this might be to see if theres a way to completely load a new obj into a figure. Since the uvmap comes along with the obj, that might 'trick" poser into using a new uv map.

*I'm sure someone will come along and tell us this can already be done. I'd be interested to learn the technicalities. 

BTW, a script that could spare a content creator the technicalities would be valuable. This method would also allow the new UV map to include completely new boundaries.

The workflow might be to create the full body morph, make it a separate figure and UV map for the new shape. Then apply the original shape as a background morph. Save the figure so that it has the original shape along with the new UV map customized for the extreme FBM. A script might somehow optimize the obj. trading.

Quote - The best way to go about this might be to see if theres a way to completely load a new obj into a figure. Since the uvmap comes along with the obj, that might 'trick" poser into using a new uv map.

Poser can actually already do that sortof - by loading a new figure and replacing the selected one rather than adding it to the scene, a method which I've suggested before but the problem as I understand it is that people may well want to create new UV layouts to address issues with models that they don't own - so a mechanism to carry just the UV data along with nothing else is required.

Overnight I had an idea that might do better than this script malarky, but won't be as esy to use - effectively UV injection from a pose file. Possibly, maybe. I need to think about it, maybe do some tests and see if I can get something more useful than having morph-like limitations on keeping to the original vertex count etc.

Cheers,

Cliff

I've lost traction on this somewhat, partly daunted by the prospect of finding Uv Mapping software that can edit UVs withouyt destroying the vertex order (I remember well having trouble years ago finding a free mesh editor that wouldn't reorder vertices, thus destroying any morph I made initially - and don't fancy trying that again but with UVs this time and paid apps to boot!).

 

So - I haven't had time to try my alternate idea yet, or document and package up this Python solution. But if anyone wants to give it a beta test/whirl, let me know and I'll see about at least some quick rough notes and packing it up in a .zip file for one or two people to try.

 

Cheers,

 

Cliff