Using LOD support for Materials?

Community USD
1

Is there such a thing as using the LOD schema purely for material bindings? Like switching between an expensive procedural material, when geometry is close, to a cheap low-resolution pre-baked material when far away (while using the same geometry as the prior)?

If so, how would that best be represented in the file?

If not, are materials strictly relegated to just using the material purposes for such things?

2

I don’t have a comment on “best” representations, but here’s a general note on materials (or anything really) configured for LODs:

The LOD schema allows you to set up heuristics for deciding which children fit the selection criteria. It is up to a renderer (i.e., an LOD consumer) to do something with that information.

Work on Hydra support for LODs is underway, so you cannot observe this behavior in Hydra based systems, e.g. usdview, today.

3

Thanks Nick. It sounds like Materials are supported in some way then? Perhaps “best representation” wasn’t the right phrase, it’s more rather how might it be represented at all?

We’re just working through some thought experiments on our side and materials came up and we haven’t quite moved to 26.08 yet so we’re mostly sketching things out blind.

One of the confusing points is related to the material binding path and the main shader connect path. If there needs to be a “scope” for the LOD groups, how do we reconcile the path that we use for these tokens?

One example where the LOD grouping is at the Material level itself (see ??? placeholder):

def Mesh "mesh" (
    prepend apiSchemas = ["MaterialBindingAPI"]
)
{
    rel material:binding = </Materials/Test>
    ...
}

def Scope "Materials"
{
    def Material "Test" (
        apiSchemas = ["LODRootAPI"]
    )
    {
        token outputs:surface.connect = </Materials/Test/???/TheShader.outputs:surface>
        ...

        def "Expensive" {
            def Shader "TheShader" { ... }
        }
        
        def "Cheap" {
            def Shader "TheShader" { ... }
        }
    }
}
4

@deadpin , we need to have a deeper think about this, and some of the key folks are OOO this week. But my initial thinking is that we all missed this; I surely remember thinking, well, if you’re going to be going as far as simplifying the shading, surely you’ll be simplifying the geometry also. And so today the only way to encode Material variation per LOD for the same geometry would be to duplicate the geometry per-LOD - the existing OOTB material “purpose” binding values (full and proxy) aren’t really the right axis.

Because there’s so much explicit connectivity to and within Materials, it’d be really challenging to make the same LODRoot/children encoding work for Material-variation-per-LOD. But Material purpose or maybe Material terminal “render context” could be brought to bear.

But it’d be great to start with how important we believe this is?

5

Right, if you’re simplifying the shading you’re probably simplifying the geometry too. I think? Maybe?

The topic here is not an indication of importance though :slight_smile: It came about as a tangent to something else we were discussing and isn’t necessarily something that we wish is possible to do.