My goal: Rebuild the latest emHdBindings related files with the ThreeJsRenderDelegate from the Autodesk fork branch and have it display USD assets that have UsdPreviewSurface materials.
Current result: I’m able to build all of the files and display geometry information however I get the following error when trying to display assets with UsdPreviewSurface materials
Invalid info:id UsdPreviewSurface node: /RedMetalMaterial/UsdPreviewSurface : this comes from this line of code. The shaderReg at this point in the code only knows about light related identifiers (MeshLight , RectLight , VolumeLight , DomeLight_1 , PortalLight , DomeLight , DistantLight , CylinderLight , DiskLight , GeometryLight , SphereLight ). Why doesn’t this shaderReg know about UsdPreviewSurface nodes? How can I add that info / initialize the registry with that info?
ChatGPT’ing led me to believe that usdImaging is not being included in the build, but it does show up as ON when running the python build script listed on the github page.
Lastly there is another error that shows up around plugin management : USD/pxr/usd/ndr/registry.cpp -- Failed verification: ' pluginFactory '. This comes from this line. Is this related? Does support of UsdPreviewSurface materials need something from this pluginFactory?
Since UsdPreviewSurface materials show fine on my local normal build of USD, I assume I don’t need any special plugins or environment variables to include the support of UsdPreviewSurface materials in general, is it possible this is necessary for the web? Am I looking in a completely wrong place? Is this supposed to be supported / a known issue?
Thanks so much for any help! (Will cross post in #wg-usd-web)
I’m not familiar with the Emscripten stuff, but I can answer how USD shader registration generally works. Shaders are added to the registry by something called an NdrDiscoveryPlugin, which should look for node definitions/shaders in any relevant location, like a JSON file or some cloud database. These plugins are themselves registered to run their discovery code when the Sdr registry is initialized, which is where the plugin factory comes in.
As for how this relates to UsdPreviewSurface, the relevant discovery plugin and various shader definition files can be found here. This directory gets built as a standalone plugin, usdShaders, so one thing you can debug is seeing if this plugin was found and can be successfully loaded.
Beyond that, I’m not sure what else would be good to look into, particularly because there’s not a lot of debugging around why the factory would fail to be gotten. Something you can do for a bit more info is set the env var TF_DEBUG=NDR_DISCOVERY to confirm which NdrDiscoveryPlugin fails, though it’s likely just the UsdShadersDiscoveryPlugin.
Thanks @lbiasco! this gave me the context I needed to be able to dig further.
I used this info to discover where that discovery code was, but even after manually adding the path I needed, the plugInfo.json file was not found, they were not in my emscripten artifacts.
This turned out to be a CMakeLists.txt issue. UsdShaders needs to be added here and also here in order to produce the outputs needed. Basically I copied off of the existing CMakeLists.txt here, an older fork.
I can now see UsdPreviewSurface materials! Really appreciate the help!