I’ve heard rumors of a python script for Poser 9/Poser Pro 2012 that allows switching between multiple uv maps. This script is sometimes referred to during discussions concerning Poser’s capabilities and how they stack up with Genesis, but the only interest seems to be its use for establishing compatibility with the Genesis figure. I have other interests and would like to have custom UV maps for FBMs in original figures. Ideally the uvs could be traded out without a lot of headache for the end user. Does anyone know if this script currently exists and where it can be found? I wonder what would be required to setup and use this? If the cost is learning Python myself, I'll probably have to pass...

If there is one, I'd be interested to know what approach it uses.  There's been discussion of one, on and off, but I don't know that one exists.  The trouble with any Python script to switch UV maps in Poser would be that it would actually have to switch geometry, in one way or another, and each approach for geometry switching in Poser offers its own complications and limitations.  It could be done, but I doubt the result would be as easy to use, fast, or flexible as it would be in any software where a single geometry can be held in memory with multiple UV maps for that geometry.  :unsure:

In particular, the fact that Poser UV-switching would require actual geometry switching (until and unless some update gives us new options) creates difficulties for animation.  If the point is to animate two UV maps blending while a geometry morphs, complicated tricks would be needed to accomplish this.  The geometry switch would be on or off for all available options, with no gray area to allow any kind of built-in blending effect.  Overall, I think it would be simpler to just swap figures.  :sad:

I always thought it was a gross oversight that there is no UV morph.

We have vertex morphs that alter (and interpolate) xyz based on deltas. Why not uv, or xyzuv? The obj file works for all of these. It's like a two-line change.

Agreed. If you can allow for morphs then you really should allow for a new uv map...that would bust down a few doors.

You can switch in different obj files with different mapping using a dial. It's called "geometry switching" and it's part of Poser though it's not used much anymore. It could also switch materials and material zones as that is also referenced from the obj file. With a master dial you could also adjust all of the body parts at once. The product that I made and sold here had over a hundred different obj files that could be dialed in. That was a long time ago.

As I recall if the obj files are identical geometry wise, (Same number of vertices) you can still use morphs that affect that body part. I'm not positive about that though, experimentation would be needed.

My old product Dial-A-Tile was in freestuff untill about a year ago when my ISP dropped web space.

you can also set up a pz2 file to switch uvmaps / geometries

wroks all the way back to poser 4

but you do have to have both full obj present, which made it unusable for the pupose I developed it for

If a python guy could make a thing that would call a uvs file, slap it onto the obj and then use that new thing for my pz2 then we'd be all set

Lyrra

Quote - you can also set up a pz2 file to switch uvmaps / geometries

Do you mean, by switching the figure geometry reference?  When I tested that, it worked but the change wasn't written out in a saved file.    Alternately, you could use a pose to switch each actor separately, but then you need to have all the alternate geometries separated by actor, as you would with dial-driven geometry switching.

well  I did mine by clipping out everything from a cr2 but the geom reference lines pretty much and switched those to the new obj.  it seemed to load fine, morphed fine, took inj fine and saved with the new obj in place

Some screwiness happened if you tried to switch them back in the same session though.

I didnt look into it more than that since what I wanted was something that would read from a uvs set and not a whole obj.  Customers are so resistant to rte encoding or swapping out uvs manually that I was hoping to make the process more transparant

There are quite a few obj (characters, clothing, etc) that I'd love to texture if only I could improve the uv maps

I've heard rumours about poser adding uv switching sometime, but don't know likely that is

Lyrra

it's all in the vt lines, i think. 

uvclassic can import uvs's, would a uvclassic plugin be totally awesome?  applying uv tweaks right inside poser.  like, multi Os.

Quote - As I recall if the obj files are identical geometry wise, (Same number of vertices) you can still use morphs that affect that body part.

That's correct. You can even have different morph sets applying to geometries with different vertex counts - Poser takes care of matching them up automatically and only shows you the dials which will work on the loaded geometry.

I remember Dial-a-Tile from way back then... Now the material room can scale UVs its usefulness has passed, I suppose.

I also made a UV scale changer which used geometry injection - the embedded geometry version of what Lyrra was discussing. 

Quote - I remember Dial-a-Tile from way back then... Now the material room can scale UVs its usefulness has passed, I suppose.

I still use it on floors and walls. One nice advantage is that the tiling shows in preview mode. What you see is what you get with no need for a test render.

The disadvantage is that it's just a flat plane. Though you can use any number of them.

It didn't sell very well and I have no intention of bringing it back.

Edit to say that it was in free stuff for many years though I never recieved a single thank you or comment about it.

Quote - If there is one, I'd be interested to know what approach it uses.  There's been discussion of one, on and off, but I don't know that one exists.  The trouble with any Python script to switch UV maps in Poser would be that it would actually have to switch geometry, in one way or another, and each approach for geometry switching in Poser offers its own complications and limitations.  It could be done, but I doubt the result would be as easy to use, fast, or flexible as it would be in any software where a single geometry can be held in memory with multiple UV maps for that geometry.  :unsure:

As I wrote the script being discussed, I can assure you that it doesn't need to change geometry or invalidate morph deltas or anything like that. Poser has had the built-in capability, under the hood, to do UV Map switching for a long time I suspect - it's been able to rewrite the UVs since at least Poser 4 so I suspect it's been possible to change the UVs in Pythin sinc ePoser Pro or Poser 5, but I don't ahve the Python methods reference manuals to hand to check.

I was writing it as part of seeing how we could potentially improve compatability with Genesis because so many different UV sets exist for Genesis, but due to the way DAZ have implimented different Uv Maps I decided that either geometry switching or indeed whole figure switching (loading a figure that used a different .OBJ file with a different UV set, but retaining the current pose) was simply quicker and easier.

If you produce new UV sets with the same splits/cuts as exist in the main figure - just like morphs have to have the same cuts and the same vertex order - then switching UV Sets wouldn't be hard at all.

Cheers,

Cliff

PS I may have lost the later more complete versions of the code, but the basic routine was:

SaveUVs

1. Open save file

2. For selected figure cycle through all the actors.

3.. For all the actors, cycle through the texvertices

4... Write the U and v values out to a file

1. End

Load UVs

1. Open UVset

2. For selected figure, cycle through all the actors

3.. For all the actors, cycle through the texture vertices

4... Read in the U and V values from the file and set them on the actor

1. End

Quote - As I wrote the script being discussed, I can assure you that it doesn't need to change geometry or invalidate morph deltas or anything like that.

If you open a saved file which has been subjected to Python geometry-level manipulations, you should find that the original geometry references have been replaced with geomCustom blocks, effectively making the procedure another type of geometry-switching.  Using Python to do it may offer more flexibility for the process, but it should still be an all-or-nothing approach, unless the code is calulating blended UVs from the UVS data file, for each frame.  To get an animated blending effect this way, each frame would have to be recalculated while the animation is rendering.  Whatever UV data has been plugged into the modified geomCustom geometry will still be present globally for that geometry, with no variation by frame.  Or such is my armchair reasoning-based understanding of the matter.  :lol:  This was one of the "complicated tricks" I was referring to.  :unsure:

But if you've made a script, bravo!  Excellent news.  :woot:

Quote - > Quote - If there is one, I'd be interested to know what approach it uses.  There's been discussion of one, on and off, but I don't know that one exists.  The trouble with any Python script to switch UV maps in Poser would be that it would actually have to switch geometry, in one way or another, and each approach for geometry switching in Poser offers its own complications and limitations.  It could be done, but I doubt the result would be as easy to use, fast, or flexible as it would be in any software where a single geometry can be held in memory with multiple UV maps for that geometry.  :unsure:

 

As I wrote the script being discussed, I can assure you that it doesn't need to change geometry or invalidate morph deltas or anything like that. Poser has had the built-in capability, under the hood, to do UV Map switching for a long time I suspect - it's been able to rewrite the UVs since at least Poser 4 so I suspect it's been possible to change the UVs in Pythin sinc ePoser Pro or Poser 5, but I don't ahve the Python methods reference manuals to hand to check.

 

I was writing it as part of seeing how we could potentially improve compatability with Genesis because so many different UV sets exist for Genesis, but due to the way DAZ have implimented different Uv Maps I decided that either geometry switching or indeed whole figure switching (loading a figure that used a different .OBJ file with a different UV set, but retaining the current pose) was simply quicker and easier.

 

If you produce new UV sets with the same splits/cuts as exist in the main figure - just like morphs have to have the same cuts and the same vertex order - then switching UV Sets wouldn't be hard at all.

 

Cheers,

 

Cliff

 

PS I may have lost the later more complete versions of the code, but the basic routine was:

SaveUVs

1. Open save file

2. For selected figure cycle through all the actors.

3.. For all the actors, cycle through the texvertices

4... Write the U and v values out to a file

1. End

 

Load UVs

1. Open UVset

2. For selected figure, cycle through all the actors

3.. For all the actors, cycle through the texture vertices

4... Read in the U and V values from the file and set them on the actor

1. End

this would be so wonderful for people creating brand new figures.

perhaps - as a merchant resource? 

with guidelines so the figure would work well with the script - it wouldn't work if the next poser has subdivision?

And... missed my edit cutoff.  :unsure:

Another complication with UV blending as opposed to on-or-off UV switching.  The two textures for the UV sets being blended would also have to be blended, frame by frame.  The texture pixel positions would have to be recalculated relative to the shifted UVs, for both textures.  Then they would need to be appropriately blended together for each frame and a new texture file written.  The texture file would need to be applied to the geometry.  Then the blended frame could be rendered.

This, for each frame.  At render time.  Complicated!  Hoofa!  :lol:

switching UVs in UVmapper is pretty trivial.

unfortunately - as we have seen with pcf-encoded figures - requiring that people download a 3rd party app and run through a technical process, then re-save .OBJs, etc is usually a death sentence for a product.

a python script that would allow on the fly switching of UVs in poser would be invaluable, and along with the other new features in Poser it could also breathe some life into older figures and meshes.

it would have to be redistributable or built right into Poser though - otherwise whats the point? if you require that a customer to download and install a third party UV switching python script in order to switch UVs, you may as well just ask them to download UVMapper and do it.

It's inevitable that the geometry reference would be invalid after changing the UVs, since the different UVs are in the original OBJ, which would be a pain for saved scenes. But I think Cliff's point was that you can in fact change the UVs without having to change any other aspect of the geometry.

Quote - It's inevitable that the geometry reference would be invalid after changing the UVs, since the different UVs are in the original OBJ, which would be a pain for saved scenes. But I think Cliff's point was that you can in fact change the UVs without having to change any other aspect of the geometry.

Ah.  I see.  I was quoted and then the response said there was no need to change geometry.  The vertex count and order can be retained, keeping the geometry fully functional in Poser, but the geometry itself will have changed.

Prob'ly need to put on my reading comprehension glasses and remove my pendant's beanie.  :unsure:

Well obviously you can't change the UVs without changing ANY geometry since that would include the UV data. That has to be changed for switching! But no change of geometry file, no change of X,Y,Z etc.

Quote - a python script that would allow on the fly switching of UVs in poser would be invaluable, and along with the other new features in Poser it could also breathe some life into older figures and meshes. it would have to be redistributable or built right into Poser though - otherwise whats the point? if you require that a customer to download and install a third party UV switching python script in order to switch UVs, you may as well just ask them to download UVMapper and do it.

Well, I may have lost the final/last step in the process but I should be able to recreate it without TOO much hassle, though I'm nowhere near as proficient as the real Python Gurus. I'd also have to think about how to organise it properly were it to be the basis of anything redistributable rather than as a simple technology test - does anyone fancy actually making new UV sets for any characters? Or to put it another way - is it worth me putting in the effort to make something reasonably flexible and robust rather than just to irritatingly prove the point that actually Poser CAN do that? ;) I'm lazy. I don't want to expend effort on something that seems "cool" only to find no-one actually wants to USE it.

Cheers,

Cliff - who hates being told "You can't do that" and often sets about proving that, in fact, he can (within whatever limitations seem acceptable). Just for the heck of it.

Quote - this would be so wonderful for people creating brand new figures. perhaps - as a merchant resource? 

with guidelines so the figure would work well with the script - it wouldn't work if the next poser has subdivision?

I'll muse on it. It doesn't feel like a commercialy viable product at the moment, more like a freebie if I have the time and inclination, I think I'd like to consider whatever responses we get here. I must admit that part of my concern is that if such a thing were ACTUALLY all that desireable - wouldn't we already have it by now? But then I have often felt that way about stuff I've done - "surely if this was worth doing someone else would have done it long ago" syndrome.

If you have any ideas for a figure that would actually benefit from varying UV Layouts without changing the seams or texture vertex order etc. then I'd love to hear them.

I don't see why UV switching would be inherantly incompatible with subdividing - after all, DAZ Studio does exactly that - has low-poly UV swapping and then subdivides the model afterwards.

Cheers,

Cliff

No, because everytime the question comes up, those asking get told that they can use other programs to do it.  I'm interested, but I'm just one of those lowly content users who likes to render in Poser and doesn't have enough brain cells remaining to remember how to use 5 or 6 programs at once to get to an end result. :)

Quote - Well obviously you can't change the UVs without changing ANY geometry since that would include the UV data. That has to be changed for switching! But no change of geometry file, no change of X,Y,Z etc.

 

Quote - a python script that would allow on the fly switching of UVs in poser would be invaluable, and along with the other new features in Poser it could also breathe some life into older figures and meshes. it would have to be redistributable or built right into Poser though - otherwise whats the point? if you require that a customer to download and install a third party UV switching python script in order to switch UVs, you may as well just ask them to download UVMapper and do it.

Well, I may have lost the final/last step in the process but I should be able to recreate it without TOO much hassle, though I'm nowhere near as proficient as the real Python Gurus. I'd also have to think about how to organise it properly were it to be the basis of anything redistributable rather than as a simple technology test - does anyone fancy actually making new UV sets for any characters? Or to put it another way - is it worth me putting in the effort to make something reasonably flexible and robust rather than just to irritatingly prove the point that actually Poser CAN do that? ;) I'm lazy. I don't want to expend effort on something that seems "cool" only to find no-one actually wants to USE it.

Cheers,

Cliff - who hates being told "You can't do that" and often sets about proving that, in fact, he can (within whatever limitations seem acceptable). Just for the heck of it.

i think it would be a valuable asset to many addon texture creators who choose not to support products or legacy figures due to issues with their UV mapping. it would allow them to 'fix' UVs, and even sell their UV fixes.

if you make it redistributable you can even make some money on it by selling it as a merchant resource, pretty sure most add-on texture artists (which is over half the MP now) would be interested in such a script. youd have to figure out a way for it to work without transferring the actual geometry - such as either using the .uvs format, or its own proprietary UV format.

im just speculating, youd be better off getting the opinions of actual add-on texture artists - i make my own meshes so i dont need to worry about not being able to redistrib them if i make any changes.

Quote - No, because everytime the question comes up, those asking get told that they can use other programs to do it.  I'm interested, but I'm just one of those lowly content users who likes to render in Poser and doesn't have enough brain cells remaining to remember how to use 5 or 6 programs at once to get to an end result. :)

anyone can use UVMapper to transfer UVs from one mesh to another, or from a .uvs file to a mesh.

the problem is that requiring users or your product to go to a 3rd party site, download and install an app, and then go through a multi-step process to import UVs, then resave the object, etc is - like i said - a deaths entence for any product. look at how crippled the sales of .pcf encoded meshes were because of this same problem.

if you can automate the process within poser using python, and the script is either made fredistributable with the products or is integrated into poser, then it will be a very viable tool.

it would allow a texturer to fix Alyson's UVs, or to take Vicky and recombine her maps into a more modern mapping that would be more suitable for full body displacements and procedural shaders, instead of the bloated and wasteful half dozen 4096x4096 maps shes using now.

Very valid points.  And you are probably right about anyone being able to use UV mapper, but it took me forever just to get comfortable using RTencoder, so I could purchase some of those things. LOL

This morning is my kid's last half-day at school - he breaks up for the summer after lunch. I've already looked around for the original script and can't find it but if the phones stay quiet I'll se if I can do something about recreating it and moving towards making something that might be actually useful.

Cheers,

Cliff

PS the attached shows just a Genesis figure swapping UV sets back and forth - the "texture map" that you see changing was produced by UV Mapper Pro 2

Part of the point about scripts in any program - Poser, MS Word, whatever - is to make life easier by putting repetitive boring procedures under control. I'll honestly see if I can put at least a fresh basic test together today - though it's going to have to be Genesis-based simply because that's the figure I have that has different UVs, for testing with. This would be a low alpha test number version.

I'll have to add some extra data for version control and figure identification. We'll see how it goes.

Cheers,

Cliff

Cool!

A few thoughts.

It's possible to call a Python script from within a library file, so the process could be made transparent for the user - just apply a MAT pose or material collection as usual, and the appropriate UVs would be applied.

Antonia has three different UV mappings at the moment. Perhaps a UV switching script would be useful, for the times when you load the wrong one by mistake?

There are also free remaps of other figures available, which their makers might be interested in making available in other formats. dphoadley has done several, and Lyne has remapped many of the animals to allow better texturing.

Quote - It's possible to call a Python script from within a library file, so the process could be made transparent for the user - just apply a MAT pose or material collection as usual, and the appropriate UVs would be applied.

Yup. I've even been considering what the icon design for saving a UV file might look like - but looking over my files it looks like I lost/threw away more than i'd thought. I need to get the basic functionality working before I think about making it easier.

Quote - Antonia has three different UV mappings at the moment. Perhaps a UV switching script would be useful, for the times when you load the wrong one by mistake?

Could be - I didn't realise that any figure (Genesis aside) had multiple UVs out of the gate. However, limitations either of Poser or of my scripting ability might hamper whether any specific pre-existing multiplem UVs would work... but thanks for the heads up, I'll have to see if I can dig up the antonia stuff to test once I get the scripts to a basic working stage again :rolleyes

Quote - There are also free remaps of other figures available, which their makers might be interested in making available in other formats. dphoadley has done several, and Lyne has remapped many of the animals to allow better texturing.

As above, they've probably gone outside what my script hopes to achieve by changing the splits in the UV geometry. Still, it would be nice to be wrong and to be able to do more. I'll achieve as much as I can today - right now I've just installed UV Mapper on my main Win7 64bit PC so I can re-create some nice lined textures so it'll be easily visible that the minor Genesis Uv changes have taken place when I go to load different sets. It's all in the preperation! :)

Cheers,

Cliff

Quick apologies - had my morning taken over by a shitstorm elsewhere. But I'll get back to this just as soon as I can afford to :)

Cheers,

Cliff

maybe SM could buy it from you to be included in the next poser?

LOL if SM wanted it they could code it a lot quicker than I can, I'm sure.

I've managed a little prep work towards getting back to this - creating a test set of texture maps and a basic scene to render in. Will get back to coding when I can (takes more effort than knocking out UV templates does so I need fewer distractions).

 Don't worry - I don't intend to let it drop just because I don't have a lot of time to spend on it right this instant. I'd prefer to crack on with it when I can.

Cheers,

Cliff

OK, I've got a really REALLY crude prototype working again. Let's see if I can knock up a quick .GIF to discuss what it does... and find out if anyone's still interested

Cheers,

Cliff

Since the screen captures were taken at 5 second intervals, and since I had to get to the "Load UVs" menu a second time to actually run the script, this is a LITTLE slower than real-time, but not much. You can see my clock and CPU Meter displayed in the top right corner.

Cheers,

Cliff

As cage has pointed out, it might be simpler and certainly easier for many situations to simply switch the figure out for another figure - except where the person geneerating the different Uv map doesn't have the relevant rights.

This technique as it stands now, with my limited ability with PoserPython (and within what PoserPython can, itself, do) has these "features":

*Cannot currently select files - trivial I guess, but it would still take coding effort however trivial.

*Doesn't have nice library thumbs to run it. Should also be trivial

*UV file (currently with a .tvs extension) MUST match the currently selected figure/.OBJ file to work in terms of texture vertex counts and texture vertex seams.

*Minimal testing has been done - as I've said earlier, this is an early alpha, a "proof-of-concept" type test. More testing would be needed to make sure it's not screwing up somewhere. I'm a little bit suspicious of some of the code as PosePython is lacking some features I'd like - so at the end of the day my code makes more assumptions than I'd like which is limiting the functionality of the script.

*Design issues - at the moment, since I don't actually "feel" a marketplace for this script, I don't know whether it should prompt the user to locate the file to load or have a script per texture set so it's a one-click solution at the end point. Having the user select a file after running "Load UV" would be easier to maintain, I suspect.

*No animation - this isn't about animating from a Michael2 texture to a David3 texture to a Victoria 5 texture all on a single model - it's just about uv texture vertex switching. Bam - on or off, one way or another (or another or...)

*Slow (IMHO). It'd be better to have something written in native code in Poser itself, IMHO.

*Money. I've a kid to feed - if this would only sell to 5 people, or be used by 15 people as a freebie, then development will have to be minimal!

*All sorts of other stuff, I'm sure. but I forget for now. For example - were this to aim for "paid", what's the cheapest Renderosity allows? Because unless it's going to REALLY help merchants it's not worth a lot IMHO. Too simple. As with my Genesis tut, my Python coding skills just aren't all that impressive I'm afraid - I just throw rocks at it until the damn thing works LOL

At the moment it's basically slower than the same kind of feature in DAZ Studio, but also more limited. As the DS 4 feature has under-the-hood access it's able to swap to a completely different UV layout - different seams, different numbers of texture vertices. Otherwise it's the same kind of concept - switching or swapping UV data rather than animating from one set to another, with all the complciations that would arise from that.

Cheers,

Cliff

I'm pretty sure the lowest, non-Prime, price at Rendo is $5 (same as the minimum checkout amount). Rather than using your own format, have you looked at using the DSON format for UVs? PoserPython can load a JSON file, as I recall, in one call (after which accessing items is just accessing members of an object and array) which may reduce one bottleneck, and it's a format that already has a bunch of files written in it.

I haven't actually, for various reasons - and file reading and writing isn't a bottleneck, it's the speed of PoserPython methods to access the geometry which are the big bottleneck. Take those out and the script runs at lightning speed - but doesn't actually DO very much.

I'm not especially interested in the DSON file format at present, and using my own file format has the benefit that I control whether it gets outdated or not. Plus, of course, the file format structure is directly related to how the data is accessible within Poser - which from what Rob has said would mean I'd probably have a pretty nasty job having to try and work out how to extract the UV data from one of DAZ's DSON files usefully for my script.

This is a distinctly different project to the tut that tries to make Genesis as useable in Poser as possible - this is more for Poser native figures.

Meanwhile - $5? $5 isn't much, that could maybe work. That or free (depending on how much more work needs to be put in) sound reasonable.

Cheers,

Cliff

Edit for PS - and I've a sneaky suspicion that the DSON files wouldn't be any used for Poser UV switching anyway, as I believe that they contain a lower-resolution version of the Genesis mesh than the one that the .CR2 exporter creates. So there may be fewer DSON format files that could be any use than you might think.

Would it be faster and easier to work on the .obj file level?  Then you could just scan the file and replace the vt lines, then save with a new filename.  You'd have to save the current scene, then edit the appropriate figure geometry references.  The order of the vt lines would have to be constant between any data file and the target obj, or else some sorting would be required.  If the bottleneck is the geometry API, though, and there's no intent to try to move into animating the effect, that might speed things up.  :unsure:

I can't how that'd be an improvement on just replacing the figure. Which we can already do right in Poser. I mean, if it's going to need a different .obj file then the existing way is already faster than anything I could script up in Python.

There may be SOME simple optimisations that I haven't done yet in tinkering around with old half-forgotten code, but beyond that it'd have to be newer cleverer optimisations that will make my brain hurt to attempt - or be in native code as part of Poser (in which case that's when I'd be more tempted to look at expanding the capability to being able to have different uv seams/uv counts).

Cheers,

Cliff

Yes, the uvs in the DSON file would be for the non-SubD mesh - though that is what the standard route exports for the CR2.

When exporting Genesis the mesh level isn't set to "Base" though - it's set to "High Resolution". One step up, I thought, from the base mesh.

Quote - When exporting Genesis the mesh level isn't set to "Base" though - it's set to "High Resolution". One step up, I thought, from the base mesh.

It's been a couple of months since I exported a Genesis mesh, but Ithought it needed to be set to base or the morphs wouldn't work....

Nope :) the official setting is "High Resolution" - one step up from "Base".

I'm pretty sure I can speed up loading a fair bit - not sure how I'd speed up saving at this point but I have an idea. Just need to find the time to have a bit more of a play with it.

Cheers,

Cliff

Well, it looks like the PoserPython calls to change the UV values aren't where the speed issue lies - looks like it's simply the speed of Python iterating through tens of thousands of vertices :(

After optimising the speed a little, I was getting over 12 seconds for a Genesis UV swap - optimising the UV methods didn't seem to speed it up any more than that so I commented out the UV setting methods, and that made less than 2 seconds improvement on my machine - so still around 11 seconds without actually making the changes. As a result, I can't see any way to get the time down to 10 seconds WITH making the changes using Python. Sure, it can be done - but at that speed and with the seam limitations I don't think it's worth putting more effort into at this time. It'd be far better coded into Poser as native code than as a slow, interpreted script.

Cheers :(

Cliff

Well, that's a shame, guess we'll have to live without it until SM sees it as a desirable feature.  Thanks for letting us know.

Thanks for taking the time to attempt to create this. I guess Daz Studio actually has one feature that Poser doesn't for now.

i don't mind waiting 20 seconds or more for a uv swap.

i've used uv classic to export V4's uvs and imported the uvs to M4. 

for development testing, swapping V4 vts to M4 or viceversa, may be easier than using genni. it removes DS from the equation.

using v4 textures on m4 sounds silly, but it gives m4 a young adult look.

i'm looking at James6's t-shirt, i had an idea to make a texture set for it, to distribute.  but, the top of the shirt, the uv template is squashed up.

a uv swap script for clothes objs -     Fashion Week time!

the t-shirt be a lot quicker than 20 seconds, i'd imagine. 

it would be ultra kewl if the uv swap could be applied within a pose MAT file. or a material collection file.

maybe, you could sell the script as a merchant resource?!
-with a disclaimer on it, not recommended over so many polygons

Hi - Sorry for the delay, I've had a quick holiday and even though I'm back now my head's not totally focussed yet.

OK - so what are we looking for?

1. Library thumb/icon to activate "Save" capability, to which you use a file browser window to specify a file patha nd name. Should be easy.

2. Library thumb to activate "Load" capability, where you'd have to browse to select the relevant uv set.

Would that be acceptable? Or would we need to try and find...

3. a way to generate a library thumb for each UV set that we might want to load?

I think I'll start working on #1 now, maybe even #2 if that goes well.

Cheers,

Cliff

Well, that was harder than it should have been! #1 accomplished, though I don't have a thumb design yet. #2 should be easier following #1, but #3 I'll have to think hard about.

Cheers,

Cliff

I truly don't know how much market for this there would be.  I'm largely ignorant of UV mapping in the first place.  But I'm sure that twenty seconds for this process is less time than it takes to load a UV Mapper, load a figure, load a new UV map, and save the new mapping.  And even if it turned out to be a bit slower, it would greatly lower the number of manual steps, allowing even people like myself to operate it.