Add Wrap::UDIM mode for proper UDIM filtering

[etheory]

Currently, the wrap modes for textures are (https://openimageio.readthedocs.io/en/latest/texturesys.html):

• Wrap::Black
• Wrap::Clamp
• Wrap::Periodic
• Wrap::Mirror
• Wrap::Default

But when using UDIM textures, what you really want, is filtering across UDIM seams, else, at low mip map levels, you get strange artifacts at UDIM edges.
So I would like to propose a new Wrap mode called Wrap::UDIM that implements such filtering.

I also propose to update maketx to support this new mode somehow (new command line argument?), such that during the mip-map generation, it also performs this cross-UDIM tile filtering also.

What do people think?

I further propose that "Wrap::Default" use "Wrap::UDIM" when passed one of the UDIM-specific path types.

If you think this is a good idea, are you OK with me going ahead and proposing an implementation and making a PR?

@lgritz? Thanks.

Does this already exist and I'm missing it?

[lgritz]

Is that what people really want? I always thought of UDIM as more like a "texture atlas" where different connected parts of an object were on different UDIM texture components (that's what I'm calling them because there is apparently no official name and "tiles" is really confusing), and honestly it never occurred to me that people would want to filter across the seams and the edges of the individual file components.

Maybe I'm wrong about that? Would be interesting to hear from others what the expectations are across different apps and different studios as to what geometric connectivity is expected at the seams. Is Animal just weird, or is my place? Do users of UDIMs expect a single geometric component to span a seam?

If it's me who's wrong, then we should definitely implement something like this. Though I'm expecting that it's going to be a bit complex and not cheap, since crossing a seam boundary is a step beyond just needing potentially another tile -- it could be involving another file on disk entirely. (It raises questions, too: at the left, right, top, and bottom-most edge seams, what is the right behavior? Can the whole UDIM set itself be "periodic" and wrap all the way around? Does blending across seams imply that all of the UDIM file components must be identical resolution?)

[etheory]

It's definitely what our artists expect. They say that PRMan does this, but honestly, I don't think it does. But I could be wrong.

Here is what they are trying to do.

They are writing a parallax shader. That shader steps in UV space along a ray projected in UV-space. The object they are using it on it constructed from multiple UDIMs and they note that there are edge artifacts in the render.

This is obviously due to 2 things:

1.) maketx does not filter across multiple UDIMs, and their expectation is that it should.
2.) there is no wrap mode to allow cross-UDIM filter at runtime, which they are expecting to get rid of these seams.

I am also curious if others could comment and if anyone else uses another renderer that does the above automatically (I doubt there is).

One annoying obvious complication is that re-baking a texture would imply re-baking other textures surrounding it to get the right result, which whilst not impossible, would be a challenge to get working accurately.

[etheory]

OK after an internal discussion we realized something.

Since we do stochastic single-sample filtering in glimpse, we really ONLY need to update maketx to filter the mip-maps across the UDIMs.

So I'm going to do a test where I make a tool that's based on maketx to do this, and see if it resolves the issue. Since for single-sample filtering, we shouldn't need to change the runtime code at all. The sample is either in the next UDIM, or it isn't, and the runtime code SHOULD do the right thing in that case.

If that fixes our use-case, I can make a PR and see if other people are interested in it. Is that OK @lgritz?

Where things get REALLY hairy is that our artists often use the UDIM specified names, as well as reference individual tiles in the same render or even sometimes the same shader. This is where things start to feel like the colour-space discussion, where you'd actually need to generate BOTH sets of filtered tiles, and choose the correct set at runtime based on the wrap mode. Since the general user-expectation is that one invocation of maketx works for all wrap modes. In this case, it wouldn't.

Also, for UDIM's when you generate a cross-UDIM texture with maketx, it'd need to be tagged such that at runtime the "Default" wrap mode was "UDIM" in order to work as people expect it to. Another thing to consider.

On second thoughts, doesn't this also mean that maketx is inherently broken since it doesn't consider the wrap mode properly?

[lgritz]

I'm not quite sure I understand the terminology, or if you're just mixing terms around. You keep saying 'maketx' but do you really just mean the TS? Is it really the case that you can only make the MIP-maps for each udim piece if you have all the other pieces ready? So, like, even within one "piece", you want the lower MIP levels to be derived by filters that pull in bits of adjacent pieces?

Or does each piece maketx as usual on its own, but the TS knows that there's a new wrap mode you can optionally use for the texture call (or the texture set?) that makes a texture lookup know that it might run off the edge and onto a different udim section piece?

For the TS / texture lookup piece: I definitely would welcome an additional MIP mode to filter across UDIM piece boundaries, as long as it's optional (I'm not at all sure that is the usual case people want, but I can totally imagine that you and maybe other places do want it, at least in some cases).

I'm less convinced about some kind of super maketx mode where it really does make the MIPmaps for the whole UDIM set simultaneously... but if it's not too hard to pull off, I guess why not allow it?

[etheory]

You need to both generate the textures on disc (maketx) with knowledge of their neighbours AND know about neighbours at runtime (TS) to make it work properly, I believe.

[etheory]

OK cool, sounds like you basically agree. I'll whip something up, make a PR, and then people can rip me to shreds there. Thanks @lgritz!