Cycles: WIP: Implement UDIM texture node
AbandonedPublic

Authored by Lukas Stockner (lukasstockner97) on Mar 23 2017, 5:02 AM.

Details

Summary

This patch adds a first WIP version of an UDIM node.

Essentially, UDIM is just a standard that extends the UV area beyond the unit square by assigning an ID to each square and storing each tile in its own file.
Therefore, this node is essentially a Multi-Image-Texture node that automatically figures out which tiles are needed, loads them and then uses the correct one in the kernel.

There are three limitations currently:

  • No OSL support. Would be fairly easy to add, just didn't do it yet.
  • No UV input socket, instead the user directly selects the UV map in the node. The reason for that is that the host code needs to know which tiles will be needed, and if the shader tree is doing some funky things to the UVs, there's no way of predicting it. By directly selecting an UV map, the sync code can loop over all UVs and check which tiles are needed.
  • No support for packed files - could be added by just searching the Image datablocks for one that has the correct name, but that brings up the question of how to handle UDIM in Blender outside of Cycles, so I've just not added any builtin image support for now.

Final note before Hype happens: This is a first WIP patch that I hacked together within one day, so expect things to be broken. Not ready for general use yet. This also does NOT mean that UDIM support will necessarily come soon, or even at all.

Diff Detail

Repository
rB Blender
Branch
cycles_udim (branched from master)
Build Status
Buildable 486
Build 486: arc lint + arc unit

Interesting!

Does this need to be a separate node? Could it be a checkbox on the existing image node? When UDIM eventually becomes integrated into Blender itself, I expect that it would be a property of the image datablock without any settings needed on Cycles nodes. At that point it would only be confusing to have to use a different node for different image datablocks.

OpenImageIO texture system supports UDIM, so it should kind of automatically work for OSL already? I never tested that though. It might be useful to look at their implementation. I think they just hardcoded the start tile and columns for example, as far as I know that's part of the UDIM spec.

Why not using the existing file node and add <UDIM> like the other softwares ?
One node, same workflow as Maya, Max etc.

Example

C:\textures\choco1001.exr > C:\textures\choco<UDIM>.exr

For support in OSL, it should only take an update to OpenImageIO 1.7 or newer:

UDIM support for textures: filenames like `"tex_<UDIM>.exr"` will automatically be resolved to the correct UTIM tile based on the s,t coordinates.

http://lists.openimageio.org/pipermail/oiio-announce-openimageio.org/2016-October/000018.html

For support in OSL, it should only take an update to OpenImageIO 1.7 or newer:

We're been on OIIO 1.7.8 since early december

We're been on OIIO 1.7.8 since early december

Ah, my mistake. I was still using outdated binaries from https://svn.blender.org/svnroot/bf-blender/trunk/lib/darwin-9.x.universal.

Update: UDIM is now an option in the Image Node. Internally, they're still separated though.

OSL works now (as long as you're building with a recent OIIO). The V mirroring is a bit hacky, I'd prefer a better solution there.

I also looked into adding more options for the filename (<UDIM>, <U>, <V> etc. as used in OIIO), but the problem there is that the node currently expects an actual image, not some random filename string... So, for now I kept the search token as 1001 so you can just select the actual file.

As for the start tile and column count, it seems that they're indeed pretty much a fixed convention and OIIO has them hardcoded, so I removed the options.

Abandoned in favor of D2921.