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...

Download my free stuff here: http://www.renderosity.com/homepage.php?page=2&userid=323368

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:

===========================sigline======================================================

Cage can be an opinionated jerk who posts without thinking. He apologizes for this. He's honestly not trying to be a turkeyhead.

Cage had some freebies, compatible with Poser 11 and below. His Python scripts were saved at archive.org, along with the rest of the Morphography site, where they were hosted.

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.

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

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

Comitted to excellence through art.

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.

===========================sigline======================================================

Cage can be an opinionated jerk who posts without thinking. He apologizes for this. He's honestly not trying to be a turkeyhead.

Cage had some freebies, compatible with Poser 11 and below. His Python scripts were saved at archive.org, along with the rest of the Morphography site, where they were hosted.

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.

♥ My Gallery Albums ♥ My YT ♥ Party in the CarrarArtists Forum ♪♪♪ 10 years of Carrara forum ♥ My FreeStuff

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

Open save file
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

Load UVs

Open UVset
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

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:

===========================sigline======================================================

Cage can be an opinionated jerk who posts without thinking. He apologizes for this. He's honestly not trying to be a turkeyhead.

Cage had some freebies, compatible with Poser 11 and below. His Python scripts were saved at archive.org, along with the rest of the Morphography site, where they were hosted.

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

Open save file

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

End

Load UVs

Open UVset

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

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?

♥ My Gallery Albums ♥ My YT ♥ Party in the CarrarArtists Forum ♪♪♪ 10 years of Carrara forum ♥ My FreeStuff

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:

===========================sigline======================================================

Cage can be an opinionated jerk who posts without thinking. He apologizes for this. He's honestly not trying to be a turkeyhead.

Cage had some freebies, compatible with Poser 11 and below. His Python scripts were saved at archive.org, along with the rest of the Morphography site, where they were hosted.

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:

===========================sigline======================================================

Cage can be an opinionated jerk who posts without thinking. He apologizes for this. He's honestly not trying to be a turkeyhead.

Cage had some freebies, compatible with Poser 11 and below. His Python scripts were saved at archive.org, along with the rest of the Morphography site, where they were hosted.

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

Well I'm already using my own file format to store just a cloud of UV points - all that my scripts allowed to change.

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

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?

♥ My Gallery Albums ♥ My YT ♥ Party in the CarrarArtists Forum ♪♪♪ 10 years of Carrara forum ♥ My FreeStuff

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

OK - it's a little clumsily captured but here at least is an attempt at showing how slow this version is - and it's likely that it would only get slower as I add in more error-checking to stop things going "boom". Also, there's no way to pick a particular file name and location to load or save to as yet - I've just concentrated on getting the darned thing working again, and on removing Genesis-specific checks (so while I'm using Genesis to do this, it's not reliant on Genesis). The UV file is a text file a little over 3MB in size (because it's a text file with lots of number in!).

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:

===========================sigline======================================================

Cage can be an opinionated jerk who posts without thinking. He apologizes for this. He's honestly not trying to be a turkeyhead.

Cage had some freebies, compatible with Poser 11 and below. His Python scripts were saved at archive.org, along with the rest of the Morphography site, where they were hosted.

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....

----------------------------------------------------------------------------------------

The Wisdom of bagginsbill:

"Oh - the manual says that? I have never read the manual - this must be why."
“I could buy better software, but then I'd have to be an artist and what's the point of that?"
"The [R'osity Forum Search] 'Default' label should actually say 'Don't Find What I'm Looking For'".
bagginsbill's Free Stuff... https://web.archive.org/web/20201010171535/https://sites.google.com/site/bagginsbill/Home

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.

Download my free stuff here: http://www.renderosity.com/homepage.php?page=2&userid=323368

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

♥ My Gallery Albums ♥ My YT ♥ Party in the CarrarArtists Forum ♪♪♪ 10 years of Carrara forum ♥ My FreeStuff

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?

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.
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.

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.

♥ My Gallery Albums ♥ My YT ♥ Party in the CarrarArtists Forum ♪♪♪ 10 years of Carrara forum ♥ My FreeStuff

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:

Redesign of the icons.
Documentation.
Further testing and fixing (probably do this during documenting).
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:

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.)

Download my free stuff here: http://www.renderosity.com/homepage.php?page=2&userid=323368

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.

Download my free stuff here: http://www.renderosity.com/homepage.php?page=2&userid=323368

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.

Way too many people take way too many things way too seriously.

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.

Download my free stuff here: http://www.renderosity.com/homepage.php?page=2&userid=323368

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.

Download my free stuff here: http://www.renderosity.com/homepage.php?page=2&userid=323368

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

Forum: Poser - OFFICIAL

Subject: UV Map switching script?