Per MObject PrimWriter customization

[BeardedPlatypus]

Hi all,

First of all, thank you for all the improvements over the past months It's been great to be able to retrieve a better prim to dag map in the ImportChasers! I am currently looking into overriding PrimWriter and PrimReader implementations in specific cases.

Is your feature request related to a problem? Please describe.

Given a scene that looks something along the lines of this

• Character (Transform): Root transform
  • Geometry (Transform): Container for geometry objects
    • Character_Body_LOD0
    • Character_Body_LOD1
    • Character_Helmet_LOD0
    • Character_Outfit_LOD0
  • Skeletons (Transform): Container for skeleton objects
    • DisplacementRig: Skeleton hierarchy to which the lods are bound
    • ControlRig: Skeleton hierarchy which has the animator controls

I would want to export the Geometry and Skeletons as UsdGeom.Scope prims. These are only there for artists to organize their scenes, and we do not care about their transform data. As such a scope seems to be a fitting prim.

In order to do this, I want to call a custom PrimWriter for these specific MObject instances, but utilize the default PrimWriter for other MObject transform nodes. This custom PrimWriter would write a scope instead rather than a XForm or SkelRoot, which would solve our issue.

While it is possible to register a custom PrimWriter for transforms, it seems like I am only able to override the complete behavior for all transform prims, rather than provide a more specific implementation under specific conditions. The CanExport (see additional context) is only called once per export, and if ContextSupport.Supported is returned, it will be used for all transform nodes. Thus I cannot rely on the default implementation anymore.

This in itself would be less of a problem, if I could access the default behavior inside my PrimWriter and reuse it (or inherit from the default PrimWriter and extend it with my own implementation). However none of these classes seem available in python.

Describe the solution you'd like

I want to be able to register my own PrimWriter (and PrimReader) which would have a CanHandle method (or similar) which would be called per input object (MObject or Prim). If CanHandle returns falls, False, the fallback/default reader/writer should be used.

Describe alternatives you've considered

Alternatively, I would have to re-implement the default behavior completely in my own PrimWriter class, or I would need to perform some hack-ish behavior in a Chaser to achieve a similar result.

Additional context

An example implementation of how I expected the PrimWriter to function:

class ScopeWriter(mayaUsdLib.PrimWriter):
    def __init__(self, *args, **kwargs):
        super(ScopeWriter, self).__init__(*args, **kwargs)

        if not self.GetDagPath().isValid():
            return

        scope = UsdGeom.Scope.Define(self.GetUsdStage(), self.GetUsdPath())
        if scope is None:
            return

        prim = scope.GetPrim()

        if prim is None:
            return

        self._SetUsdPrim(prim)

    @classmethod
    def CanExport(cls, exportArgs, exportObj=None):
        if exportObj is None or not exportObj.hasFn(api.MFn.kDagNode):
            return mayaUsdLib.PrimWriter.ContextSupport.Unsupported

        dag_node = api.MFnDagNode(exportObj)

        if dag_node.parent(0).hasFn(api.MFn.kWorld):
            return mayaUsdLib.PrimWriter.ContextSupport.Unsupported
        return mayaUsdLib.PrimWriter.ContextSupport.Supported

Where CanExport was expected to run for each object that is encountered, rather than per full export.
This was based on the code found in the PrimWriter tests

[wallworm]

Thanks for the kind comments. As for the request, I will talk to team. My understanding is that the methods are already called per object as I've written them like that in 3ds Max, and we built the Max USD implementation based on the Maya implementation. I will bring this up with the devs and clarify.

[wallworm]

It turns out that we are missing something on the Python side. We're looking into this now.