File type is chosen from the path, rather than the resolved path

[sirpalee]

Description of Issue

When loading a file, the file type is chosen using the original file path, instead of the resolved path. This is causing issues when there is a custom ArResolver in use, and the original path doesn't end up in an extension that USD knows how to handle.

The problem comes from SdfLayer::FindOrOpen, where the _ComputeInfoToFindOrOpenLayer is called before the path is resolved, so it only has access to the original path.

A better approach could be to first resolve the path, if the layerPath is not anonymous, then setup the layerInfo using the resolved path.

Steps to Reproduce

1. Load up a custom resolver that generates a usda file, but the source path doesn't end with .usda.
2. For example this proof of concept resolver: https://github.com/LumaPictures/luma_usd/blob/master/uberResolver/resolver.cpp
3. Use this usda file.

#usda 1.0

over "ReferencedStuff" (
    add references = @sphere://hello@
)
{
}

System Information (OS, Hardware)

Doesn't matter.

Package Versions

ce52132

Build Flags

Doesn't matter.

[jtran56]

Filed as internal issue #141641.

[frenchdog]

A solution is to implement the resolver virtual function std::string GetExtension(const std::string& path) in your resolver.

// Example returning extension from a path looking like that:
// "@<asset>/<version>/<asset>.usda?asset=foo,version=v001@"
std::string RdoResolver::GetExtension(const std::string& path)
{
    auto mainTokens = TfStringSplit(path, "?");
    if (mainTokens.size() < 2)
    {
        return TfGetExtension(path);
    }

    auto pathTemplate = mainTokens[0];
    auto tokens = TfStringSplit(pathTemplate, ".");
    if(tokens.size() < 2)
    {
        return TfGetExtension(path);
    }

    return tokens.back();
}