always register and de-register the PxrMayaHdImagingShape and its draw override

[mattyjams]

While the USD proxy shape classes included in the maya-usd repo all use either the (legacy) Pixar batch renderer or the Viewport 2.0 render delegate, there may be other custom node types that may or may not leverage USD but still want to take advantage of aggregated drawing using Hydra.

As an example, internally at Pixar we have a custom Maya shape node that is a severely stripped down approximation of a UsdGeomPointInstancer. This shape maintains its own data structures as a mix of USD and non-USD data, but it still uses the PxrMayaHdImagingShape and the Pixar batch renderer for drawing. I'm not sure whether other studios have custom shape nodes that leverage the Pixar batch renderer and its shape adapter system in this way, but it was definitely written with the intention of supporting that.

In our case, the eventual goal is that once we've fully transitioned to the Viewport 2.0 render delegate and UFE, we'll be authoring UsdGeomPointInstancer prims directly under a mayaUsdProxyShape and will no longer need this custom node type. As a result, we don't see value putting effort into making the custom shape work with the Viewport 2.0 render delegate. Instead, we're hoping that it can continue to use the Pixar batch renderer as we transition, and then we'll retire the shape once we've switched.

I don't think there should be any ill effects from always registering and de-registering PxrMayaHdImagingShape and its draw override. If no nodes are created in the scene that call PxrMayaHdImagingShape::GetOrCreateInstance() in their postConstructor() override, we shouldn't see any imaging nodes created and the Pixar batch renderer shouldn't get instantiated either.

[mattyjams]

To put it another way, right now enabling the Viewport 2.0 render delegate for USD proxy shape node types effectively disables the Pixar batch renderer for all shape node types, not just USD proxies. We'd like to still be able to use the batch renderer for non-proxy shape types to smooth the transition.

[huidong-chen]

I am not familiar with the PxrMayaHdImagingShape class. If we enable the congregated draw for this node type, will it introduce duplicated drawing for the same objects from both VP2RenderDelegate and the draw override you enable in this commit?

[mattyjams]

I am not familiar with the PxrMayaHdImagingShape class. If we enable the congregated draw for this node type, will it introduce duplicated drawing for the same objects from both VP2RenderDelegate and the draw override you enable in this commit?

@HdC-adsk: Good question. No, we should be ok there. We effectively have two layers of protection against that.

The proxy shape classes guard against even creating an instance of the PxrMayaHdImagingShape when we're using the Viewport 2.0 render delegate:

maya-usd/plugin/adsk/plugin/ProxyShape.cpp

Line 64 in 29b37a6

if (!MayaUsdProxyShapePlugin::useVP2_NativeUSD_Rendering())

maya-usd/plugin/pxr/maya/lib/usdMaya/proxyShape.cpp

Line 318 in 9090482

if (!MayaUsdProxyShapePlugin::useVP2_NativeUSD_Rendering())

So if none of these custom node types are in play, we really shouldn't end up with a PxrMayaHdImagingShape node in the scene when the Viewport 2.0 render delegate is enabled.

Even if we do have a PxrMayaHdImagingShape node in the scene, we're still not registering the legacy Pixar batch renderer UsdMayaProxyDrawOverride for proxy shapes when the Viewport 2.0 render delegate is enabled, so no proxy shape rprims would get populated in the batch renderer, and there would be nothing for it to draw.

[huidong-chen]

No worry about the preflight build errors. They are relevant to a new API class we recently added and will fix it soon.