UDIM Textures: support for different file name schemes #77989

New Issue

Arvid · 2020-06-18T07:07:22+02:00

Arvid commented

2020-06-18 07:07:22 +02:00

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: Quadro RTX 8000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 442.92

Blender Version
Broken: version: 2.83.0, branch: master, commit date: 2020-06-03 14:38, hash: 211b6c29f7
Worked: (newest version of Blender that worked as expected)

Short description of error
Hello!
Coming from a VFX background working in the industry for 15y.

It seems right now that udim tiles are recognized if the format is filename_1001.exr
Depending on the DCC like Mari, Painter or others, it's common to have a format like filename.1001.exr.

This format is not recognized, so I have to rename my UDIM textures for blender.

Please make sure that all UDIM formats are recognized like , .1001, _1001

This description is taken from #72734:

0-based (Zbrush) - select this option if your UV co-ordinates start at 0
Some applications, for example, Zbrush, number the UV tiles with the lower left UV co-ordinate. That is, a UV tile [0,0]x(1,1) would use u0_v0 in its file name.

1-based (Mudbox) - select this option if your UV co-ordinates start at 1
Some applications, for example Mudbox, number the UV tiles with the upper right UV co-ordinate. That is, a UV tile [0,0]x(1,1) would use u1_v1 in its file name.

2-UDIM (Mari) - select this option if your UV co-ordinates are represented as a four-digit number using the formula 1000+(u+1+v*10)

3-Explicit Tiles - select this option to load each tile separately and enter the U and V values explicitly. For each tile, enter the values of the lower-left UV co-ordinate that the texture corresponds to.

Exact steps for others to reproduce the error
[Please describe the exact steps needed to reproduce the issue]
[Based on the default startup or an attached .blend file (as simple as possible)]

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: Quadro RTX 8000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 442.92 **Blender Version** Broken: version: 2.83.0, branch: master, commit date: 2020-06-03 14:38, hash: `211b6c29f7` Worked: (newest version of Blender that worked as expected) **Short description of error** Hello! Coming from a VFX background working in the industry for 15y. It seems right now that udim tiles are recognized if the format is filename_1001.exr Depending on the DCC like Mari, Painter or others, it's common to have a format like filename.1001.exr. This format is not recognized, so I have to rename my UDIM textures for blender. Please make **sure** that all UDIM formats are recognized like <UDIM>, .1001, _1001 This description is taken from #72734: ``` 0-based (Zbrush) - select this option if your UV co-ordinates start at 0 Some applications, for example, Zbrush, number the UV tiles with the lower left UV co-ordinate. That is, a UV tile [0,0]x(1,1) would use u0_v0 in its file name. 1-based (Mudbox) - select this option if your UV co-ordinates start at 1 Some applications, for example Mudbox, number the UV tiles with the upper right UV co-ordinate. That is, a UV tile [0,0]x(1,1) would use u1_v1 in its file name. 2-UDIM (Mari) - select this option if your UV co-ordinates are represented as a four-digit number using the formula 1000+(u+1+v*10) 3-Explicit Tiles - select this option to load each tile separately and enter the U and V values explicitly. For each tile, enter the values of the lower-left UV co-ordinate that the texture corresponds to. ``` **Exact steps for others to reproduce the error** [Please describe the exact steps needed to reproduce the issue] [Based on the default startup or an attached .blend file (as simple as possible)]

Arvid commented

2020-06-18 07:07:22 +02:00

Added subscriber: @arvidurs

blender-admin commented

2020-06-18 07:07:22 +02:00

#82119 was marked as duplicate of this issue

Ankit Meel changed title from ~~UDIM Textures Token~~ to UDIM Textures: recognise textures based on filenames

2020-06-18 07:47:01 +02:00

Ankit Meel changed title from ~~UDIM Textures: recognise textures based on filenames~~ to UDIM Textures: recognise textures by filenames

2020-06-18 07:47:21 +02:00

Philipp Oeser commented

2020-06-18 10:06:09 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-06-18 10:06:09 +02:00

This also came up in #72734 (UDIMs don't behave properly on imported geometry).
However, this is already on the list in #72390 (Improve UDIM functionality) under

Consider adding support for different file name schemes

This is taken from #72734:


0-based (Zbrush) - select this option if your UV co-ordinates start at 0
Some applications, for example, Zbrush, number the UV tiles with the lower left UV co-ordinate. That is, a UV tile [0,0]x(1,1) would use u0_v0 in its file name.

1-based (Mudbox) - select this option if your UV co-ordinates start at 1
Some applications, for example Mudbox, number the UV tiles with the upper right UV co-ordinate. That is, a UV tile [0,0]x(1,1) would use u1_v1 in its file name.

2-UDIM (Mari) - select this option if your UV co-ordinates are represented as a four-digit number using the formula 1000+(u+1+v*10)

3-Explicit Tiles - select this option to load each tile separately and enter the U and V values explicitly. For each tile, enter the values of the lower-left UV co-ordinate that the texture corresponds to.

Also some info here
https://www.fxguide.com/fxfeatured/udim-uv-mapping/

Think we can keep this as the TODO task to reference in #72390.

This also came up in #72734 (UDIMs don't behave properly on imported geometry). However, this is already on the list in #72390 (Improve UDIM functionality) under > Consider adding support for different file name schemes This is taken from #72734: ``` 0-based (Zbrush) - select this option if your UV co-ordinates start at 0 Some applications, for example, Zbrush, number the UV tiles with the lower left UV co-ordinate. That is, a UV tile [0,0]x(1,1) would use u0_v0 in its file name. 1-based (Mudbox) - select this option if your UV co-ordinates start at 1 Some applications, for example Mudbox, number the UV tiles with the upper right UV co-ordinate. That is, a UV tile [0,0]x(1,1) would use u1_v1 in its file name. 2-UDIM (Mari) - select this option if your UV co-ordinates are represented as a four-digit number using the formula 1000+(u+1+v*10) 3-Explicit Tiles - select this option to load each tile separately and enter the U and V values explicitly. For each tile, enter the values of the lower-left UV co-ordinate that the texture corresponds to. ``` Also some info here https://www.fxguide.com/fxfeatured/udim-uv-mapping/ Think we can keep this as the TODO task to reference in #72390.

Philipp Oeser changed title from ~~UDIM Textures: recognise textures by filenames~~ to UDIM Textures: support for different file name schemes

2020-06-18 10:06:39 +02:00

Philipp Oeser commented

2020-06-18 10:06:39 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Brecht Van Lommel commented

2020-06-18 16:22:32 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2020-06-18 16:22:32 +02:00

To be clear, as far as I know both filename_1001.exr and filename.1001.exr work already. We don't test for preceding underscores.

What is not supported is conventions other than UDIM, like u0_v0. And using tokens like <udim>, which are not part of the file names on disk, but would be a way to explicitly specify to Blender which part of the filename contains the UDIM part rather than Blender auto detecting it.

To be clear, as far as I know both `filename_1001.exr` and `filename.1001.exr` work already. We don't test for preceding underscores. What is not supported is conventions other than UDIM, like `u0_v0`. And using tokens like `<udim>`, which are not part of the file names on disk, but would be a way to explicitly specify to Blender which part of the filename contains the UDIM part rather than Blender auto detecting it.

Régis commented

2020-07-03 15:15:36 +02:00

Added subscriber: @Redj

Régis commented

2020-07-03 15:15:36 +02:00

Hi,
I'm having a similar issue.
Indeed, both filename_1001.exr and filename.1001.exr seem to work alright, but I'm dealing with production files (coming from a Maya pipeline) that include a version number placed after the tile number, it looks like this: filename.1001_v000_001.exr. It fails to be detected as UDIMs, apparently because the tile number is not followed by the file extension directly.

In this case, the only way to have Blender detect the UDIM tiles sequence is to rename the files, since there's no way to set the tiles manually for existing textures.

And using tokens like , which are not part of the file names on disk, but would be a way to explicitly specify to Blender which part of the filename contains the UDIM part rather than Blender auto detecting it.

Having this would be great.

Hi, I'm having a similar issue. Indeed, both `filename_1001.exr` and `filename.1001.exr` seem to work alright, but I'm dealing with production files (coming from a Maya pipeline) that include a version number placed after the tile number, it looks like this: `filename.1001_v000_001.exr`. It fails to be detected as UDIMs, apparently because the tile number is not followed by the file extension directly. In this case, the only way to have Blender detect the UDIM tiles sequence is to rename the files, since there's no way to set the tiles manually for existing textures. > And using tokens like <udim>, which are not part of the file names on disk, but would be a way to explicitly specify to Blender which part of the filename contains the UDIM part rather than Blender auto detecting it. > Having this would be great.

Evan Wilson commented

2020-10-27 06:36:06 +01:00

Added subscriber: @Funnybob

Robert Rioux commented

2020-10-27 11:32:33 +01:00

You have to understand that UDIMs are NOT an image sequence that needs to start at 1001. UDIMs only represents tiles. They can be non-sequential and they don't have to start at 1001. This is how it works in every software in the industry. The attached image is a perfectly valid UV setup that would work in every software but Blender. It's a show stopper. It breaks compatibility with other software. If I get a model from another vendor that it setup like that, I won't be able to use it in Blender.

You have to understand that UDIMs are NOT an image sequence that needs to start at 1001. UDIMs only represents tiles. They can be non-sequential and they don't have to start at 1001. This is how it works in every software in the industry. The attached image is a perfectly valid UV setup that would work in every software but Blender. It's a show stopper. It breaks compatibility with other software. If I get a model from another vendor that it setup like that, I won't be able to use it in Blender. ![Screen Shot 2020-10-27 at 6.27.37 AM.png](https://archive.blender.org/developer/F9109761/Screen_Shot_2020-10-27_at_6.27.37_AM.png)

Alessandro Padovani commented

2021-02-15 13:25:23 +01:00

Added subscriber: @padone

Alessandro Padovani commented

2021-02-15 13:25:23 +01:00

Also other softwares may use different names for the udim tiles, that is, the name doesn't need to be unique. Then we may have multiple udim textures in the same folder, as in the example below. So the only valid convention around seems to be the udim number, and everything else may vary from software to software.

So what about storing a udim list internally, instead of forcing a name convention ? This would solve all the compatibility issues.

torso_diffuse_1001.jpg
torso_specular_1001.jpg
legs_diffuse_1002.jpg
legs_specular_1002.jpg

p.s. I am a contributor for the blender plugin to import daz files, so my comment comes from the daz world. Actually we copy and rename textures to import udims, that's not ideal.

http://diffeomorphic.blogspot.com/p/daz-importer-version-15.html
http://diffeomorphic.blogspot.com/2019/12/udim-support.html

Also other softwares may use different names for the udim tiles, that is, the name doesn't need to be unique. Then we may have multiple udim textures in the same folder, as in the example below. So the only valid convention around seems to be the udim number, and everything else may vary from software to software. So what about storing a udim list internally, instead of forcing a name convention ? This would solve all the compatibility issues. torso_diffuse_1001.jpg torso_specular_1001.jpg legs_diffuse_1002.jpg legs_specular_1002.jpg **p.s.** I am a contributor for the blender plugin to import daz files, so my comment comes from the daz world. Actually we copy and rename textures to import udims, that's not ideal. http://diffeomorphic.blogspot.com/p/daz-importer-version-15.html http://diffeomorphic.blogspot.com/2019/12/udim-support.html

Robert Rioux commented

2021-07-09 21:33:58 +02:00

I just saw how Pixar addresses the different naming conventions in Renderman. It's actually better than Maya.

I just saw how Pixar addresses the different naming conventions in Renderman. It's actually better than Maya. ![Screen Shot 2021-07-09 at 3.31.02 PM.png](https://archive.blender.org/developer/F10218638/Screen_Shot_2021-07-09_at_3.31.02_PM.png)

Jesse Yurkovich commented

2021-07-09 21:50:46 +02:00

Added subscriber: @deadpin

Jesse Yurkovich commented

2021-07-09 21:50:46 +02:00

Yes, most software allows placeholders to be used inside a filename detailing where the udim information can be extracted from. Some examples are supported by OpenImageIO directly: https://openimageio.readthedocs.io/en/master/texturesys.html#udim-and-texture-atlases

I've recently uploaded a few other UDIM-related patches for review (can search by name; won't list them here in this task). If those go well, this would likely be the next thing I look at attempting to address as I get time on my end. Others are still free to look if you get to it before I do as there's no guarantee I can do it.

Yes, most software allows placeholders to be used inside a filename detailing where the udim information can be extracted from. Some examples are supported by OpenImageIO directly: https://openimageio.readthedocs.io/en/master/texturesys.html#udim-and-texture-atlases I've recently uploaded a few other UDIM-related patches for review (can search by name; won't list them here in this task). If those go well, this would likely be the next thing I look at attempting to address as I get time on my end. Others are still free to look if you get to it before I do as there's no guarantee I can do it.

blender-admin commented

2021-12-31 07:06:23 +01:00

This issue was referenced by 180b66ae8a

This issue was referenced by 180b66ae8a1ffc0a1bb7d3993028240b4c7f7246

Jesse Yurkovich commented

2022-01-04 01:14:31 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Jesse Yurkovich closed this issue

2022-01-04 01:14:31 +01:00

Jesse Yurkovich self-assigned this 2022-01-04 01:14:31 +01:00

Jesse Yurkovich commented

2022-01-04 01:14:31 +01:00

This issue should be fixed by the checkin noted above. Let me also try to sort out the various discussions here as well:

Pre 3.0: As previously stated, Blender was already capable of handling both .1001. vs _1001_ etc.
3.0: Tiles no longer have to start at 1001
New 3.1: If detection fails, like what might happen with say filename.1001_v000_001.exr, you can now tell blender where the information is by inserting a UDIM token manually within the Image Editor. e.g. filename.<UDIM>_v000_001.exr
New 3.1: There's 2 tokens supported today for different naming schemes ( and )
- They are the same as what MaterialX (page 18) supports
- They should cover interop between most (all?) DCCs (i.e. most should be capable of reading/writing using one of these two conventions)
  Example for u-tile of 3 and v-tile of 1:
  filename.<UDIM>_ver0023.png --> filename.1014_ver0023.png
  filename.<UVTILE>_ver0023.png -->filename.u4_v2_ver0023.png

This issue should be fixed by the checkin noted above. Let me also try to sort out the various discussions here as well: - Pre 3.0: As previously stated, Blender was already capable of handling both `.1001.` vs `_1001_` etc. - 3.0: Tiles no longer have to start at 1001 - New 3.1: If detection fails, like what might happen with say `filename.1001_v000_001.exr`, you can now tell blender where the information is by inserting a UDIM token manually within the Image Editor. e.g. `filename.<UDIM>_v000_001.exr` - New 3.1: There's 2 tokens supported today for different naming schemes (<UDIM> and <UVTILE>) - They are the same as what [MaterialX (page 18)](http://www.materialx.org/assets/MaterialX.v1.38.Spec.pdf) supports - They should cover interop between most (all?) DCCs (i.e. most should be capable of reading/writing using one of these two conventions) Example for u-tile of 3 and v-tile of 1: `filename.<UDIM>_ver0023.png` --> `filename.1014_ver0023.png` `filename.<UVTILE>_ver0023.png` -->`filename.u4_v2_ver0023.png`

kursad k commented

2022-07-21 19:01:26 +02:00

Added subscriber: @kursadk

kursad k commented

2022-07-21 19:01:26 +02:00

Blender seem to get very confused if the first tile of the UDIM images start with .1000. Is there a plan to support UDIMS that that with the 1000 (from Zbrush) range?

Brecht Van Lommel commented

2022-07-21 19:59:22 +02:00

The UDIM convention is to start at 1001. I would imagine ZBrush does that by default too, at least I couldn't find any information saying otherwise?

Alessandro Padovani commented

2022-07-22 06:44:26 +02:00

Again the file name doesn't have to be unique, as noted above. In daz studio we have different file names for the uv tiles. How do you handle that in blender ?

torso_diffuse_1001.jpg
torso_specular_1001.jpg
legs_diffuse_1002.jpg
legs_specular_1002.jpg

Again the file name doesn't have to be unique, as noted above. In daz studio we have different file names for the uv tiles. How do you handle that in blender ? torso_diffuse_1001.jpg torso_specular_1001.jpg legs_diffuse_1002.jpg legs_specular_1002.jpg

Brecht Van Lommel commented

2022-07-22 13:05:27 +02:00

In #77989#1393869, @padone wrote:
Again the file name doesn't have to be unique, as noted above. In daz studio we have different file names for the uv tiles. How do you handle that in blender ?

Is that really following the UDIM convention? I don't know Daz Studio, but in major 3D apps and renderers I've only encountered UDIM tokens in file paths, that would not work with such different file names.

> In #77989#1393869, @padone wrote: > Again the file name doesn't have to be unique, as noted above. In daz studio we have different file names for the uv tiles. How do you handle that in blender ? Is that really following the UDIM convention? I don't know Daz Studio, but in major 3D apps and renderers I've only encountered UDIM tokens in file paths, that would not work with such different file names.

Alessandro Padovani commented

2022-07-22 15:41:09 +02:00

In #77989#1394027, @brecht wrote:
Is that really following the UDIM convention?

Well if you alone decide that daz studio is not a "major 3D app" and thus is not included in the "udim convention", then there's no margin of discussion of course. What I'm pointing out is that daz studio uses different names for the uv tiles. So for example a udim diffuse texture can have different names for different parts.

it's not:

"diffuse_1001" "diffuse_1002" "diffuse_1003"

but it's rather:

"arms_diffuse_1001" "legs_diffuse_1002" "torso_diffuse_1003"

To support different names it would be "enough" to include a "4-explicit names" option, where you enter both the uv tile and the file name.

0-based
1-based
2-udim
3-explicit tiles
4-explicit names - select this option to load each tile separately and enter the U and V values and the texture name explicitly.

> In #77989#1394027, @brecht wrote: > Is that really following the UDIM convention? Well if you alone decide that daz studio is not a "major 3D app" and thus is not included in the "udim convention", then there's no margin of discussion of course. What I'm pointing out is that daz studio uses different names for the uv tiles. So for example a udim diffuse texture can have different names for different parts. it's not: "diffuse_1001" "diffuse_1002" "diffuse_1003" but it's rather: "arms_diffuse_1001" "legs_diffuse_1002" "torso_diffuse_1003" To support different names it would be "enough" to include a "4-explicit names" option, where you enter both the uv tile and the file name. 0-based 1-based 2-udim 3-explicit tiles 4-explicit names - select this option to load each tile separately and enter the U and V values and the texture name explicitly.

Robert Rioux commented

2022-07-22 15:53:47 +02:00

Then I would contact Daz and tell them that their way of using UDIMs makes no sense at all. The idea behind UDIMs is to avoid having different names. That would be unthinkable to work like this in VFX because there's not way to automatically connect the right texture to the right UDIM. You would have to do this manually and create an image node for every single image.

Brecht Van Lommel commented

2022-07-22 16:09:23 +02:00

Looking at the discussion here, the arms, legs and torse images are each used in different materials.
https://bitbucket.org/Diffeomorphic/import_daz/issues/381/better-udim

So as far as I can tell these are not even meant to be a single UDIM image by the Daz Studio exporter. You want to be able to merge these materials without renaming the image files along with it. That may be convenient, but I don't think it's worth deviating from the convention and running into incompatibilities exporting such materials to renderers and other file formats.

Looking at the discussion here, the arms, legs and torse images are each used in different materials. https://bitbucket.org/Diffeomorphic/import_daz/issues/381/better-udim So as far as I can tell these are not even meant to be a single UDIM image by the Daz Studio exporter. You want to be able to merge these materials without renaming the image files along with it. That may be convenient, but I don't think it's worth deviating from the convention and running into incompatibilities exporting such materials to renderers and other file formats.

Alessandro Padovani commented

2022-07-22 16:26:25 +02:00

In #77989#1394187, @brecht wrote:
Looking at the discussion here, the arms, legs and torse images are each used in different materials.
https://bitbucket.org/Diffeomorphic/import_daz/issues/381/better-udim

Well udims are textures, not materials. Of course I can use a udim texture in different materials, the same as I can use a regular texture in different materials. Those are meant to be a single udim as you can tell from the names, but diffeomorphic can't import them as udim because blender doesn't support the names. So we have to copy the textures and rename them to the blender convention to make the udims.

As if it's worth to support daz studio you can judge by yourself. It's practically the largest asset library in the whole known universe. The ones below are only some of the shops selling daz studio assets. Then I understand blender may go a different way and thus we will continue to copy tons of 8K textures from the daz library just to rename them to the blender convention. Thank you.

https://www.daz3d.com/shop/
https://www.renderosity.com/
https://www.forender.com/

> In #77989#1394187, @brecht wrote: > Looking at the discussion here, the arms, legs and torse images are each used in different materials. > https://bitbucket.org/Diffeomorphic/import_daz/issues/381/better-udim Well udims are textures, not materials. Of course I can use a udim texture in different materials, the same as I can use a regular texture in different materials. Those are meant to be a single udim as you can tell from the names, but diffeomorphic can't import them as udim because blender doesn't support the names. So we have to copy the textures and rename them to the blender convention to make the udims. As if it's worth to support daz studio you can judge by yourself. It's practically the largest asset library in the whole known universe. The ones below are only some of the shops selling daz studio assets. Then I understand blender may go a different way and thus we will continue to copy tons of 8K textures from the daz library just to rename them to the blender convention. Thank you. https://www.daz3d.com/shop/ https://www.renderosity.com/ https://www.forender.com/

Brecht Van Lommel commented

2022-07-22 16:44:57 +02:00

It's not the Blender convention, it's the UDIM convention found across many 3D apps and renderers. It doesn"t make sense to add a bunch of complexity to Blender, OpenImageIO, OpenShadingLanguage, USD, Maya, ... instead of solving the issue at the root.

If you want more convenient material merging, I suggest to request either Daz Studio to make their image file names compatible with that, or request diffeomorphic to support image file renaming.

It's not the Blender convention, it's the UDIM convention found across many 3D apps and renderers. It doesn"t make sense to add a bunch of complexity to Blender, OpenImageIO, OpenShadingLanguage, USD, Maya, ... instead of solving the issue at the root. If you want more convenient material merging, I suggest to request either Daz Studio to make their image file names compatible with that, or request diffeomorphic to support image file renaming.

Alessandro Padovani commented

2022-07-22 17:00:02 +02:00

In #77989#1394198, @brecht wrote:
It's not the Blender convention, it's the UDIM convention

And we go straight to the start it's a loop. Who decides what is the "udim convention" and what "3D apps" to include support for ?

Of course your "suggestion" is already implemented, diffeomorphic copies and renames textures to the "udim convention". But again this way we have to copy tons of 8K textures from the daz library otherwise if we just rename them the daz assets will not find them anymore. Just to fit a naming convention that could be "easily" extended with an extra option for "explicit names".

But again I understand that blender may go its own way.

edit. p.s. It's just not very "blender" if it doesn't blend-in if you forgive me the joke.

> In #77989#1394198, @brecht wrote: > It's not the Blender convention, it's the UDIM convention And we go straight to the start it's a loop. Who decides what is the "udim convention" and what "3D apps" to include support for ? Of course your "suggestion" is already implemented, diffeomorphic copies and renames textures to the "udim convention". But again this way we have to copy tons of 8K textures from the daz library otherwise if we just rename them the daz assets will not find them anymore. Just to fit a naming convention that could be "easily" extended with an extra option for "explicit names". But again I understand that blender may go its own way. **edit. p.s.** It's just not very "blender" if it doesn't blend-in if you forgive me the joke.

kursad k commented

2022-07-22 17:28:15 +02:00

Here is my couple cents. The initial 1000 might not be a UDIM convention but no other 3D DCC (Mari, Maya etc) has any issue loading them except Blender. It is fine if Blender wants to stick to 1001+ range when baking new textures, however it would be very helpful if it loads the UDIM sets that start with 1000. Like others mentioned some apps just bake textures starting at 1000.

Blender assumes that a UDIM texture that starts with ".1000. " is just a regular single image file. This is really a friction point in a pipeline in my view.

Thanks

Here is my couple cents. The initial 1000 might not be a UDIM convention but no other 3D DCC (Mari, Maya etc) has any issue loading them except Blender. It is fine if Blender wants to stick to 1001+ range when baking new textures, however it would be very helpful if it loads the UDIM sets that start with 1000. Like others mentioned some apps just bake textures starting at 1000. Blender assumes that a UDIM texture that starts with ".1000. " is just a regular single image file. This is really a friction point in a pipeline in my view. Thanks

Robert Rioux commented

2022-07-22 17:47:16 +02:00

Who decides what is the "udim convention"

The guy who created it decided.

UDIM is not new – it was invented by Richard Addison-Wood and came (as many good things have) from Weta Digital (circa 2002). It comes from U-Dimension numbers 1001 upwards. The system of parsing UDIM files is really easy as the order is embedded into the very filename in a really easy to access way. Using other naming system like like u0_v0 naming requires a bit more parsing. In a word it is simple. As such major companies like MPC, DNeg, Weta Digital and others use it daily.

> Who decides what is the "udim convention" The guy who created it decided. UDIM is not new – it was invented by Richard Addison-Wood and came (as many good things have) from Weta Digital (circa 2002). It comes from U-Dimension numbers 1001 upwards. The system of parsing UDIM files is really easy as the order is embedded into the very filename in a really easy to access way. Using other naming system like like u0_v0 naming requires a bit more parsing. In a word it is simple. As such major companies like MPC, DNeg, Weta Digital and others use it daily.

Brecht Van Lommel commented

2022-07-22 17:50:33 +02:00

In #77989#1394213, @kursadk wrote:
Here is my couple cents. The initial 1000 might not be a UDIM convention but no other 3D DCC (Mari, Maya etc) has any issue loading them except Blender. It is fine if Blender wants to stick to 1001+ range when baking new textures, however it would be very helpful if it loads the UDIM sets that start with 1000. Like others mentioned some apps just bake textures starting at 1000.

Can you be specific about which software bakes textures starting 1000 (and if it does so by default)? I could not find confirmation that Zbrush saves UDIM images starting at 1000.

And how does other software handle UDIMs starting at 1000, how does it distinguish them between those starting at 1001? I couldn't quickly find anything in the docs of other software, but may well have missed some option or alternative <UDIM> token syntax.

> In #77989#1394213, @kursadk wrote: > Here is my couple cents. The initial 1000 might not be a UDIM convention but no other 3D DCC (Mari, Maya etc) has any issue loading them except Blender. It is fine if Blender wants to stick to 1001+ range when baking new textures, however it would be very helpful if it loads the UDIM sets that start with 1000. Like others mentioned some apps just bake textures starting at 1000. Can you be specific about which software bakes textures starting 1000 (and if it does so by default)? I could not find confirmation that Zbrush saves UDIM images starting at 1000. And how does other software handle UDIMs starting at 1000, how does it distinguish them between those starting at 1001? I couldn't quickly find anything in the docs of other software, but may well have missed some option or alternative `<UDIM>` token syntax.

Jesse Yurkovich commented

2022-07-23 02:20:48 +02:00

I too would not consider these UDIMs nor are they treated as such inside OpenImageIO- [x]. They just happen to be textures with numbers in their filename. That said, assuming such files reside somewhere between 1001 and 2000, and since Blender 3.2, these will load just fine (they will load correctly in 3.1 with a slight tweak too). They will be loaded as a tiled image, residing in the proper UV space, but will be separate from each other and not treated as a singular entity. It's a separate Image for each of them but they otherwise still work correctly on a mesh once assigned[2].

While researching this topic myself I came across a similar workflow where the person was importing from DAZ into Substance. There, at least a few versions ago, you need to map each one of the DAZ images to the proper tile in question, manually... it's similar in Blender today.

So you can abuse the tiled-ness by using those numbers, but you will lose out on the automatic treatment of the entire texture set as just 1 image and will also need to manually assign the materials.

https://openimageio.readthedocs.io/en/master/texturesys.html#udim-texture-atlases
Manual example:

I too would not consider these UDIMs nor are they treated as such inside OpenImageIO- [x]. They just happen to be textures with numbers in their filename. That said, assuming such files reside somewhere between 1001 and 2000, and since Blender 3.2, these will load just fine (they will load correctly in 3.1 with a slight tweak too). They will be loaded as a tiled image, residing in the proper UV space, but will be separate from each other and not treated as a singular entity. It's a separate Image for each of them but they otherwise still work correctly on a mesh once assigned[2]. While researching this topic myself I came across a similar workflow where the person was importing from DAZ into Substance. There, at least a few versions ago, you need to map each one of the DAZ images to the proper tile in question, manually... it's similar in Blender today. So you can abuse the tiled-ness by using those numbers, but you will lose out on the automatic treatment of the entire texture set as just 1 image and will also need to manually assign the materials. - [x] https://openimageio.readthedocs.io/en/master/texturesys.html#udim-texture-atlases - [x] Manual example: ![manual-example.png](https://archive.blender.org/developer/F13309309/manual-example.png)

Alessandro Padovani commented

2022-07-23 06:18:01 +02:00

In #77989#1394340, @deadpin wrote:
you need to map each one of the DAZ images to the proper tile in question

If I understand correctly you're suggesting to use option 3-explicit tiles, that will become multiple udims with a single texture each that's a nonsense. We need 4-explicit names. But I understand the openio thing. I mean if blender wants to be 100% compliant with openio, that's not mandatory by the way.

> In #77989#1394340, @deadpin wrote: > you need to map each one of the DAZ images to the proper tile in question If I understand correctly you're suggesting to use option 3-explicit tiles, that will become multiple udims with a single texture each that's a nonsense. We need 4-explicit names. But I understand the openio thing. I mean if blender wants to be 100% compliant with openio, that's not mandatory by the way.

Damien Picard referenced this issue

2023-11-06 00:48:00 +01:00

Improve UDIM functionality #72390

Sign in to join this conversation.