[draft] [USDU-370] First pass at adding relative path to UsdAsset. #376
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose of this PR
Ticket/Jira #: [USDU-370]
When Unity project directories are moved or shared, the full path that is serialized for an imported asset causes lots of errors due to the path being different. This change attempts to, where possible, save only the relative path inside the Unity project folder, but still fallback to the full path when it's not in the project folder. We then also catch cases more cleanly when they don't exist at the stated path. This awkward code is necessary to not break existing projects when upgrading, and still support importing USD files from outside the project folder.
We could alternatively have a one time fix up style approach that happens on domain reload or something, but this seemed the simplest approach that should catch if the user fixes a missing file.
This version will be non backwards compatible, because the UsdAsset is 'fixed' to contain a m_relativeUsdPath, and this new field doesn't exist on older versions of the package. As many users have had too many issues with 3.0.0-exp.2 that 3.0.0-exp.3 should solve, this shouldn't be too common. However I think we should fully discuss this before landing.
Testing
Functional Testing status:
TBC
Performance Testing status:
TBC
We are adding potential overhead to a getter which is certainly undesirable, however in the majority of cases it should fallback to the same cost as before- a single call to Path.GetFullPath().
Overall Product Risks
Complexity: Low
Halo Effect: Medium
Additional information
Note to reviewers:
Reminder: