Advice for a minimal UsdMaya PrimReader plugin failing to load on demand

[rlei-weta]

Hello,

I'm attempting to setup a minimal, custom UsdMaya PrimReader plugin by referencing the code & examples in the maya-usd repository.

After building and installing the new plugin, I tested the import of a simple USD file with the custom prim - the maya plugin does not seem to load on demand and the import fails (falls back to a empty transform).

However, if I load the plugin manually through the plug-in manager before importing the USD file, then the expected nodes/geo are created.

I was under the assumption that the mayaPlugin key value under PrimReader is for triggering maya to load the plugin on demand - but let me know if that's off target.

I can share the current setup for the plugin - it's fairly minimal... was hoping someone with more experience could see if there are any missing pieces.

The plugInfo.json for the plugin:

{
    "Plugins": [
      {
        "Info": {
          "UsdMaya": {
            "PrimReader": {
              "mayaPlugin": "wMayaUsdTranslators",
              "providesTranslator": [
                "WUsdExamplesTriangle"
              ]
            }
          }
        },
        "LibraryPath": "../../../wMayaUsdTranslators.so",
        "Name": "wMayaUsdTranslators",
        "Type": "library"
      }
    ]
}

There is an associated plugin.cpp for the maya plugin registration like thie one here:
https://github.com/Autodesk/maya-usd/blob/dev/lib/usd/translators/plugin.cpp

There is a triangleReader.cpp which is similar to lib/usd/translators/meshReader.cpp, except for the class name, what geometry it provides, and the registration bit:

...

TF_REGISTRY_FUNCTION_WITH_TAG(UsdMayaPrimReaderRegistry, WUsdExamplesTriangle) 
{
    UsdMayaPrimReaderRegistry::Register<WUsdExamplesTriangle>(
        [](const UsdMayaPrimReaderArgs& args) {
            return std::make_shared<WMayaUsdTriangleReader>(args);
        });
}

...

The installation structure, relative to the install root, looks as follows:

.
└── plugin
    ├── usd
    │   ├── plugInfo.json
    │   └── wMayaUsdTranslators
    │       └── resources                                                                                                                                   
    │           └── plugInfo.json                                                                                                                           
    └── wMayaUsdTranslators.so

The plugin/usd/plugInfo.json is used to include all descendent plugInfo(s).

The following env variables specific to this plugin are set-up for the runtime (linux):

PXR_PLUGINPATH_NAME=${PLUGIN_ROOT}/plugin/usd
MAYA_PLUG_IN_PATH=${PLUGIN_ROOT}/plugin

... currently looking to build maya-usd with debugging info to dig further - but in the meanwhile if anyone happens to spot any glaring errors - I'd be in your debt!

And to confirm, the type names inside the "providesTranslator" array (in plugInfo.json) should be the C++ schema class names of the prim, not the prim type name as you would encode for usdImaging prim adapters right?

Thanks for taking the time to read!

[JGamache-autodesk]

The type name is definitely the C++ name. Did you record a registry alias to help the PrimReaderRegistry discover the C++ name that corresponds to your USD primitive name? See for example the USD Skel primitives:
https://github.com/PixarAnimationStudios/USD/blob/release/pxr/usd/usdSkel/skeleton.cpp#L44

[rlei-weta]

Hi @JGamache-autodesk - thanks for the suggestion.

Yes the AddAlias registration is present - although I would guess it is the schema library plugInfo.json alias registration that would help PrimReaderRegistry discover the C++ name - given that the schema library would not yet have been loaded. (And yes the plugInfo.json alias reg is also present)

Once our debug build is available we're keen to have step through the registry code path to see what's going on - and hopefully report back some findings.

[rlei-weta]

... and just as the last reply was submitted, I had a look at our schema library's plugInfo.json and its C++ name included the full namespace of the class! (Our schema classes are generated under a custom namespace).

In the PrimReader plugin's plugInfo.json, replacing:

              "providesTranslator": [
                "WUsdExamplesTriangle"
              ]

with

              "providesTranslator": [
                "<custom namespace>::WUsdExamplesTriangle"
              ]

Has rectified the load on demand behavior. Thanks for pointing us in the right direction @JGamache-autodesk!