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

loading FileResolver with pxr #3

Open
Viewgob opened this issue Sep 6, 2023 · 3 comments
Open

loading FileResolver with pxr #3

Viewgob opened this issue Sep 6, 2023 · 3 comments
Assignees

Comments

@Viewgob
Copy link

Viewgob commented Sep 6, 2023

Hello! This isn't really an issue with the plug-in but more of a question about best practices when loading it. Is there a recommended way of importing the FileResolver python module so that it's available any time usd is loaded. For example, I have the FileResolver loaded through the PXR_PLUGINPATH_NAME in usdview, but if I print out the contexts, I get an error because a python representation hasn't been created yet for the FileResolverContext:

st.GetPathResolverContext()
Traceback (most recent call last):
File "", line 1, in
TypeError: No to_python (by-value) converter found for C++ type: FileResolverContext

after running:

from usdAssetResolver import FileResolver

it works fine:
st.GetPathResolverContext()
Ar.ResolverContext(FileResolver.ResolverContext('/assetResolverTest/test.usda'))

Do I need to go to each dcc (houdini/maya/usdview/etc) and add that import statement to it initialization or is there a better way?

Thank you!

@LucaScheller
Copy link
Owner

LucaScheller commented Sep 6, 2023

Hey, thanks for checking out the repo!

Good question! I'm actually not too familiar with how C++ Python bindings work under the hood, so I can't give you an answer as to if there is a way to auto import it.

I'd recommend asking the same question in the USD forum, maybe someone there can give more insights how USD loads the plugins (or if this is just a general Python binding issue or if maybe some setup code is just missing).

In our production code, we always just import the class somewhere ourselves (in startup scripts or the module that handles resolver related stuff).

-Luca

EDIT: Closing issue for now, please re-open if necessary :)

@LucaScheller LucaScheller self-assigned this Sep 20, 2023
@LucaScheller LucaScheller closed this as not planned Won't fix, can't repro, duplicate, stale Oct 3, 2023
@LucaScheller
Copy link
Owner

LucaScheller commented Oct 31, 2023

Hey, I'm actually running into this issue again too currently with the "CachedResolver" implementation.
I'm doing the following:
cachedResolver.so invokes PythonExpose.py with the active CachedResolverContext, but since the Python representation hasn't been loaded yet it errors, unless it was imported before (as you mentioned above).

Workarounds for now are:

  • Set the "LD_PRELOAD" to the the python lib .so file. That way it is force loaded, this seems very hacky though
  • Import the module in startup scripts, like pythonrc.py in Houdini. It standalone python scripts we don't have an error because we import the module first.
  • Compile the cachedResolver .so with the Python bindings. This means both .so files (resolver.so and pythonBindings.so ) will have duplicate content, I'll go with this solution for now, if anyone knows are better approach, please let me know :)

Re-opening this ticket to re-investigate this some point in the future

@LucaScheller LucaScheller reopened this Oct 31, 2023
@Viewgob
Copy link
Author

Viewgob commented Oct 31, 2023

Thank you for your continued support of the plugin!

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

No branches or pull requests

2 participants