Jump to content

UDIM ---> SL


Sowa Mai
 Share

You are about to reply to a thread that has been inactive for 1491 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

(this is what i could find on UDIM, including this: "UDIMs are useful for working on objects that need really high resolution textures. It’s standard to see them in VFX and animation productions, but unusual to see them in a game pipeline."

would those in the know please briefly explain UDIM in an SL context for an IDIM like me  :D. is this something i should try to learn?)

https://cgcookie.com/articles/first-look-at-udim-textures-in-blender-2-82-alpha?utm_source=blendernation

  • Like 1
Link to comment
Share on other sites

I'm struggling to see how this feature can be useful in SL. Can you give an example?

If you want to apply different textures with different resolutions to different faces of your model and want them all laid out on a single UV map, it's dead easy. Simply assign different sectors of the UV map to different materials and then dial in the right sector inworld with texture offsets less-than-1 texture repeats. It takes a little bit of elementary school maths or trial and error but it's hardly rocket science. Then again, why would you want to? You might as well sue the whole UV map area for each face.

If you want everything on the same texture but with different effective resolutions for different parts, the only way is to adjust the relative sizes of the UV islands.

  • Like 2
Link to comment
Share on other sites

@ChinRey You're missing the point of UDIM as a whole. While it is a feature that automates different textures assignment on a UV space base without using multiple materials, as a general workflow it can ease out selection of an object's parts by UV clumping. In game production, pure UDIM is not supported yet, however in a multi-material asset such like those we can have in SL, materials separation becomes easier on objects that need multiple texturable faces, without overlapping UVs, helping procedures like maps baking. Its primary intent is to provide room for more textures and therefore higher resolutions, on the other hand it can also be used to avoid overlapping UVs when duplication or mirroring of geometry is needed, also saving time during texture bake by avoiding cumbersome and time consuming setups. An example here:

Screenshot_1.thumb.png.a84e03ab5abb20bce44b7ce420329df9.png

This is the UV map for a character I've made for a game. Parts that could use mirroring without being detrimental to the general look have been moved to the next UDIM tile, in the same relative position. UV spaces don't end with the usual square one could be used to. From the squares labels, you can see two different nomenclatures, U1V1 followed by 1001, U2V1 followed by 1002 and so on. The first nomenclature is a pure labeling based on the grid, the second is the UDIM label. Now for this particular setup, not only i avoided to waste texture space on the main tile (1001) ensuring more pixels for the whole packing, it also helped with texture baking from the high res model which wasn't receiving  interferences from overlapping UVs of the mirrored parts, in one go, without the need to separate the parts, bake and combine them back later, merge the overlapping vertices etc. One side automatically reads the texture from the main tile on the other side. Moreover, if i wanted to get rid of the mirrored effect, i could make a variation of the texture and easily apply it as another material to the mirrored part without much fuss or mistakes, just selecting the relevant geometry by selecting the UVs on the 1002 and quickly assign the material. This latter isn't really optimal, but arranging the layout differently with another working method in mind (more texturable faces) you can see how easier it is to manage a multi material mesh by packing the relative UVs on their own tile.

  • Like 2
Link to comment
Share on other sites

58 minutes ago, OptimoMaximo said:

@ChinRey You're missing the point of UDIM as a whole.

I think I got it but if I understood the OP right, the question was how to use this directly in SL.

There are two ways to do that. One is to use the inworld texturing functions to assign the right UV area to each texture, the other is to scale up the UV map for each material to cover the entire texture area before you export (but after you've baked of course).

  • Like 1
Link to comment
Share on other sites

4 hours ago, ChinRey said:

I think I got it but if I understood the OP right, the question was how to use this directly in SL.

There are two ways to do that. One is to use the inworld texturing functions to assign the right UV area to each texture, the other is to scale up the UV map for each material to cover the entire texture area before you export (but after you've baked of course).

only the first one of the two options you list is meaningfulto an environment such as SL. The second should really scale down the UVs to fit into the regular UV tile, and this also assumes that UDIMs were laid out accordingly (in a set of tiles that make a square). UDIM workflow assumes that in the U direction you can "only" have 10 tiles (1001-1010) and then it restarts to the next row above (1011-1020), with no filling up obligation before you move to a new vertical tile and virtually no vertical limit. While perfectly doable, such a set up defeats the purpose of UDIM as a whole, losing resolution and increasing the chances to waste texture space. See the example below:

Screenshot_1.png.f5a0e9b63a35dbe6cebf1c0d912ac4fe.png

Suppose you laid out the UDIMs within the 9 tiles marked with the big square, and then you want a single texture, all of them need to be shrunk down to fit the single tile in the bottom left corner. Instead, after working on the textures and each tile has its own, you can assign each tile to a different material, split the 9th into its own geometry object and put another material. (in this example they're 9, no need for this step if you worked your way to have 8 tiles) and on upload it all works as intended.

  • Like 2
Link to comment
Share on other sites

Thanks all for your informed opinions.  The experimental build of blender 2.81 worked well. You created three tiles with three textures your uv map distributed across them.

image.thumb.png.af7a1bac1fcf66834576bd254336dd67.png

 

When the model was imported in to sl each texture/tile was a separate face/material. I am not seeing this behavior in 2.82. When I import in to substance painter it recognizes the three tiles and creates three texture sets as did the experimental 2.81 blender but sl isn't recognizing them any longer. I was wondering if anyone else was able to bring a tiled uv set model in to sl and have it respond as separate materials.

https://gyazo.com/84e1d024d8890002ea8040b347d71d5c image.png.2d8de3a661d2b45ccd2d48b6303f6753.png

Link to comment
Share on other sites

I don't see why you need this? If that's your workflow, just copy all uvs in the finale version to the 0-1 space and apply the according textures to the faces in sl after the upload. In your example, the uvs are pretty bad. Don't waste that much texture space, you easily can copy all uvs to one map. If you want to use a hud to change textures of some parts, you have to think about that while doing the uvs. For the eyes for example, you could add the uvs to the other uvs too, and let them just white. So you could use the sl mod tools to change the color of the eyes without appling another texture. Or, if you want a special textures there, stretch the eye uvs to one square, but use a small seperate texture for them (depends on your details), 128x128, max 256x256 should be enough, because nobody really needs to zoom into such small parts so close, so everything else would be waste of texture memory.

Link to comment
Share on other sites

2 hours ago, Tonk Tomcat said:

I don't see why you need this?

She's learning the general workflow and as a testing item like Suzanne, however bad the UV layout is doesn't matter. 

3 hours ago, Sowa Mai said:

. I was wondering if anyone else was able to bring a tiled uv set model in to sl and have it respond as separate materials

SL and game engines in general don't support UDIMs (yet), which supposes the use of 1 material and the the shader reads the texture numbering. However, if you assign a different material to the geometry corresponding to the UVs within an udim tile, that works in SL. 

  • Like 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1491 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...