Dynamic file format behavior changes with 24.11

Community USD
1

Hi,

we’re in the process of upgrading to USD 24.11 and we were on 24.03 before, so we skipped 24.05 and 24.08. As we’re testing things we’ve noticed a behavior change with the SBSAR dynamic file format plugin: USD-Fileformat-plugins/sbsar at main · adobe/USD-Fileformat-plugins · GitHub

I suspect the behavior change is due this big change: Compose dynamic file format arguments through all non-dynamic arcs. · PixarAnimationStudios/OpenUSD@4076951 · GitHub
It’s from May 10th by @diyajoy. But I’m not 100% sure, since it’s hard to revert individually. But it seems to be the only change in that space.

We have a simplified procedural material setup using dynamic payloads that looks like this:

#usda 1.0

over "SbsarMaterial_prototype" (
    active = false
)
{
    custom int2 procedural_sbsar:_outputsize = (9, 9)
    custom float procedural_sbsar:procParam = 0.123

    # Material network definition goes here
}

def Material "SbsarMaterial" (
    active = true
    prepend references = </SbsarMaterial_prototype>
    variants = {
        string resolution = "res0016x0016"
    }
    prepend variantSets = "resolution"
)
{
    variantSet "resolution" = {
        "res0016x0016" (
            prepend payload = @/path/to/SbsarMaterial.sbsar:SDF_FORMAT_ARGS:depth=1@</SbsarMaterial>
        ) {
            custom int2 procedural_sbsar:_outputsize = (4, 4)
        }
    }
}

Note the two procedural attributes: procedural_sbsar:_outputsize and procedural_sbsar:procParam, which both exist on the /SbsarMaterial prim and are originally coming in via the references arc from /SbsarMaterial_prototype. Also note that procedural_sbsar:_outputsize is set to a different value inside of the resolution variant.

When the dynamic file format is called with ComposeFieldsForFileFormatArguments() we use the PcpDynamicFileFormatContext::ComposeAttributeDefaultValue() to get the default values of these procedural attributes.

With 24.03 we get a default value for both attributes: (4, 4) and 0.123 respectively.
With 24.11 we get only a default value for procedural_sbsar:_outputsize and the value is (4, 4).

That is the behavior change. We’re curious if that happened to work in the past, to get the default values that came via the references arc, but is actually incorrect and that the new behavior is correct. Or if it should actually provide all default values of attributes that exist on the /SbsarMaterial prim?

I did some experiments to change the setup and put the default values directly on the /SbsarMaterial prim (instead of on the /SbsarMaterial_prototype prim ) and that works as before. Authoring overrides on this attributes on stronger layers also works.

I also removed the resolution variant and that works as before, while still having the references arc in there.

#usda 1.0

over "SbsarMaterial_prototype" (
    active = false
)
{
    custom int2 procedural_sbsar:_outputsize = (9, 9)
    custom float procedural_sbsar:procParam = 0.123

    # Material network definition goes here
}

def Material "SbsarMaterial" (
    active = true
    prepend references = </SbsarMaterial_prototype>
    prepend payload = @/path/to/SbsarMaterial.sbsar:SDF_FORMAT_ARGS:depth=1@</SbsarMaterial>
)
{
}

Some guidance around the expectations for this would be helpful.

(My best guess might be that this an unexpected LIVRPS effect of having the payload on the variant and then the payload doesn’t see the R part of the prim, since it is still evaluating the V part.)

Thanks so much,
Florian

1 Like
2

Hi @fhecht ,
That change was intended to facilitate the style of asset that was proposed here, which previously did not work. Let us investigate whether we were testing the “workaround” asset structure from the subsequent post, which looks like the one you are reporting is not working.

3

Hi @fhecht ,
Thanks for pointing this out! The behaviour change you pointed out was intentional (following LIVRPS strength ordering), but after reviewing the use case you provided, we agree the original behaviour is more intuitive. Our goal with the dynamic payloads going forward is that the params should evaluate to roughly the same value whether payloads are loaded or not.

I’m working on a fix to restore the original behaviour now and will link it to you when it’s published!

4

Hi @diyajoy,

Thanks so much for looking into this. And I really appreciate that this change is being reconsidered, but I wanted to make it clear that we can make it work either way. So if the current version is actually better, that is OK from our perspective. This is more about clarity around this behavior.

If you’re going to change the behavior can you make sure that this type of setup will work going forward. This is actually the way we originally wanted to set this up and with the current behavior (as of USD 24.11) this works now.

#usda 1.0

over "SbsarMaterial_prototype" (
    active = false
)
{
    custom int2 procedural_sbsar:_outputsize = (9, 9)
    custom float procedural_sbsar:procParam = 0.123

    # Material network definition goes here
}

def Material "SbsarMaterial" (
    active = true
    prepend references = </SbsarMaterial_prototype>
    prepend payload = @/path/to/SbsarMaterial.sbsar:SDF_FORMAT_ARGS:depth=1@</SbsarMaterial>
    variants = {
        string resolution = "res0016x0016"
        string preset = "default"
    }
    prepend variantSets = ["resolution", "preset"]
)
{
    variantSet "resolution" = {
        "res0016x0016" {
            custom int2 procedural_sbsar:_outputsize = (4, 4)
        }
        # Other resolution variants here
    }
    variantSet "preset" = {
        "default" {
        }
        "alternative" {
            custom float procedural_sbsar:procParam = 0.456
        }
        # Other preset variants here
    }
}

In this case the payload is on the prim itself and we can have parallel variants sets that contribute attribute values which affect the dynamic payload arc.

Currently we’re actually nesting multiple variant sets and then putting the payload on the inner most variant, which is a rather ugly and verbose setup.

In any event, we’re grateful for what you do.

Thanks,
Florian

5

@fhecht Thanks for clarifying! We’re still going to make a change so that the workaround you’ve been using will function again since we think that behaviour is more intuitive for users in general. We also intend to keep the pattern you just provided (using variants to set the params) working consistently and have an internal test case based on your example to ensure that!

1 Like