Unused primvar filtering not recomputed when material is edited

[nvmkuruc]

Description of Issue

Consider the following scene containing a Sphere with two primvars and a Material driving color via primvar.

#usda 1.0

def Sphere "MySphere" (append apiSchemas = ["MaterialBindingAPI", "PrimvarsAPI"]) {
    rel material:binding = </MyMaterial>
    color3f primvars:mydiffusecolor = (.7, .0, .7) (interpolation = "constant")
    color3f primvars:myothercolor = (0, .0, .7) (interpolation = "constant")
}

def Material "MyMaterial" {
    token outputs:surface.connect = <PreviewSurface.outputs:surface>

    def Shader "PreviewSurface" {
        uniform token info:id = "UsdPreviewSurface"
        token outputs:surface
        color3f inputs:diffuseColor.connect = <../PrimvarColor.outputs:result>
    }

    def Shader "PrimvarColor" {
        uniform token info:id = "UsdPrimvarReader_float3"
        string inputs:varname = "mydiffusecolor"
        color3f outputs:result
    }
}

Changing the primvar from mydiffusecolor to myothercolor results in the /MySphere turning black in the usdview viewport. Inspecting the hydra scene browser suggests that the material has updated correctly, but that /MySphere has pruned myothercolor presumably because it was unused when the scene was initialized.

Steps to Reproduce

1. Open up the layer in usdview.
2. Select /MyMaterial/PrimvarColor.inputs:varname
3. In the python interpreter, call usdviewApi.property.Set("myothercolor")
4. The sphere is now black, as if the primvar was missing, instead of the expected blue.

System Information (OS, Hardware)

Linux

Package Versions

Python 3.10

Build Flags

--usdview --no-tests

[sunyab]

Filed as internal issue #USD-8217

[robp-sidefx]

I wanted to revisit this bug in the context of Hydra2 as we had similar issues with our realtime rendering engine.

Are there thoughts/plans on making the DependencySceneIndex part of hdsi rather than hdSt? We've got a copy-paste version of it in our codebase (though we may start diverging from the original code for our specific needs).

Also, more recently it seems dac626e removed this primvar dependency from the DependencySceneIndex, citing it's already being introduced by the MaterialPrimvarTransferSceneIndex. We don't have need of the primvar transfer, but we do have need of dependencies being introduced, which furthers the above comment that we'll probably need to take a Houdini-specific DependencySceneIndex in our own direction.