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

UDIM higher than 1100 is broken in usdview #1846

Closed
zephchai opened this issue Apr 29, 2022 · 5 comments
Closed

UDIM higher than 1100 is broken in usdview #1846

zephchai opened this issue Apr 29, 2022 · 5 comments

Comments

@zephchai
Copy link

Description of Issue

Hi,

I found a problem when viewing an asset that has udim higher than 1100 in usdview.
broken_material

The usd version I am using is 21.11. It works fine if I shift the UV within 1100 so it looks like the texture is not being read if the udim is higher than 1100.

I have attached an example in the zip file to illustrate the problem.
udim_bug.zip

Steps to Reproduce

  1. Unzip the attached zip file to a folder
  2. Use usdview to open cube.usda
  3. Rotate the cube so that you are viewing the bottom. You should see that the material is broken.
  4. In the usda, there are 2 lines of st values with 1 commented out. One is working and the other is broken.

System Information (OS, Hardware)

Windows10, Kubuntu 18.04

Package Versions

USD 21.11 and earlier

Thanks

@zephchai
Copy link
Author

Looking at the code, I may have the found the cause.

I found this line in 2 files
static const int UDIM_END_TILE = 1100;

USD-21.11\pxr\imaging\hdSt\udimTextureObject.cpp:44
USD-21.11\pxr\usdImaging\usdImaging\materialParamUtils.cpp:56

Since UDIM supports up to 9999, ending at 1100 may seems limited. Although I also agree that it is not common for UDIM to go over 1100. Any thoughts?

Thanks,
Zeph

@spiffmon
Copy link
Member

Hi @zephchai ,
Yes, as you guessed in the usd-interest thread, this cap is set for performance reasons, since resolving assetPaths can expensive. Now for sure the codesites you found could be parallelized over the tiles, but there should already be per-prim multithreading, and it sould not change the total amount of required computation. Are there scenarios in which you actually have more tiles than our limit allows?

I would propose that the "fix" for this Issue be actually documenting the limit here (which I'm surprised isn't there already)?

--spiff

@zephchai
Copy link
Author

Hi @spiffmon,

Thanks for your reply. We do have assets going over the limit but I will let people in production know about this and hopefully they can work within the limit. And I agree this should be documented.

Thanks again. I will close this issue then.

@spiffmon
Copy link
Member

@zephchai , I'm reopening the issue because it explains the issue well, and it can serve as a task for us to do the documentation, and possibly the configurability that Colin E mentioned on usd-interest.

@spiffmon spiffmon reopened this Apr 30, 2022
@jilliene
Copy link

jilliene commented May 9, 2022

Filed as internal issue #USD-7356

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants