Override the Default Camera Writer

[NickWu]

Hi,

We have a need in our pipeline to export a Maya native camera to our custom schema camera prim. Currently, the prim writer register mapping for Maya native cameras is taken by PxrUsdTranslators_CameraWriter and is mapped to USD's default camera prim UsdGeomCamera. With the current design of PXRUSDMAYA_REGISTER_WRITER and PXRUSDMAYA_REGISTER_ADAPTOR_SCHEMA, I couldn't find a way to override PxrUsdTranslators_CameraWriter with another writer. Hence, I have come up with an approach to allow an existing register to be overwritten.

Firstly, I'd a new parameter canOverride to UsdMayaPrimWriterRegistry::Register and extend its functionality so that it becomes:

primWriterRegistry.h

static void Register(const std::string& mayaType, WriterFactoryFn fn, bool fromPython = false, bool canOverride = false);

primWriterRegistry.cpp

void UsdMayaPrimWriterRegistry::Register(
    const std::string&                         mayaTypeName,
    UsdMayaPrimWriterRegistry::WriterFactoryFn fn,
    bool                                       fromPython,
    bool                                       canOverride)
{
    TF_DEBUG(PXRUSDMAYA_REGISTRY)
        .Msg("Registering UsdMayaPrimWriter for maya type %s.\n", mayaTypeName.c_str());

    std::pair<_Registry::iterator, bool> insertStatus
        = _reg.insert(std::make_pair(mayaTypeName, fn));
    if (insertStatus.second) {
        UsdMaya_RegistryHelper::AddUnloader(
            [mayaTypeName]() { _reg.erase(mayaTypeName); }, fromPython);
    } else {
        if (canOverride) {
            _reg[mayaTypeName] = fn;
            TF_STATUS("%s has been registed already. We will replace it with the new registeration.", mayaTypeName.c_str());
        } else {
            TF_WARN("Multiple writers for type %s", mayaTypeName.c_str());
        }
    }
}

Then, I'd add a new macro in primWriterRegistry.h:

primWriterRegistry.h

#define PXRUSDMAYA_REGISTER_WRITER_OVERRIDE(mayaTypeName, writerClass)                     \
    TF_REGISTRY_FUNCTION_WITH_TAG(UsdMayaPrimWriterRegistry, mayaTypeName##_##writerClass) \
    {                                                                                      \
        UsdMayaPrimWriterRegistry::Register(                                    \
            #mayaTypeName,                                                                 \
            [](const MFnDependencyNode& depNodeFn,                                         \
               const SdfPath&           usdPath,                                           \
               UsdMayaWriteJobContext&  jobCtx) {                                           \
                return std::make_shared<writerClass>(depNodeFn, usdPath, jobCtx);  },             \
           false,                                                                           \
           true                                                                             \
    );                                                                            \
    }

Similarly, I'd also add a canOverride parameter to RegisterTypedSchemaConversion and extend its functionality so that it becomes:

adaptor.h

static void RegisterTypedSchemaConversion(
        const std::string& nodeTypeName,
        const TfType&      usdType,
        bool               fromPython = false,
        bool               canOverride = false);

adaptor.cpp

void UsdMayaAdaptor::RegisterTypedSchemaConversion(
    const std::string& nodeTypeName,
    const TfType&      usdType,
    bool               fromPython,
    bool               canOverride)
{
    const auto iterAndInserted = _schemaLookup.insert(std::make_pair(nodeTypeName, usdType));
    if (iterAndInserted.second) {
        UsdMaya_RegistryHelper::AddUnloader(
            [nodeTypeName]() { _schemaLookup.erase(nodeTypeName); }, fromPython);
    } else {
      if (canOverride) {
            _schemaLookup[nodeTypeName] = usdType;
            TF_STATUS(
                "Typed schema conversion %s has been registed already. We will replace it with the new registeration.", 
                nodeTypeName.c_str());
        } else {
            TF_WARN(
                "Typed schema conversion already registered for Maya "
                "type %s",
                nodeTypeName.c_str());
        }
    }
}

Then, I'd add a new macro in adaptor.h:
adaptor.h

#define PXRUSDMAYA_REGISTER_ADAPTOR_SCHEMA_OVERRIDE(mayaTypeName, schemaType)                              \
    TF_REGISTRY_FUNCTION(UsdMayaAdaptor)                                                                    \
    {                                                                                                       \
        UsdMayaAdaptor::RegisterTypedSchemaConversion(#mayaTypeName, TfType::Find<schemaType>(), false, true); \
    }

With all that, I can use the new macros to register my custom camera writer against maya native cameras to override PxrUsdTranslators_CameraWriter like so:

PXRUSDMAYA_REGISTER_WRITER_OVERRIDE(camera, PxrUsdTranslators_CustomUSDCameraWriter);
PXRUSDMAYA_REGISTER_ADAPTOR_SCHEMA_OVERRIDE(camera, CustomUSDCamera);

What do you think? Or you have other recommended ways of overriding the default camera writer? Thank you.

[neilh-adsk]

I like the idea of this, I was thinking that t could be extended, by allowing a JobContext to supply a list of overrides. As a thing pair like {"mesh", "NeilsMeshWriter"} { "camera",NeilsCameraWriter"} etc.. The topic of overriding the built in readers/writers is very timely but I wonder if the system "Could" or "should" allow multiple readers/writers to be registered. As a first step, I like this direction just purely thinking larger scale and whether it could be extended to a larger solution, or if that is even needed.

[NickWu]

For us at AL, it's needed to export from Maya via our custom writer. I imagine this could provide great extensibility as well for others. You mentioned this could be implemented via a JobContext. Is the work already in progress or still in conversations?

[neilh-adsk]

ITs still in conversation but I am interested in your thoughts about this direction

[NickWu]

I like the idea of JobContext's approach because it'd allow overriding a reader or writer at runtime via job context args which could provide more flexibility in our pipeline.

[deboisj]

What we have done in 3dsMax to enable overriding "base" writers, is this (and for this we were inspired by the mayaUsd shader writers) :

• Writers must implement a CanExport() function and can return "Supported", "Fallback" or "Unsupported" - the function also receives the object to export as input, and export options.
• All the base writer that ship with MaxUsd are specified as "Fallback" writers.
• Any third party that wants to override a base writer can just return "Supported" for an object. Writers with "explicit" support, take precedence over fallback writers.

Note that this does not solve the cases where multiple third parties register "Supported" writers for the same objects.. in this case the first one wins...

Perhaps a similar approach could be used here.

[NickWu]

Thank you for sharing the idea. This could be another direction to go.

[samuelliu-adsk]

I'm currently working on overriding for readers with the design as @deboisj mentioned above, and will apply the same mechanism to writers as well.

[NickWu]

That's good to hear! Any idea when this feature will be released here?

[neilh-adsk]

watch out for the pull requests :-)

[neilh-adsk]

There are many options, but the issue still comes down to "Supported" option which is why I personally like the JobContext route, but interested if there are any other opinions about this.

[csyshing]

Hi @neilh-adsk , for the reference AL's translator system has a method canBeOverridden() for derived translator (reader or writer) to override built-in / fallback translators:
https://github.com/Autodesk/maya-usd/blob/dev/plugin/al/lib/AL_USDMaya/AL/usdmaya/fileio/translators/TranslatorBase.h#LL217C53-L217C53
I guess this is similar as 3dsMax's solution that @deboisj was mentioning?

by allowing a JobContext to supply a list of overrides. As a thing pair like {"mesh", "NeilsMeshWriter"} { "camera",NeilsCameraWriter"} etc..

I like the idea to use JobContext to specify overrides, I believe this approach could give the production pipeline a better and greater flexibility to decide when and how to override at runtime, for example, it will then become possible to import/export two different meshes (or same mesh) with two different readers/writers for different purposes in one single pipeline step.

but I wonder if the system "Could" or "should" allow multiple readers/writers to be registered

I think if using JobContext, we have to allow multiple readers/writers to be registered, otherwise it would not be possible to specify at runtime unless we change the registration logic to be lazy finding and loading readers/writers, isn't it?

In reality, there will be one to one mapping between Maya geometry type and USD prim type, thus there will be only one "active" reader/writer in use even if we had multiple readers/writers in registration list.

There might be other workflows that I am not aware of, happy to discuss for other possibilities!