-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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 resolution broken for symlinks to non-UDIM paths #1329
Comments
Changing the paths also makes error messages hard for users to figure out. |
Filed as internal issue #USD-6351 |
I spent a little bit of time looking at this and I agree with you both. I've made a change internally that just removes the symlink processing, so the UDIM pattern matching is done on the authored paths and not the paths of the symlinked files. This should go out in the next push. Thanks! |
… resolution was removed, so was any testing for whether or not the "Resolve" call succeeded. This change restores the looping to look for an existing tile file rather than always returning the attempted resolution of the first tile file.
… resolution was removed, so was any testing for whether or not the "Resolve" call succeeded. This change restores the looping to look for an existing tile file rather than always returning the attempted resolution of the first tile file.
… resolution was removed, so was any testing for whether or not the "Resolve" call succeeded. This change restores the looping to look for an existing tile file rather than always returning the attempted resolution of the first tile file.
Description of Issue
New[ish] code to share UDIM textures when they are symlinks breaks down if they are symlinks to non-UDIM textures.
_ResolveAssetAttribute in pxr/usdImaging/materialParamUtils.cpp attempts to deduce the following:
This seems to allow sharing a common key for /symlink/a_.exr and /symlink/b_.exr, but will break down when the symlinks point to a file that is not a UDIM tile (i.e. /realpath/realfile_some_other_convention.exr)
It occurs to me that this may actually be fundamentally flawed and even the solution in #1330 may be insufficient, given that there could be two UDIM paths that resolve to the same first-tile, but diverge on subsequent tiles:
I think any resolution/transformation via symlinks in this case would make /realpath/realfile_1001.exr the key, for both a_<UDIM>.exr and b_<UDIM>.exr which would give incorrect results.
The text was updated successfully, but these errors were encountered: