Using MaterialOverride Schema

Community Hydra
, ,
1

I’m experimenting the Hydra 2.0 and I’m trying to understand how I can use the MaterialOverride schema to apply tweaks to the material parameters using a UI. What is the correct way to specify material overrides in a usda file? Let’s say I have this material in the file:

   def Material "RedMaterial" {
        token outputs:surface.connect = <SurfaceShader.outputs:surface>  
        color3f inputs:diffuseColor = (1, 0, 0)
        def Shader "SurfaceShader" {
            uniform token info:id = "UsdPreviewSurface"
            color3f inputs:diffuseColor.connect = </World/RedMaterial.inputs:diffuseColor>
            token outputs:surface
        }
    }

How would I specify a material override for the diffuseColor parameter?

2

Hi Nicola,
I am not an expert, but I think it may be related to the “over” keyword like in these usda files :

Some people also use a “variant” with the “over” keyword to override a value.
Regards,
David

3

You may also look at this file :

which uses variants to override the displaycolor of a Cube.
Regards,
David

4

Hi David, thanks for the answer. I tried the following:

file simple-cube.usda:

#usda 1.0

def Xform "World" {
    def Cube "Cube" (
        prepend apiSchemas = ["MaterialBindingAPI"]
    ) {
        float3 xformOp:translate = (2, 0, 0)
        uniform token[] xformOpOrder = ["xformOp:translate"]
        rel material:binding = </World/RedMaterial>
    }

    def Material "RedMaterial" {
        token outputs:suface.connect = <SurfaceShader.outputs:surface>  
        color3f inputs:diffuseColor = (1, 0, 0)
        def Shader "SurfaceShader" {
            uniform token info:id = "UsdPreviewSurface"
            color3f inputs:diffuseColor.connect = </World/RedMaterial.inputs:diffuseColor>
            token outputs:surface
        }
    }
}

file simple-cube-over.usda:

#usda 1.0
(
    subLayers = [ @./simple-cube.usda@ ]
)
over "World" {
    over "RedMaterial" {
        color3f inputs:diffuseColor = (0, 1, 0)
    }
}

If I load the simple-cube-over.usda, the input RedMaterial.diffuseColor gets correctly resolved as (0,1,0).

To clarify, I’m writing a SceneIndexObserver for our Hydra 2.0 render delegate.

In the following C++ code, I’m trying the extract the MaterialOverrideSchema from the material primitive’s data source. But the primitive doesn’t seem to contain the data corresponding to the MaterialOverrideSchema. I’m trying to figure out why.

Observer::PrimAdded(HdSceneIndexObserver::AddedPrimEntry entry, Observer* observer) {
    if(entry.primType == HdPrimTypeTokens->material) {
        return CreateMaterialPrim(entry.primPath, observer);
    }
}

Prim* CreateMaterialPrim(SdfPath primPath, Observer* observer) {
    HdContainerDataSourceHandle primSource = observer->GetSceneIndex()>GetPrim(path).dataSource;

    HdMaterialOverrideSchema materialOverrideSchema = HdMaterialOverrideSchema::GetFromParent(primSource);
    if(materialOverrideSchema.IsDefined()) {
        std::cout << "OK" << std::endl;
    } else {
        std::cout << "Something's wrong" << std::endl;
    }
}
5

It’s not really clear to me what a HdMaterialOverrideSchema does…
But my understanding is that it is not used to override material’s values but the public UI :
// The MaterialOverride schema allows overrides to be made to the material’s
// public UI. Overrides can be applied to both material or geometry scene
// index prim locations.
To me the “over” keyword seems more like a Hydra : HdContainerDataSourceEditor or HdOverlayContainerDataSource but that is just a guess. I am not 100% sure… And I am not aware of a way to use a schema to detect an override made with one of those classes.
You can find usage of these classes on :

And line 152.

Regards,
David

6

Thanks for the link. I’m interested in the HdMaterialOverrideSchema because it allows to specify the public UI parameter values in a way that is loosely coupled to the shader parameters in the node graph.

Let’s say that I want to tweak a parameter value from a DCC application. If I author the parameter directly in the shader network, or even as an override, that would most likely trigger a shader recompilation, because the parameter values are inside the shader graph contained in the HdMaterialSchema locators.
But if I author the parameters in the public UI managed by the HdMaterialOverrideSchema, then no shader recompilation would be triggered, and I could just update the parameter values in the already compiled shaders.

According to the documentation in the files

/pxr/imaging/hd/materialSchema.h
/pxr/imaging/hd/materialOverriedSchema.h

You could author a public UI attribute as (please correct me here, I’m still new to OpenUSD)

def Material "RedMaterial" {
        custom color3f materialOverride:interfaceValues:diffuseColor:value = (1, 0, 0)
        # rest omitted
}

The problem is that if I try to author the public UI attributes in like the above, they are not available in the primSource of the scene index:

Prim* CreateMaterialPrim(SdfPath primPath, Observer* observer) {
    HdContainerDataSourceHandle primSource = observer->GetSceneIndex()>GetPrim(path).dataSource;

    HdMaterialOverrideSchema materialOverrideSchema = HdMaterialOverrideSchema::GetFromParent(primSource);
    if(materialOverrideSchema.IsDefined()) {
        std::cout << "OK" << std::endl;
    } else {
        std::cout << "Something's wrong" << std::endl;
    }
}

It looks like the problem stems from the fact that the UsdImagingDataSourceMaterialPrim (file dataSourceMaterial.cpp) in usdImaging scene index is skipping the data for the materialOverrideSchema, making it unavailable to downstream scene indices.

The question is, if the materialOverrideSchema is missing from the implementation, what is the common way to specify material parameters without triggering shader recompilation?

PS. I added an issue on Github: UsdImagingDataSourceMaterialPrim is missing the the MaterialOverrideSchema · Issue #3550 · PixarAnimationStudios/OpenUSD · GitHub

7

My experience with shader recompilation in HdStorm with MaterialX shaders is that updating a color in Maya doesn’t trigger a recompilation of the MaterialX GLSL shader in Storm.
Regards,
David

8

Thanks for pointing that out. Probably looking at the hdStorm implementation will clarify how to handle parameter changes without triggering shader recompilation. Thanks!