Merging UVs

  • @vilters you mentioned doing a video showing how to stack UVs (for PE) did you ever make one?

    I know we can't ship an obj for say PE or V4 with new UVs in them, but what about shipping a file that just contains the UV info and a script that takes the original obj file reads the data, merges it with the UV info and spits out a modified obj file? That way if someone didn't have the original obj the UV info would be useless. Not a clue whether this would be possible either practically or without breaking copyright but just thinking out loud.

  • Poser Ambassadors

    Might be doable with RTEncoder.

  • Poser Ambassadors

    Hello, the idea was to make 2 video's.
    One how to stack and unstack UV fields.
    A second one how to make Poser figures a LOT more end user friendly using this procedure.

    Many Poser figures have WAY too many material zones making material room and texture work harder then it should be.

    Examples :

    • Upper and lower lashes should be ONE mat zone.
    • The nipples on V4 ?
    • The mess most figure builders make from the eyes? Brr. . . .
    • Unstacking UV fields horizontally while Preview and FireFly have issues with horizontally stacked UV fields. => Stack them vertically. => Only Bella is properly stacked vertically.

    To make this work?

    • You need to unstack the UV fields VERTICALLY and save out a fresh obj file.
    • Combine the existing textures into a new one.
    • Edit the cr2 to point to the fresh obj file and texture.
    • Adapt the material room => That is the easy part. => This is where you gain the most. => I can change a Complete Texture set on V4 or PE or whatever figure, with a single click.

    Video's are coming but I am a bit in overload at the moment. Sorry for that.

  • @vilters could you expand here on just what you mean by stacked UV fields? Do you mean something like the UDIM tiling scheme where overlapping UV maps for non-contiguous areas, or (material) groupings with different UV scales have whole number values added to their U and V coordinates so that the separated maps have a different coordinate space?

    Can you say explicitly what the Preview and FireFly issues are? I'm having difficulty conceiving what difference vertical UV tiling could make over horizontal UV tiling.

    I mention only since I have delved explicitly into it, not to start any kind of flame wars, that most, if not all, of the figures released by DAZ in the Genesis series (post V4/M4) started using UDIM to avoid overlapping UV maps, which uses at most 10 horizontal UV tiles and an almost unlimited number of vertical tiles.

    Sorry to hear of your overload. We'll wait patiently for your responses. ;-)

    I did find some figures that share common UV coordinates for separate body parts, like eyes, which are virtually impossible to parametrically separate without hairy and convoluted logic (when I was trying to develop UV unwrapping techniques).

  • @vilters said in Merging UVs:

    Video's are coming but I am a bit in overload at the moment. Sorry for that.

    That's fine, I just wanted to make sure that the reason I couldn't find them was because they weren't there yet rather than poor searching :)

  • Indeed RTEncoder would be the way to go.
    Users will want to use the skin and face textures, including eyelashes, of donor characters.
    I do not think users will have a main driving interest in a remap of teeth, eyes, tongue, inner mouth, or even nails. The origial materials may do best there. Genitalia may or may not be added to that list.

    So best keep it simple and remap uv's of areas with materials for which in EZSkin you would choose the 'skin' or 'lips' shader model.

  • Poser Ambassadors

    @fverbaas There is NO remapping or retexturing involved.
    My procedure uses the existing textures "as is" , only merged into larger textures.
    And merge "stupid" material zones. Easy to show, difficult to explain.
    For some mat zones like cornea's, or inner mouth, I don't use textures at all because procedural setups work best here and cost next to nothing on memory load..

    V4 and PE (examples) are stacked UV's. All fields are lying one on top of the other.
    Roxie, Pauline and so on are horizontally stacked. Fields are laying next to the previous one. => Horizontally spread.
    Bella 's UV fields are Vertical. One above the other. => The only correct procedure.

    In Poser? ? ? We are getting there LOL.
    Ok, in Poser the Preview and FireFly render engines have issues at the seams between UV fields when they are Horizontally spread. (SuperFly is OK)

    When stacking the UV fields VERTICALLY, all UV seam issues are gone in Preview, FireFly and SuperFly.

    I"ll cancel some projects to make the video's.
    Best regards all and have a nice Sunday. Tony

  • @vilters said in Merging UVs:

    I"ll cancel some projects to make the video's.
    Best regards all and have a nice Sunday. Tony

    Now you are making me feel bad!

  • @vilters Ah, do you mean that they don't correctly distinguish which tile U=1.0 is in (U0,V0) or (U1,V0)? That sort of tolerance problem can usually be fixed by scaling the coordinates by 0.9999, or some not quite 1.0 value.

    Are you basing the "The only correct procedure" assertion on the fact that Preview and Firefly have problems at UV tile seams, or some other criteria. If the actual textures don't go all the way to the edges of the UV tile, I don't see how there can be a problem. Or do you mean that the only way to avoid tile seam problems is not to have horizontal tiling. That seems like putting the cart before the horse. If Poser has a problem in two out of three display pipelines, why is that a fault of the UV layout and not just bugs in Poser?

    I'm only pressing this point, because many other software platforms can correctly deal with UV tiling, so I don't see why their accepted schemes are "incorrect", if the problem stems from Poser bugs. I just like to be clear in my understanding of language used, and English is so easy to misinterpret.

  • @vilters said in Merging UVs:
    One above the other. => The only correct procedure.

    The choice to use stacked (Vertical)or Udim has more to do with what you are trying to do, versus one is just better than the other.

    Top of the list, is animated textures. Udim is far less memory intensive for a few reasons.

    As example.

    If you do an animated textures using stacked, you have to offset it to go to the next frame.
    That offset is done within an interpreter, IE, consumes a lot of clock cycles.
    You have to re read the texture, every called offset, it's a type of parsing....

    Udim ? Just change blocks and your done.
    No fancy node setups to wade thru, etc.
    Nothing to parse, etc

    Mip mapping....

    Udim will only mip map the called block, as needed, in many apps.

    UV, well, it mip maps the entire texture map......
    If you are using a 16k x 16k texture with UV, figure out how big that is mip mapped. It's huge....
    Wait, now that you mip mapped it, your GPU can't even use it.....
    It's too big....
    CPU? you better have a lot of cache.....

    Using an application with mapping ID's?
    You can't add that to UV's if your using that standard,
    UDIM already has ID's in the file.....

    Saying one is better than the other, is a tad misleading.

    What you are rendering, what you are rendering it with, etc.
    Tons of variables to consider.

    Both have their place, and both have downfalls as well.

  • @vilters
    I know, Tony. I was not talking about (un)stacking but about real remapping, say to get a PE that can take V4 or Genesis x maps.