Skip to content
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

[usdAbc] Pass Sdf arguments to Alembic plugin. #1099

Merged
merged 6 commits into from
Mar 20, 2020

Conversation

marsupial
Copy link
Contributor

Description of Change(s)

And adds two arguments to the reader:
abcReRoot Read the entire hierarchy in under a single parent held in argument's value
abcLayers Comma separated list of secondary files to load as a layered Alembic.

Fixes Issue(s)

  • <defaultPrim> is a bit cumbersome for Alembics prepared without any concept of it

@spiffmon
Copy link
Member

This sounds interesting, @marsupial, and will try to review soon. But up front, can I ask you to add new tests and test files for the new behaviors?

@marsupial
Copy link
Contributor Author

I knew that was coming, so yeah, on its way

@jilliene
Copy link

Filed as internal issue #USD-5822

@c64kernal c64kernal changed the base branch from master to dev February 5, 2020 18:35
Copy link
Member

@spiffmon spiffmon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, @marsupial ! There are a few changes we'd like to request - please let us know when it's ready for re-review?

Cheers,
--spiff

@@ -43,7 +44,7 @@ class UsdAbc_AlembicData : public SdfAbstractData {
/// Returns a new \c UsdAbc_AlembicData object. Outside a successful
/// \c Open() and \c Close() pairing, the data acts as if it contains
/// a pseudo-root prim spec at the absolute root path.
static UsdAbc_AlembicDataRefPtr New();
static UsdAbc_AlembicDataRefPtr New(const SdfFileFormat::FileFormatArguments* = nullptr);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It introduces a couple of layers of extra complexity to change the higher-level pattern of passing FileFormatArguments by const-ref to by pointer, and I'm curious why we'd want to do it? You're already paying for heap-allocating a copy of the std::map (which is generally going to be empty or very small), so why not eliminate all of that and the checks-for-nullptr, and just plumb the const-ref all the way down and let the member-var hold a copy?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No idea why I chose that initially other than a quick way to enable disable the custom behavior.
Easy enough to change.

pxr/usd/plugin/usdAbc/alembicReader.cpp Show resolved Hide resolved
const auto abcLayers = args->find("abcLayers");
if (abcLayers != args->end()) {
for (auto&& l : TfStringSplit(abcLayers->second, ",")) {
layeredABC.emplace_back(std::move(l));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know Alembic doesn't do any asset resolution, by-design... but would it not be valuable in the USD universe to attempt to anchor (to "filePath") and resolve each of these paths using the installed ArAssetResolver before passing the paths down to Alembic?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've looked into this, but it's currently a bit problematic on the Alembic side to pass layers as relative (particularly in a multi-threaded env). Second, there may be cases where the layer is in a totally separate location, unrelated to the -base layer-.

Or are you suggesting to call the resolver within usdAbc.so ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't suggesting that you pass relative paths to Alembic. Instead, use ArGetResolver().Resolve() (etc) to resolve the paths to full paths in USD-land before passing them on to Alembic.

But if that seems undesirable, then just please document in overview.dox that you must only supply full paths in the URI, which is a bit limiting for fancy resolver setups, but probably OK since this is for Alembic backwards compatibility.

Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah OK, then yes (i.e. this is currently already being done on the resolver side here), I'll add the note.

IArchive archive;
std::vector<std::string> layeredABC;
if (args) {
const auto abcLayers = args->find("abcLayers");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although you could, I won't ask you to add the string-literals for the arg-strings into alembicUtils.h as Tokens (both because you only use each once, and because, since this is a plugin, clients can't really use the header files anyways).

But, please do add a new section to overview.dox that both names the new args, and gives example authored asset paths that use them. And for bonus points, refer people to SdfLayer::CreateIdentifier() as a helper for building up such asset paths. That will show up here.

pxr/usd/plugin/usdAbc/alembicReader.cpp Show resolved Hide resolved
pxr/usd/plugin/usdAbc/alembicReader.cpp Show resolved Hide resolved
if (args) {
const auto reRoot = args->find("abcReRoot");
if (reRoot != args->end())
abcReRoot = TfToken(reRoot->second);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should verify TfIsValidIdentifier() on abcReRoot, and discard and warn if not.

@marsupial
Copy link
Contributor Author

Think I got to all the reviews minus the HDF5 threading issue, but if I missed any let me know

@pixar-oss pixar-oss merged commit d444e7d into PixarAnimationStudios:dev Mar 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants