Explicitly case Ar path string to ArResolvedPath #1261
Conversation
This was throwing errors when built against the latest version of USD. File path strings are explicitly cast elsewhere in the USD code, updating this one to follow suit.
This throws an error when built against the latest USD. File path strings are being explicitly cast to ArResolvedPath objects when passed to ArResolver::OpenAsset elsewhere. Updating this call to follow this pattern.
|
FYI @ysiewappl |
JGamache-autodesk
added
the
ready-for-merge
kxl-adsk
removed
the
ready-for-merge
| @@ -266,7 +266,7 @@ bool PxrMayaUsdUVTexture_Reader::Read(UsdMayaPrimReaderContext* context) | |||
| && !filePath.empty() && ArIsPackageRelativePath(filePath)) { | |||
| // NOTE: (yliangsiew) Package-relatve path means that we are inside of a USDZ file. | |||
| ArResolver& arResolver = ArGetResolver(); // NOTE: (yliangsiew) This is cached. | |||
| std::shared_ptr<ArAsset> assetPtr = arResolver.OpenAsset(filePath); | |||
| std::shared_ptr<ArAsset> assetPtr = arResolver.OpenAsset(ArResolvedPath(filePath)); | |||
There was a problem hiding this comment.
@dj-mcg Please check PF results - https://github.com/Autodesk/maya-usd/pull/1261/checks?check_run_id=2125284262. Looks like this wasn't existing in USD 20.11. We currently support USD versions down to 20.02.
There was a problem hiding this comment.
Thanks @kxl-adsk - put in a PXR_VERSION check and running preflight now
ArResolver::OpenAsset takes an ArResolvedPath in versions after 20.11. Add a version check when calling this function and passing an std::string and explicitly cast to an ArResolvedPath instead.
|
We had some slow network issues...that slowed down the PF enough to cause the timeout on GitHub Action side. The internal job (job/ecg-mayausd-branch-preflight-master-public/1128/) finished with success. No need to re-trigger the PF. |
kxl-adsk
added
the
ready-for-merge
|
Sorry, something was bugging me and I just double-checked with @dgovil: I am already building against USD 21.02 here and the code builds fine without this check. From what I can see: https://graphics.pixar.com/usd/docs/668045551.html#AssetResolution(Ar)2.0-RolloutandTransition
Should the macro be changed to check against this instead rather than the USD version itself, assuming people want to use the old resolver and haven't built their libUSD with this flag enabled? |
|
I'm not sure about the connection to Ar 2.0 here. We are internally building without Ar 2.0 which means PF is validating against an artifact that doesn't have it. The problem was that this change originally only worked for USD 21.02 and above. It was not compiling with older versions (like 20.11 down to 20.02). Based on that, why should the check be changed? |
Passing a path string to ArResolver::OpenAsset throws an error when built against the latest version of USD. This parameter is explicitly cast to ArResolvedPath elsewhere in the USD code, so updating this callsite to follow that pattern.