Question regarding UDIM's

ioannespavlvsxcix

well i just tested the usage of UDIM's and i have some concerns about it, first i thought that working with UDIM textures would give a single tiled image of all the textures or something, but all i got were a pack of texture sets per UV tile that i made in substance painter, my question is:
How is it any different of the method of multi material objects assigned to each poly, then exported to substance painter and exported as different sets of textures?
i end up with the same, an object with different assignments and 6 packs of textures, working with UDIM's only saves you to create materials
it seems like the UDIM workflow is so much better than the old one but i see no difference at all...
Hope you can understand what i mean

Obscura

Wrong forum section, this should have went into the technical talk, instead of general discussion. Anyways, there isn't much difference between the 2 methods. Earlier I heard that the naming convention of udims can be beneficial when making a script that automates connecting of textures, but honestly, I think you could do the exact same thing with multi-materials too. Maybe someone else who have more experience with udims can shed some more light on the topic.

oglu

If you have 200 uv tiles you dont have todo anything by hand. If you have a robot for a feature film with 1200 parts and 200 uv tiles you just slap one material on them and all is done. Those tiles are stored even if you go out to an other tool like zbrush or whatever. Try to preserve a per face shader assignement if you export an fbx from maya to mudbox. Go with an obj to zbrush, export to mari and back to maya and in the end with an alembic to houdi for a sim and render in katana. Yes, thats the way of an film asset in production. The uvs will stay the same and the shader from the biginning in maya will work in katana.

All modern render engines can read them. 

Per face assigned shaders are a nogo on feature film. One object does have only one shader for procedural shader assignments. Also later in comp you are in trouble with per face assigned shaders.

And for creature it assential to have one one shader on the whole body caus of ss shaders. If the creature is only one polyshell its the only way to paint across those tiles (its in beta for substance). But Mari and Mudbox are able to paint across tiles since the beginnign. Its the main reason why Weta invented Mari and Mudbox.

oglu

One good example is this Robot here.
https://www.artstation.com/artwork/wXzPg

And this old Mari video here at 4min.
https://www.youtube.com/watch?v=chn60uPGBv0

ioannespavlvsxcix

oglu said:

If you have 200 uv tiles you dont have todo anything by hand. If you have a robot for a feature film with 1200 parts and 200 uv tiles you just slap one material on them and all is done. Those tiles are stored even if you go out to an other tool like zbrush or whatever. Try to preserve a per face shader assignement if you export an fbx from maya to mudbox. Go with an obj to zbrush, export to mari and back to maya and in the end with an alembic to houdi for a sim and render in katana. Yes, thats the way of an film asset in production. The uvs will stay the same and the shader from the biginning in maya will work in katana.

All modern render engines can read them. 

Per face assigned shaders are a nogo on feature film. One object does have only one shader for procedural shader assignments. Also later in comp you are in trouble with per face assigned shaders.

And for creature it assential to have one one shader on the whole body caus of ss shaders. If the creature is only one polyshell its the only way to paint across those tiles (its in beta for substance). But Mari and Mudbox are able to paint across tiles since the beginnign. Its the main reason why Weta invented Mari and Mudbox.

I see, it's only useful as a time saver, not a resources saver, you end up with a whole ton of textures as well but it's faster to apply to models... Very useful for film and vfx but no so much for environments in videogames (i think trim sheets and tileable textures are the real heroes there)
Thanks! 

oglu

Its an essential part of the workflow you cant create highend featurefilm assets without.

And its comming for games too. If im not mistaken there are some hero creatures in god of war done with udims.

The new consoles next year have to support 4k resolution. And substance is coming with full UDIM support this year.

I agree tileable solution wont go away. 

Obscura

To be honest, I have some doubts about this whole thing overall, but please correct me if I'm wrong. If an fbx or obj can't store per face material assignment (which I'm pretty sure fbx can), as you said, I would assume that it can't store a set of assigned textures either so you would need to reconnect them to the material anyways. UVs will stay intact, thats for sure. Also, none of the popular game engines supports udims natively. You can make a custom shader but connecting the textures to it will be a pain. And there is no texture array asset in these game engines so you can't really do it in a dynamic way, the shader code could only be templated to different udim layouts such as 4x1, 4x2 etc. So at least in game engines, its hard and not efficient to use them in production. I've met a few udim assets in game development during my carrier and it was kinda hard to work with them and the shader of them was always hand crafted for the specific purpose.

oglu

You dont have to use them in engine. Just use them in mari to paint across textures. 
Back in maya select the faces based on the UDIMs and assign a shader for each tile. Move all uvs back to the 0-1 space.

In case of a render engine. Lets say Arnold. 
The file read node does handle everything. Just select the first UDIM and its done. 200 textures will get loaded.

And for shaders a materialX Arnold shader does load in Maya, Katana, Houdini you dont have to create a new one. 

oglu

And there is https://graphinesoftware.com/products/granite-for-unreal

rollin

This streaming approach would mean you can work with 'any' amount of single files (vs. atlas) as everything would end up in some cache anyway. 
But this sounds like it should rather be part of d3d ogl vulcan or whatever instead of an engine extension. 
Just because it allows quite fundamental changes in the workflow and asset setup

UDIMs would then just be the standardized input format. So instead of a big atlas holding textures for many assets you might have assets with a set of unique single textures

gnoop

I once had to bake and paint a huge unique "macro" texture for an in-game terrain.    20 textures or so.  Huge pain to assign multi materials  considering it involved re-thinking of uv unwrap several times.   UDIMs were super helpful.      To bad I had to make it multi submaterial in the end anyway for in-game export .  

Couldn't  find any script for Max that could do it automatically.  Do somebody know one?    

Baking is also an issue since no modern cool game oriented bakers like substance ones work with UDIMs

oglu

Mightybake does support UDIMs and at the end of the year hopefully substance. 

gnoop

Good to know, thanks oglu 

I  am looking forward to what SPainter promises.       Too bad  something is always missing.    Like SDesigner that could bake UDIM  but couldn't read UDIM  textures on hi res object to bake from.

oglu

Unreal latest update does support UDIMs now. 

https://docs.unrealengine.com/en-US/Engine/Rendering/VirtualTexturing/Streaming/index.html

lobsang_007

does anyone know how to use udim in new maya 2025 lookdevx