I think they're all in hiding. I know I was!

Cheers,

Cliff

Quote - but you could write a new tutorial for people with poser and new to DS, telling us exactly what the best way to do it would be. I notice a bit of confusion and complaints about the DAZ instructions here in the forums. Love esther

I think I'd rather produce an "addendum" type document to accompany the existing .PDf, if I can be brief enough. I'm a touch busy right now, but give me a yell if I don't come up with a comment by NEXT weekend maybe?

Quote - I would leave it - but maybe it is possible to add a sentence to the product description? You never know when they start selling it, and then your way is cheaper. ;)

Argh. I hadn't thought about when they put the price up - though "with subdivision" is going to produce MUCH better results than "without subdivision". Though that looked like it was getting some promising attention from snarly. Definitely need an update to the product page then, at minimum. Though of course DAZ could always stop providing the .CR2 exporter - that'd kill the "economy route" stone dead :(

Thanks for the food for thought. I tend to make snap decisions, but I'm trying really hard this time not to do that :) (the decision to write the tut in the first place was a snap decision, for example!).

Cheers,

Cliff

Look lively! DAZ have released an importer for DSON files that make for a much better experience. It's currently free but I've no idea when (or if) that will change.

http://www.daz3d.com/shop/dson-importer-for-poser

http://www.daz3d.com/forums/viewthread/9405/

I'd also appreciate feedback over whether it would be politic to remove my tutorial from the marketplace to avoid confusion, or whether there are people still using DS 4 with Poser that might benefit from it remaining available. I'd rather avoid confusion but at the same time I don't want legitimate users unable to get it if they want it.

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

Snarlygribbly - excellent! this looks like a really great step forward :D

Cheers,

Cliff

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

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

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

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

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

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

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

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

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

Quote - Wow!  Definitely got my answer.  Thanks all 

Glad I could help.

Personally, I don't think Genesis is best judged against V4 (or against V3 or David or The Girl or The Troll or...) but on it's own merits. Because if one wants V4 - well, we already have it. I think Genesis is much better at being Genesis than it is at being V4, and V4 is much better at being V4 than it is at being The Troll ;) (I also tend to think that the origianl the Girl is better at being The Girl than V4 is ;) )

For example - here's V4 with smoothing turned off (so showing the actual mesh) and V5 with smoothing turned on (showing it as close to "as intended" as Poser does with it), side-by-side and using the same texture:

http://i46.tinypic.com/2cscfsw.jpg

Although neither Genesis nor V5 were actually designed for Poser, I personally think that V5 (designed not for Poser, but for Genesis) looks better than Genesis-as-V4. That blck line actually only appears when the character is smoothed, so it may be possible to light it better to get better results. I'm afraid I'm not much of one for postwork so I hesitate to suggest using postwork to smooth out that one area - but to me the eyes and lips also look much improved over the "V4 clone" look.

Cheers,

Cliff

PS V5 is short - so I've raider her up to get her head at a similar level.