Problem with new uv tile / texture set workflow

[relief7]

Hi,

I just had a quick glimpse at the new UDIM painting workflow, and while it is amazing that we can finally paint over UDIMs, I personally find the additional grouping of UV Tiles based on texture sets (or material ids) very confusing and not practical. Some of my co-workers also expressed their hesitation about it.

In my opinion, the organization of meshes into "texture sets" on the one hand and "uv tiles" on the other hand are two completely separate things and they should never be connected the way they are in SP in 2020.2.0 version. Where one way of organization is somehow dependent of the other.

The reason why I find this problematic is the following: We do lots of iterations in modeling and therefore have to update our SP project many times with changed models (VFX industry, sometimes up to 100 UDIMs). Each time we update the model, we now have to check that all uv tiles still have the right "texture set" applied. Otherwise they will "break".

Example: Let's say the modeling department splits 1 shader into 2. "Metal" will become "MetalA" and "MetalB". If I import the new model, the textures are now broken because there are two new texture sets. Ok then I use "Reassign Texture Sets Reassignment" Dialog and I can reassign Metal to MetalA but I cannot apply Metal to MetalB. I can only swap texture sets.

Also, this process may work for small assets with few UDIMs but try working on an asset with 100 UDIMs. It is hard enough to keep track what changed model / uv-wise. I don't want to additionally manually manage (and keep track) to which texture set each uv tile belongs (at least not in SP!). Or if maybe just because a modeler changed the material name, my uv tiles are now broken and lost their textures. Keeping track of this takes a lot of time additionally and just having a list of udims (like it was before) seems way more straightforward and clear. If I only want to work on flat textures / UDIMs and do not want to worry about "texture sets", it is very cumbersome now in the latest version.

ideas for improvement?
-separate texture sets and uv tiles and remove their dependency from each other
-for now, having a checkbox on import to ignore all material ids would already help. Then we get a "flat hierarchy" with just one "texture set" so we don't have to worry about reassigning texture sets after model updates
-bring back a window to control the visibility of uv tiles (eye icon, isolate, hide all / invert), I know about the "ignore masked uv tiles" option but this only works for paint layers, not for fill layers, sometimes you want to work isolated on just a few uv tiles (for performance reasons or to see them better etc.)

For now, I will kill any materials on meshes that go inside SP but this is an extra step that I have to take that was not necessary before.

If anybody has better ideas, please let me know! I am grateful for any tip!

Thanks!

[Jeremie Noguer]

Hi, thank you for the feedback.
Combining UDIMs and Texture Set was intentional to give more flexibility to different kinds of users and allow some to manage their complex and heavy assets through texture sets, but of course every pipeline is different.
Having an option to ignore material assignment should not be too hard to add on our side.
We are also considering enabling the "ignore masked tile" option no matter what layer is selected, there is no technical reason why it would only work on Paint layers.

[smoothsoperator]

Hi, thank you for the feedback.
Combining UDIMs and Texture Set was intentional to give more flexibility to different kinds of users and allow some to manage their complex and heavy assets through texture sets, but of course every pipeline is different.
Having an option to ignore material assignment should not be too hard to add on our side.
We are also considering enabling the "ignore masked tile" option no matter what layer is selected, there is no technical reason why it would only work on Paint layers.

Aside from coming here to write essentially all of what relief7 already said, I also support these changes you mention.

Combining UDIMs and Texture Sets would be a great organizational feature IF painting across texture sets was possible. Currently however, having texture sets in a udim project totally defeats the purpose of using udims in the first place. Either texture sets should be disabled entirely on a udim project or, ideally, painting across texture sets should be supported.

The "ignore masked tile" option is needed on all layer types, not just paint layers. Even better would be an additional visibility toggle per udim much like there is for texture sets.

I'm so stoked painting across udims is now possible, with these few small fixes I would be in texturing heaven.

[adso99]

Just to flag we're in the same predicament as the posts above (also for VFX use).   

We've been successfully using Painter to paint entire sets in the 100 UDIM range with 4k / 8k exports.  We also encounter frequent geo updates, UV changes, multiple materials per UDIM, etc, so the ability to update geo/UVs, solo one/several texture set UDIMs at a time, instance materials across the texture sets without breaking or reassigning materials is all critical to that workflow. 

The new UV tile method doesn't respect this process as far as we can tell, so we'll need to stick to the legacy method for now.

[daniel0711@web.de]

Hi everyone, I even don't understand the new workflow.
I mean ok, we can paint across udims now. But what do I have to do to get textures exported with the UDIM number?
What is the correct tag we need to use here?
Edit found it : $udim makes sense. Pretty confusing $textureSet was the previous one for legacy workflow.

[CAGameDEV]

All you need to do is make sure you have the proper tag (.$udim) and you're using the correct output template and it will add the UDIM Tile number to the position you marked it at.

$mesh_$textureSet_BaseColor(.$udim)

In every case I've seen it not show up with the 1001, 1002, ect... was either because the user didn't select the correct template, or used a cache version.