I'm trying to make sense of a shader and UV trick to which odf alludes in the "Antonia - Opinions" thread. I'll quote the relevant posts here and link to the pages.

https://www.renderosity.com/mod/forumpro/?thread_id=2753785&page_number=33

odf said, in post @3407769:

"In the meantime, here's the height map for stockings I promised bagginsbill. The tips of the toes are around 0.25 and the top of the pantyhose region around 0.75. This might need some fine-tuning, but should work in principle. Let me know what you think.

One interesting aspect of this map is that it was rendered in Poser with Antonia's standard UVs posing as geometry and an alternate set of UVs as - obviously - UVs. Then I made a very simple shader that translated the v coordinate - which in this case happened to be just the y coordinate of the original mesh with the feet stretched out - into gray values and rendered using the front camera shifted by (0.5, 0.5) in native Poser units and scaled at 100%. Et voila!"

https://www.renderosity.com/mod/forumpro/?thread_id=2753785&page_number=35

odf said, in post @3410465:

"I gave some thought on how to support multiple UV mappings for a figure, and I think I've got the answer. The height map I posted a few pages back was a first test. One can actually use Poser to render a texture map for UV mapping A onto a template for UV mapping B and thus convert the texture map into one that works with B. Obviously, there will be some loss in detail, but if the original map has fairly high resolution and appropriate filtering is used, it shouldn't be too bad."

Can anyone make sense of this? I'm wondering what it looks like as a shader, how it works, and what we could do with this sort of node setup.

there is a node thread at cgbytes.com where BB posts. I think it is called "the node knows"

Love esther

Thanks, esther. :D

On page 126, odf refers to the technique again, post @3514785:

https://www.renderosity.com/mod/forumpro/?thread_id=2753785&page_number=126

"The third option would be to convert the textures. There's a simple trick for doing that in Poser: I create a prop with the old UV coordinates as UV coordinates (do'h) and the new UV coordinates as x,y positions. Then I render that using the front camera at zoom factor 1 with the texture as the ambient color (and no diffuse or specular). The nice thing about that is that once I've made the prop, anyone can use it to convert all the textures they have."

I still don't quite follow him, but the general idea seems clearer. I'll keep reading the thread and see if he clarifies any further....

I guess all the Mat Room whizzes have left the building. Sad, sad.

I don't understand the first reference you gave in your original post, and I'm not totally sure about the second - but this last one isn't a material room procedure at all, assuming I have understood that as well as I imagine I have. I think I've also seen it proposed by Anton Kisiel back in the day.

I'd paraphrase it this way: take a plane on which you apply the source map. Then you morph the plane (insert handwaving here) until it has the UV mapping of the target. Then you render it in such a way that the input pixel values are exactly reproduced, which odf's method will do.

There are limitations to the transforms you can do this way, of course. You couldn't transform a V3 map into a V4 one, for example. Your plane would need to be high poly, i think. Also the process of deciding how to calculate the morph escapes me for all cases, although I did once make a prop which transforms a rectangular map into a circular one. The details were posted in the DAZ forum and are probably long gone by now.

Lastly, there's a little-known utility called UV2UV which can do this, albeit with some caveats, the major one being that the source and target meshes have to be the same. They also have to be triangulated, and the input and output maps have to be in BMP format; but those things are surmountable. Although I can't link to UV2UV it should be the top result if you search for it.

So, wait... this isn't a shader node trick he's describing? It's more of a morphing trick?

Now I'm really perplexed. Hmm.

Thanks, EB! :D

That's my understanding. To quote your quote "I create a prop with the old UV coordinates as UV coordinates (do'h) and the new UV coordinates as x,y positions." He specifically mentions a prop, and I've made a much simpler UV transform prop myself so I know the technique is sound. Also, odf said it, so it must be sound. :)

I've been searching for the prop I made, but all the discussion took place on the DAZ forum circa November 2010, and I can't find an archive of that anywhere.

odf's comment about uv coordinates versus xy coordinates ought to be a clue. I'll mull it over and see if my brain can get into gear.

This "trick" creates a converter prop. If you have the same model with two different UV sets, the generated prop will convert textures from one UV set to the other. It's not a shader nor a morph. It's a way to convert textures.

You need the same geometry, though. You could not use it to convert from V4 to Pauline, because the geometry is different.

If you know how to make such a prop, bantha, do please share! I have so far failed to get my head around it.

I think odf used this as the foundation for his Scala:Meshes code, which is available at GitHub and seems to be as baffling as the process under discussion here. Heh. But in discussing his Scala project, at various points in the long Antonia thread, odf makes it clear that the process requires mesh compatibility. The Scala code is an improvement on... whatever it is that we have here... in that it can handle different levels of subD resolution across two meshes. The Poser trick (whatever it is) requires identical geometries, but Scala only needs compatible polygon structures and one common point on both meshes to start the poly-flow correlations. Way over my head, and apparently Spanki's as well... which makes it way, way, way over my head. :P

Yes, please, bantha -- if you know how to do this, share it with the community!

I could probably write a python script which would create such a prop. But you would need two models with identical geometries, but different UV maps. This would not work if the geometry is different. I've no idea how to work with different geometries. Isn't there a texture convertig tools for most major figures out there which does exactly that? If you would have a remapped figure, this could work. Maybe we could transform some textures using DPHoardleys remaps. But then, why not simply use the remapped figure?

The basic idea is the following - every vertex has in fact five coordinates - xyz in 3d-Space and uv in 2D-Space for the UV map. If you have two models with the same xyz coordinates but different uv coordinates, you could create a model which uses the uv coordinates from model 1 as xy coordinates for a new model, with Z0 uniformely. The new model would use the UV coordinates from model 2 as uv. If you load a texture from model 2, the new prop would show a uv map for model1, The image may be slightly distorted if there is any distortion in the UV map.

But the whole thing isn't that usefull, IMHO, since you could simply use the prop with the fitting UV map. As I said the geometry needs to be identical.

For which model would you need it?

For myself, I don't need the trick for any specific model. I think the general Poser knowledge base would benefit if we had a working example for this available for study. Someone down the road may be able to implement the principles here in ways we can't imagine right now.

From the way you've explained it, I wonder if anything in the method could help resolve the problems with UV transfer Spanki and I ran up against, with TDMT. I don't think either of us tried to harness the XYZ coords when seeking a way to clean up bad UV transfers along island edges (or seams). I'm not sure this could help with that, but it's an approach we left untried.

I will see if I find some time to write something like this. I don't think it's really difficult, I just doubt that it's usefull for anyone.

Sorry I'm not around here much. I don't care for this software and being constantly irritated isn't good for my state of mind.

Anyway, the UV mapping (or remapping as you discovered) was not a direct requirement, but an indirect one from an earlier requirement.

The earlier requirements, posed by me, was this: Make the UV map of the legs go in such a way as to proceed smoothly and consistently in the V direction up the leg, such that equal spaces in V corresponded to equal spacing up the foot + leg, starting from the tip of the toe, and oriented so that wraparound values at the seam were in agreement about the V position. There should be no deviation in orientation or spacing. The motivation was to be able to use the V coordinate, alone, as a means to produce shader effects for stockings, garters, socks -- basically everything that suffers from poke through in geometry (close-fit stockings) or distortion in texture (e.g. fishnet diamonds).

At first, odf saw this as a vexing problem. To accomplish this he basically had to freeze the geometry and he was constantly tweaking. He wanted a way to automate it. Worse, the UV unwrapping tools he had would not obey this rule of V coordinate position and orientation. As well, there were competing mappings - the perfect mapping for skin is not the perfect mapping for fishnet.

So odf was looking for a way to define UV remapping in an intermediate texture. The plan was, you use the real, fixed UV coordinates to look up an alternative coordinate in a map. That alternative coordinate then could be used for my stocking bands, or other V-oriented procedural values. The scripts he later talked about were doing just that - producing automatically that coordinate translation map based on the actual 5-D XYZUV points of the figure. Unfortunately, the final UV mapping of Antonia is no longer compatible with that Y map in the thread that odf attached, so I can't demonstrate how it works. Did he post an updated one later? I kind of wandered off the thread at that time as I was very busy with work.

Here, I show how the actual UV mapping of the legs fails to meet my goals. I'm using procedural comparisons to the V coordinate to determine what density to create for the stocking overlay. You can see that the iso-V lines are not straight, but twisted, and that they do not agree on either side of the seams.

I think odf's original mapping for Antonia is the Antonia-A version. The primary mapping was contributed by... MikeJ? Most of the Antonia developers group preferred the MikeJ version, which was more like V4 or something something. The A-version mappings are included in the download at odf's Google site, but were left out of the Antonia Standard release at RDNA. (I tried to get them not to do that, but supposedly two mapping versions and two mesh resolutions made odf's Antonia release too confusing.)

To stop babbling, odf's original mapping is available at his site, but I'm not sure whether he managed to make it meet the standards you hoped for in the project.

UV mapping software is really frustrating, to veer OT. I wish odf had gone ahead with the UV software he started programming. I have a dozen applications which handle UV mapping, but not one of them will make UVs symmetrical. To get that, you need to pay hundreds of dollars for one of the two or three professional level UV programs. Really weird, very frustrating.