Although the CachedResolver was detected, ArGetResolver did not use the CachedResolver. houdini 20.5.278 +py3.10

[ACE199704]

ArGetResolver(): Found primary asset resolver types: [CachedResolver, ArDefaultResolver]
**ArGetResolver(): Using default asset resolver ArDefaultResolver for primary resolver**
ArGetResolver(): Found URI resolver ArDefaultResolver
ArGetResolver(): Found URI resolver CachedResolver
ArGetResolver(): Found URI resolver FS_ArResolver
ArGetResolver(): Using FS_ArResolver for URI scheme(s) ["op", "opdef", "oplib", "opdatablock"]
ArGetResolver(): Found package resolver Usd_UsdzResolver
ArGetResolver(): Using package resolver Usd_UsdzResolver for usdz from plugin usd
ArGetResolver(): Found package resolver USD_NcPackageResolver
ArGetResolver(): Using package resolver USD_NcPackageResolver for usdlc from plugin usdNc
ArGetResolver(): Using package resolver USD_NcPackageResolver for usdnc from plugin usdNc

Although the CachedResolver was detected, ArGetResolver did not use the CachedResolver. How do I set up ArGetResolver? Ths~

[LucaScheller]

Hey, could you share some more info on how you are launching Houdini?

[ACE199704]

Hey, could you share some more info on how you are launching Houdini?

Sure, Firstly, I installed CachedResolver by code:

import ssl; from urllib import request
update_manager_url = 'https://raw.githubusercontent.com/LucaScheller/VFX-UsdAssetResolver/main/tools/update_manager.py?token=$(date+%s)'
exec(request.urlopen(update_manager_url,context=ssl._create_unverified_context()).read(), globals(), locals())
run_dcc()

Then, I launch Houdini by downloaded bat file.

Result:

[LucaScheller]

Hey, I'll try verifying this on my end. Can you try loading it without any Houdini plugins in the meantime (No Anrold, Vray, etc.)?

[ACE199704]

Hey, I'll try verifying this on my end. Can you try loading it without any Houdini plugins in the meantime (No Anrold, Vray, etc.)?

Thank you for your reply. I removed the Htoa plugin, the result is still the same

[LucaScheller]

It looks like the GitHub built version is linking against the wrong python version. The py3.11 build seems to work. If I build it locally, I don't get the problem. I'll have to do some debugging.

[LucaScheller]

Found the issue in the build pipeline, I'll look into fixing it.

[ACE199704]

Found the issue in the build pipeline, I'll look into fixing it.

Thanks a lot!!!

[LucaScheller]

Should be fixed in release 0.7.2, thanks for the bug report!

[ACE199704]

Should be fixed in release 0.7.2, thanks for the bug report!

It works, Thanks a lot!! : )

[Xelt]

0.7.2 or 0.7.3 Same issue on linux here Seems to work well on Windows

ArGetResolver(): Found primary asset resolver types: [CachedResolver, ArDefaultResolver] ArGetResolver(): Using default asset resolver ArDefaultResolver for primary resolver

[LucaScheller]

Can you test if the 0.7.3 release works with Houdini 20.5.332?

[Xelt]

Tested 0.7.3 with 20.5.332 py310 and have the same result

[LucaScheller]

The CICD was fine, the update manager was just pulling the wrong python version ;) Should be fixed now, thanks for the report!

[Xelt]

Ok, I was not using the update manger, but directly using the build and setting environments. The update manager is pulling the same version I'm using and it's still using ArDefaultResolver for primary resolver.

[LucaScheller]

Can you try running:

from pxr import Ar
from usdAssetResolver import CachedResolver

The error message should hopefully then tell us what is failing.

[Xelt]

ImportError: /lib64/libc.so.6: version `GLIBC_2.32' not found H20.5.332 gcc9 on centos 7.9.2009 (glibc 2.17) H20.5.332 gcc11 on Roccky Linux 8.9 (glibc 2.28) We may need to re-compile or upgrade os with glibc 2.32? glibc is version 2.34 for Rocky Linux 9

[LucaScheller]

That would probably fix it it or can you try compiling it yourself? (On Linux it should be pretty straightforward, it should be enough to set the correct Houdini version in the setup.sh file and then run build.sh (both files are in the root of this repo).

Turning off shared libs in the CICD might also fix, let me try that, I'll let you know when the build is done.

[Xelt]

Ok, I did my own build on rocky linux 8.9 with docker. Seems to work. We are migrating all our stations to this build so I think it will fit our needs for now. Thanks a lot for your time by the way, I could have done this before. Maybe releasing the builds without shared libs would be good too.

[LucaScheller]

Great :) I looked into the static lib building, this doesn't work though, as the boost/python linking requires dynamic libs. So unfortunately you'll have to stick with building it your self, sorry! Out of curiosity, are you using the resolver for a private project or at a company (if yes, what company, if you don't mind sharing)?

[Xelt]

Sure, I work at Hybride. We establish a good production workflow in Houdini in obj/sop with our own builder system, it's now stable and we are starting to look more at USD / Solaris / Maya workflow (it's a year or two we say that, but hey...) and see what will be our future on this side. I'm actually simply doing a simple path remap win/linux in python with the cacheResolver to give assets to test with different departments and work step by step what's the outcomes. We will probably see for other resolving kind and c++ in the future but I think it's enough to get us started for now.

[LucaScheller]

Cool, great to hear that this repo is actually being used for RnD/production :) I'll keep this issue closed for now. I did some more reading on if python/boost can be built statically (in theory yes), but I wasn't able to get it working quickly. LibC is also usually backwards compatible only, so since I am just using the standard GitHub runners (which don't match the VFX reference platform), this case might happen here and there. The only way around it would be to dockerize and build against the vfxrp, which is a bit out of the scope of this project. Thanks for understanding!