I'm trying to wrap my head around this and so far everything seems incredibly convoluted and unnecessary, so I thought I'd ask here for a better way.

I use a lot of pre-made geometry from various kit bash collections like Kitbash3D, Turbosquid, etc.

Typically the models come in pre-UV wrapped with UV attributes already in place. The problem is that when I take a look at the UV maps in Houdini, they all seem to overlap and extend far beyond the typical UV tile (see attached image) – this doesn't even make sense to me – shouldn't an object's surface all fit neatly into a single UV tile?!? How can a UV map contain overlapping and out-of-bound geometry?

This weird UV's in turn seem to wreck havoc with Substance Painter when I tell it to bake maps such as AO, Curvature, Normals, etc. which return jumbled and messy without actually matching the geometry.

I'm just looking for a way to get proper UV maps from Houdini into Substance Painter so that I can get Substance Painter to bake proper AO and Curvature maps so that in turn I can use smart materials and masks effectively.

Can anyone point to a proper UV workflow to go from Houdini into Substance Painter or other external paint app?

Do the UVs on those kitbash components look ok in other software packages? I don't know what the quality control is like for bought assets so it might be a good thing to rule out before trying to troubleshoot things in houdini.
The workflow in this tutorial should help with getting something ready for substance painter: https://www.sidefx.com/tutorials/high_res_mesh/ [www.sidefx.com]

Here's what I suspect is happening:

1. Most of these assets are likely modeled in something like Maya, where I think that it's common to use multiple UV sets for any given geometry.

2. Houdini imports the FBX files with the multiple UV maps. From reading and googling, I found that there used to exist a Layer Node that would allow the user to separate the various UV maps, but such node no longer exists.

3. Substance Painter in turn doesn't recognize multiple UV maps, just reads UV 0 and calls it a day. I suspect this is causing the weirdness when I bake Normal, AO and Curvature maps which are being then mapped back incorrectly.

So…

I think that there are two possible solutions:

A. Use UVLayout to either remap the various UV maps into a single UV Tile, or alternatively create a set of UDIM Tiles for export into Substance Painter (which recently acquired the ability to work with UDIM Tiles).

B. Delete the existing UV Attribute, and then use something like LABS AutoUV's to generate a brand new UV Map that is correctly laid out on a single UV Tile and export that to Substance Painter.

Either way, it seems like a convoluted PITA. Does anyone know a better way?

those uvs don't look correct for any workflow
multiple uv sets are still contained to 0-1 uv space and UDIMs would not have polygons crossing any uv tile's boundaries

also while Layer SOP is gone, there is a newer workflow for multiple uv sets in Houdini, so when importing geo with multiple uv sets it should simply come in as multiple vector attributes marked as (Tex) whatever the names


if you have overlapping uvs, it probably means that they come from multiple objects, importing obj or fbx with multiple objects will probably create prim groups so you can distinguish them individually, and fit the uvs to 0-1 tile for each of them
also exporting .obj with multiple prim groups should export them as individual objects, but maybe it's better to create s@path attribute based on those groups and export as .abc

Hi,

I have only just revisited current documentation for Substance Painter (it used to be too slow and too limited in UDIM workflows in the past), but from my understanding, there are two issues:

- Substance Painter, even though it can now deal with UDIMs to a very limited extent, cannot use patches ACROSS UDIMs (which shouldn't be done anyway). So the layouts you showed above won't work anyway.
- UV space is 0 to 1. If one tile you are importing is going beyond that - UDIM offset aside - either the import has gone wrong or the model is broken.

I deal a lot with more or less broken UV/UDIM data. The first thing I usually do is make sure that within a material group (primitive attribute, usually) UV space is within 0 to 1 (maybe with a UDIM offset). Since most of the time this leads to materials with the same shop path overlapping, I separate those by simply adding UDIM offsets “per material”. That “splits” materials across several UDIM patches, cleaning things up neatly.


Marc

Edit/P.S. “Dealing with” means: Simply gather the min/max boundary of a UV area and scale all positions accordingly.

malbrecht
The first thing I usually do is make sure that within a material group (primitive attribute, usually) UV space is within 0 to 1 (maybe with a UDIM offset). Since most of the time this leads to materials with the same shop path overlapping, I separate those by simply adding UDIM offsets “per material”. That “splits” materials across several UDIM patches, cleaning things up neatly.

How do you add UDIM offsets? With UV Layout or is there another preferred workflow. The fact that between Houdini and Labs there are well over a dozen UV-related nodes doesn't help!

Hi, Kays,

How do you add UDIM offsets?

UV space is 0-1. A UDIM layout ranges from 0 to 9 for x (in the UV vector's x component) and 0 to 99 in y. .

Houdini has too many nodes for me, so I just write a VEX wrapper that runs over the UV values and corrects them. It's quite possible that I am reinventing the wheel every time I use Houdini, but my guts say that's still faster than looking up the “best node”

What you could do with above scenario is run a VEX over all UV data and store min/max values into a detail attribute. Then run a second VEX that takes that min/max and scales all UV values accordingly. That would bring all UV values into 0-1. Then you'd look up which material or shop_path or group each component you are running over belongs to and offset x/y accordingly.

For example:
You have 10 materials and your VEX already took care of all UV values being within 0-1.
You'd then look up each component's (point's, vertex') “membership” for group or material (depending on what your classification for grouping is) from a list/an array. You'd add the array's index to the x-component of the UV coordinate, which, with 10 materials, would fit nicely (going from 0-9 for the integer part of the x then).
If you have got more than 10 materials, you'd add a modulo 10 for the y-component - et voila, UDIMs.

I hope this helps. If you could prep a simple test-file, I'd quick'n dirty hack a wrangle-soup into it :-)

Marc

you can use UV Layout SOP which can split uvs into UDIMS based on an attribute
https://www.sidefx.com/forum/topic/71657/#post-305258 [www.sidefx.com]

Thank you both. Yeah, I know how to do the UDIM's in Layout, so it's great that you're confirming it. Regarding the whole VEX thing, I'm afraid that Marc is on the next-level of Jedi/ninja skillset with the coding compared to my @P = … knowledge!

Hi, Kays,

here's a simplified and over-exaggerated complicated (sorry, I ate a clown) example. I split the workflow up into several steps:

• Create a circle (obvious)
  
• create tris
  
• add UV
  
• randomize UV scale all across the place
  
• attribute promote to a single detail with minimum and maximum used UV (this could be put into a wrangle as well, but it might be faster this way)
  
• last wrangle moves the UV coordinate to 0 if minimum is not 0, calculates the “scale” (the maximum range per axis) and normalizes the coordinate. This could (and should) be simplified, could be done in one or two lines, but hopefully this “long winded” version is helpful in stepping beyond modifying “P” :-D
  

Have a look at each node in the UV layout.

By adding an offset (1, 2, 3 …) to the x and y component of the UV (index 0 and 1) you can “UDIM-ize” the UV coordinates. I am not sure if Houdini supports 3-dimensional UV coordinates (it uses a 3-component vector), I'd just ignore the third channel.

Marc

Thank you Marc, I appreciate your ingenious approach to the problem, but I'm just wondering if UV Layout is a simpler way to tackle this type of issue?

Kays, absolutely! I am not saying that the above method is “the best”, “the only” or even “the suggested one”. I would incorporate whatever else is necessary to deal with the mess at hand into that code anyway - thus probably saving several Houdini-nodes.

I have a baker-dozen of reasons for not using Houdini nodes, one of which is that I use other software for production purpose and Houdini is merely a test-bed for me, so I simply don't have all the nodes at heart and looking up what might be useful takes me MUCH longer than writing down a few lines of code.
Another simple reason is that by writing code that is SIMPLE and does ONE simple job that you can immediately quality-check is that one can learn a lot this way. It doesn't matter if there are “out-of-the-box” solutions available if a dog wants to learn a new trick.

Most of the other reasons have to do with Houdini specifically and this may not be the place to go down there :-D

Marc

in current sbsP state, to utilize multiple UV sets you have to have different materials for items. Per your weird UVing, uvlayout should fix things PER OBJECT.
you can run it in a foreach loop (connected geo).
another ridiculous solution - just delete all UVs and use sbsP autouv if you are too tired of fiddling in H.

glitchi
in current sbsP state, to utilize multiple UV sets you have to have different materials for items. Per your weird UVing, uvlayout should fix things PER OBJECT.
you can run it in a foreach loop (connected geo).

Yeah, that part I get. What I don't understand is why on FBX imports, the UV mapping extends well beyond the UV 0-1 island which I thought was standard. That's what I'm having a hard time wrapping my noggin around.

Ok, so this is what I came up with which seems to fix my issue:

1. Use the Blast Node to get rid of UV sets for the other material groups, as well as geometry groups for each of my material groups (in this case 3 groups)…I also recompute the normals while I'm at it because why not?

2. Use UV Layout to arrange each of the individual UV sets into a single UV 0-1 Tile. This is annoyingly time consuming but what the hell!

3. Merge the 3 branches back into one, add a Material node which I can then assign 3 different materials so that Substance Painter will be happy.

This appears to get me a workable set of UV maps so that Substance Painter can compute and bake proper AO, Normal and Curvature maps!

Whew….now I still don't understand why the FBX UV sets are so gigantic and go way over the 0-1 UV Tile as shown in my first image.

i generally don't get UV problems on import. might be a case with that particular kitbash asset of yours - outdated fbx or some pre-historic max file format shenanigans - who knows!
thankfully you resolved it.

i'll be continuing my epic waiting for sbsp udims for now, haha. anyway, i usually do what i wrote before: foreach via connected -> autouv+layout -> materials -> export. does the job.

glitchi
i generally don't get UV problems on import. might be a case with that particular kitbash asset of yours - outdated fbx or some pre-historic max file format shenanigans - who knows!
thankfully you resolved it.

I gotta tell you, they're all like that – KitBash3D, Gumroad, Turbosquid, all of the UV's come in looking weirdly oversized. Now, to be clear, this is not a problem when the plan is to remain within Houdini, everything will map out correctly and there shouldn't be any issues. The problems come in when exporting to Substance Painter, and asking SP to generate AO and Curvature maps which then get re-mapped weirdly to the geometry. I think the issue is more with how SP interprets the UV maps than how Houdini does…but it's an issue nonetheless.

Sounds strange, honestly … are you importing OBJ or another format? OBJ would allow you to simply open the file in a text editor and have a quick peek at the ACTUAL UV data, so you could check if it's a problem in Houdini or with the files.

Do you have an example link where one could download such a “wonky file” without having to register first?

Marc

Here's an .fbx file as an example. Import using the File Node and take a look at the UV view.

Definitely not a Houdini-problem:



… I wonder if that is a “standard” on those sites you are downloading from. I mean … this isn't exactly something I would pay money for.

Marc