Single-element primvar declaration

Community USD
1

Hello,
I’d like to ask for a simple clarification when declaring primvars with constant interpolation:
The user guide says “Note that you still need to provide an array (that contains a single element) for the primvar.”
But when declaring a single element primvar without using an array, usdview still interprets everything nicely, like shown in the following file:

#usda 1.0
(
    defaultPrim = "Root"
    metersPerUnit = 1
    upAxis = "Y"
)

def Xform "Root"
{
    def Sphere "MySphere" (
        prepend apiSchemas = ["MaterialBindingAPI"]
    )
    {
        rel material:binding = </Root/MyMaterial>
        float3 primvars:myColor = (0, 0, 1) ( interpolation = "constant" )
        double radius = 0.5
    }

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

        def Shader "ColorReader"
        {
            uniform token info:id = "UsdPrimvarReader_float3"
            float3 inputs:fallback = (0, 1, 0)
            string inputs:varname = "myColor"
            float3 outputs:result
        }

        def Shader "PreviewSurface"
        {
            uniform token info:id = "UsdPreviewSurface"
            color3f inputs:diffuseColor = (1, 0, 0)
            color3f inputs:diffuseColor.connect = <../ColorReader.outputs:result>
            float inputs:metallic = 0
            float inputs:roughness = 0.5
            token outputs:surface
        }
    }
}

So, is this intentionally supported and should I expect other renderers than Storm to have the same behavior if they follow the canonical spec? If yes, what is the recommended declaration, knowing that for example Maya exposes non-array attributes in the ExtraAttributes of a prim while array attributes are not shown at all.

image
image451×382 18.9 KB

Thanks a lot!
Marcel

2

The answer is… it depends, and there isn’t a perfect answer :frowning: Primvars can be either scalar or array-valued, and in USD, that of course becomes part of the primvar attributes type. That means that, e.g. if a schema declares it to be scalar valued, it is a validatable (not sure we’ve deployed the actual validator yet) error for a scene to provide an array for the primvar.

Renderers are expected to handle scalar, constant primvars as well as arrays, but we recommend using arrays anyways, because in our pipeline experience, the original author of the primvar in modeling/shading can’t always predict the needs of downstream departments, who may want to override a constant with something that is uniform, varying, or faceVarying, all of which require an array of values.

But OTOH, you’ve run smack into the same problem we had in Presto that led some of Presto’s schemas/workflows to use scalar primvars: DCC support for editing arrays is spotty at best.

Most primvars are “custom” in that they are not part of schemas, and in USD, nothing will blow up if a stronger layer overrides a scalar attribute with an array, though you’d still get a validation error. But for primvars:displayColor and primvars:displayOpacity we declared them as arrays, and you would likely encounter more friction if you overrode them as scalars.

3

Makes absolutely sense. Thank you very much!