Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Wrap::UDIM mode for proper UDIM filtering #4563

Open
etheory opened this issue Dec 15, 2024 · 1 comment
Open

Add Wrap::UDIM mode for proper UDIM filtering #4563

etheory opened this issue Dec 15, 2024 · 1 comment
Labels
feature request texture / image cache ImageCache, TextureSystem, maketx

Comments

@etheory
Copy link
Contributor

etheory commented Dec 15, 2024

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?

@etheory etheory assigned etheory and unassigned etheory Dec 15, 2024
@etheory etheory added texture / image cache ImageCache, TextureSystem, maketx feature request labels Dec 15, 2024
@lgritz
Copy link
Collaborator

lgritz commented Jan 3, 2025

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?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request texture / image cache ImageCache, TextureSystem, maketx
Projects
None yet
Development

No branches or pull requests

2 participants