When building USD with MaterialX my current understanding is the plugin looks for the standard library in the following locations:
The locations pointed out by: PXR_MTLX_PLUGIN_SEARCH_PATHS
The locations pointed out by the environment variable: PXR_MTLX_STDLIB_SEARCH_PATHS
The locations fed in by the compile time defined value of PXR_MATERIALX_STDLIB_DIR
What they all have in common is that they are (as far as I understand them) absolute locations that needs to be specified either by the system or at compile time. In order to build an application using USD I’d prefer to look up these things relative to the install location in some form.
My instinct would be to store and install the MaterialX library as resources in the UsdMtlx plugin resource directory and use that as the fallback location if everything else fails to make sure any valid build of usd relocated or not has the standard library available.
What are your thoughts on this topic? I get the feeling the current setup is very one environment for everyone oriented and not very application oriented. Also, please challenge my assumptions, is there a way of loading the materialx libraries from a location relative to the installed application. I am aware it’s possible to set the environment variables inside the process to work around this but I’d rather avoid that solution unless I have to.
I might misunderstand, but we have had issues with something like this for usd itself as well, where you need to set the PXR_PLUGINPATH_NAME. I’d love all these libraries to have a fallback to some location relative to the application, so you could theoretically install without any env vars.
That is what I want to get to too. In its condensed form:
If I want to build a relocatable usd application with the materialx plugin, how do I distribute the materialx libraries properly?
As an extreme example, imagine distributing usd with the materialx plugin as a python pip package and make it work without the user having to make additional API calls.
The only way I could get it to work today as far as I understand it would be to somehow hack an init.py somewhere to sneak in some data into the environment since I don’t have control over the python interpreter which would be analogous to where I would do that myself if building my own application.