UDIM is a system for dividing texture space into multiple “tiles” in UV space, with each tile represented by a separate texture file on disk. You can specify a texture name like foo<UDIM>.exr and any UDIM-aware renderer or image loading node will know to replace the <UDIM> token with the address of the UV tile it wants to look up.

Separating UV space into different texture files lets you use high-resolution files for large, detailed islands, and low-resolution files for small or simple islands. It can also have benefits for file and memory cache locality.

Nodes that lay out geometry in texture space (such as the UV Layout node) can have controls for spreading UV islands across tiles. However, most support for UDIM doesn’t require any UI. Practically all modern nodes, renderers, asset management systems, and so on, know to look for a <UDIM> token in texture filenames and expand it as necessary, including USD’s path resolver.

• The first tile is named 1001, and covers the 0, 0 - 1, 1 square of UV space.

• The second tile is named 1002, and covers the 1, 0 - 2, 1 square.

• Numbers increase this way until after the 10th tile (in regular UDIM the tile array is a maximum 10 tiles across in U space).

• The 11th tile (named 1011) wraps back to the first column (starting at 0 in U space) and up by 1 unit in V space (covers the 0, 1 - 1, 2 square).

• Subsequent tiles follow the same pattern, increasing in U space until each 11th tile wraps back

• Note that the digits represent a single number starting at 1001 and increasing for each tile.

• UV Layout surface node

• File Cache surface node

• Texture VOP node

• Bake Texture render node

• has_udim

• expand_udim

• texprintf

• The Houdini file open dialog automatically looks for runs of increasing numbers in filenames, and can confuse a UDIM sequence with a frame sequence. Use the pop-up menu in the file dialog to explicitly choose what kind of replacement token you want to use for sequences (<UDIM> for UDIM, $F for frames).