search

PixarAnimationStudios / OpenUSD

Universal Scene Description
http://www.openusd.org
Other
6.04k stars 1.2k forks source link

UsdUtilsModifyAssetPaths does not work with Packages #3131

Open dgovil opened 3 months ago

dgovil commented 3 months ago

Description of Issue

UsdUtilsModifyAssetPaths used to work with Package paths and has stopped working as of https://github.com/PixarAnimationStudios/OpenUSD/commit/dc01ba9c2583d6a556b6b0d77c0d5268f9fcac96#diff-3e3b585ea87cd67809467f7cf6ee54a94b99109c10f92c87f117cff953233fc1.

For example, I use it to traverse a USD stage when loaded from a USDZ, and then proceed to modify the stage in place before writing a flattened version of the package elsewhere.

However as of the commit above, this now ends in a TF_CODING_ERROR with Unable to edit asset path in package layer. I believe this is not an intuitive result, as UsdUtilsModifyAssetPaths does not indicate its writing the changes back to the package on disk.

Should we consider a layer from a package truly unmodifiable ? I realize you cannot serialize back to the package, but it would still be useful I believe for processing utilities.

spiffmon commented 3 months ago

It would definitely violate the assumptions of some of the paths through that code to allow writing to a package-layer. With this and previous Issues you've been knocking at the door we've erected of packages being self-contained (in which case this code should never need to modify paths within one). But the only robust way to provide what you're asking for is to really do what the comment at the error-issuing site says, and add support for expanding and rebuilding packages, here, which is no small project ;-)

dgovil commented 3 months ago

Yeah, I can see it both ways. I guess one issue is that it's inconsistent today. I can go ahead and modify SDF data via the SDF api and be fine on packages, and even with many USD apis. But then every now and then something adds a check which blocks it.

Take for example someone wanting to load up a USDZ file in usdview or another viewer/editor. It feels natural to let them do some editing in there if we can say the app will handle all the repackaging for them. e.g we do this with Reality Converter and Preview. But if we say that all edits to the layers/stage are blocked if its package backed mean that you then have to extract the asset first without knowing if an edit will happen later.

jesschimein commented 3 months ago

Filed as internal issue #USD-9780

dgovil commented 3 months ago

And sorry, I should have clarified, I'm not opposed to being blocked on writing to a USDZ on disk. It's more that, when I load a layer backed by a USDZ, even if I intend to write it to a usda eventually, I get blocked on modifying the in memory layer because it happens to be backed by a usdz.

tcauchois commented 3 months ago

From discussion it sounds like the problem is not that we want to save layers back to USDZ, but rather that layers loaded from USDZ seem to be read-only even in memory. Is that intentional? Or is it a reasonable workflow to load a USDZ file with the knowledge that you can't save edits, but you can make edits as long as you take responsibility for figuring out how to serialize them later?