Alternatives to Layer Muting for Persisting Across Sessions

Community USD
1

I am currently working with USD and have been using layer muting to temporarily ignore certain layers during a session. However, I have found that this state does not persist across different sessions of my application, and I would have to programmatically mute the layers again each time I start a new session.

I am wondering if there is an alternative method or approach in USD that achieves the same effect as muting a layer but can be persisted across sessions? Ideally, I am looking for a way to save the state of ignored layers so that when I restart my application, the specified layers are automatically ignored without having to programmatically set their state each time.

Any advice or suggestions on how to manage this kind of state across sessions in USD would be greatly appreciated!

2

Although it is still a “wet paint” feature (user doc is IP), USD Variable Expressions provide a way to conditionally enable layers, and record the “activation state” in the root layer of a scene (among other powerful capabilities).

However, there isn’t yet any DCC support for working with this feature, but all the API is there for you to experiment with, in the dev-branch of the repository.

I’ll also mention that “muted state” is an aspect of session state that DCC’s could support, if there is call for it. I believe some DCC’s already leverage UsdStage Load state/rules, which is also session state, so it would not be unprecedented. But it would not travel from app to app, which might be one of your goals?

3

Thanks Spiff,
I wanted to use muting as a means to revert back to a previous state, non-destructively. I now believe the correct approach would be to insert a stronger layer, and make the reversions in that layer.
Are there any convenience methods for applying the reversions, essentially muting a layer?

4

Hmmm… reversion really sounds more like either an undo/redo transaction, or asset/version management/check-pointing? We don’t provide any API or tools for non-destructively undoing edits that have accrued in a particular layer(s). I think in full generality that might require some pretty drastic flattening to guarantee the same results in all cases.

5

My use case is a ‘digital twin’ type scenario, where, for example, some damage is tracked in a separate layer, and then after the repair, the damage would be reverted, but I want to keep the history of the damage.

1 Like
6

That honestly sounds like a perfect use case for conditional layer inclusion with variable expressions, because the variable names and values can clearly provide the semantics of the “states” you are tracking…

Just need to build or lobby for the tooling :grinning:

7

Hi,
is there a way to save layer muting into a .usd file?
(I am working in Houdini / Solaris in this case)

For example:
I have an asset component (a waving flag).
The asset consists of the typical layers:
asset.usd
payload.usd
geo.usd
mtl.usd

Plus an additional geo_anim.usd that overlays a looping flag animation over the geo.

The asset gets exported and referenced into the lighting stage.
Now I want to be able to disable or enable the animation overlay not only in the viewport (which is possible via Houdini’s Scene Graph Layer Menu or Configure Stage LOP), but also translate this into the (Karma) render.

The Configure Stage LOP’s doc sound to me like this should translate into the output usd stage, and with that the rendering. But this isn’t the case.

Sounds like it’s not possible yet by USD architecture?
Would this be possible once SideFX had implemented USD Variable Expressions?

I suppose handling this via an additional nested variant set like (variant set anim [static, animated]) is probably smarter? But still would be interested if this was possible.

There is a post in the SideFX Forum as well, but couldn’t get this to work on a render level.

Thanks!

8

Hi, Adrian.

You could use a variantSet in the defaultPrim of the asset to choose between (static | animated) variants. Then the animated variant could overlay your geo_anim layer.

About using Variable Expressions.

Let’s say you include them in your asset to enable/disable the geo_anim layer.
You will find a problem when you reference the asset into a shot, for example.
You would need to add the Variable Expression to the shot stage for the asset to pick it up, as Variable Expression doesn’t get composed.

At least that is my understanding of USD Variable Expressions, hope it helps

9

Hey, thanks for the reply.
Yeah probably it’s a bad example, as this would be best handled with a variant set in practice.

However my question is actually, how you can mute any stage layer not only in the viewport, but also for .usd and render output.
I would have expected the Configure Stage LOP in Houdini to support that, with it’s Mute Layer functionality.
However this only works for the stage in the viewport, not at stage export or render.

So USD Variable Expressions would allow that correct?

10

Hi @adrianmeyerart , you could follow up with SideFX to see if they plan to support muting as a persistent operation in the context of Solaris… though because USD itself does not support it, it would be non-portable. While we are open to being persuaded otherwise, we see muting as a session-based, more limited functionality, whereas expression variables provide alot more power (including the ability to drive variant selections). Eventually I would imagine rendering tools (including usdrecord) to support command-line options that either allow you to directly specify expression variable overrides or (like usdview) specify a session layer for the stage that contains overrides. It may take a beat or two for that to happen, though.

11

Hi @spiff,
thanks a lot!
Okay I understand. If layer muting was only intended to be session based, I have full trust in smart brains like yours that this has it’s valid reasons (-;
Will have a closer look into Expression Variables then.

12

Could you provide an example of how an Expression Variable could ‘author’ an opinion that essentially equals what layer muting would be doing?

It would essentially require the layer that I’d like to mute to have already been authored as e.g. sublayer using an expression. I couldn’t really just from a later stage decide to have some opinionated behavior based on my stage variables?

I also wonder if since your post in November 2024 above whether there have been much changes on the Solaris/Husk side to support these out of the box. Do you happen to know whether there have been?

13

Hi @BigRoyNL,

I just tried using an expression variable to mute a layer and I think this is maybe what you asked for?

#usda 1.0
(
    expressionVariables = {
        bool includePlanning = false
    }
    defaultPrim = "world"
    endFrame = 47
    endTimeCode = 47
    startFrame = 1
    startTimeCode = 1
    subLayers = [
        @sequences/000996/0020/lighting/lighting.usda@,
        @sequences/000996/0020/effects/effects.usda@,
        @sequences/000996/0020/animation/animation.usda@,
        @`if(${includePlanning}, 'sequences/000996/0020/planning/planning.usda', '')`@,
        @sequences/000996/0020/shotbase/shotbase.usda@,
        @sequences/000996/base/base.usda@
    ]
    upAxis = "Y"
)

def Xform "world" (
    kind = "assembly"
)
{
}

In this example the variable "includePlanning " is set to false and is replaced with an empty string, effectively muting it when I open the stage.

I can change the variable to true and get the layer back.

is this what you were looking to do?

Cheers,

Jason Coelho

14

Thanks, yes - this does show the issue that I mentioned. The only way you could affect the layer then is if the list of sublayers would’ve been authored with the expression included. It’d still disallow someone to specifically ‘mute’ or ‘deactivate’ an already existing layer in a layer list and turn that into a valid opinion if it did not include an expression.

The case I’m facing is that in Houdini Solaris an artist may have muted a layer and would then submit it to the farm expecting that what they are seeing in there scene would also render on the farm. But due to the layer muting not persisting or being able to persist towards the farm render there’d be no way to actually submit the scene in the state as to what they were seeing.

In our case we’re loading the Shot usd file that happens to also contain the lighting layer itself, so we mute it. When we submit to the farm for a render, I’d want it to render only my local scene state (with that ‘old’ published layer muted but with now the local scene changes applied.)

The only workarounds I could think of is either:

  • A. Always submit scene in a flattened state. But this is a no go due to it basically writing a massive scene file each time.
  • B. Ensure to write out the lighting layer, update the loaded shot version to use the new included lighting layer.

However, even I were to go that route with B being the only viable option (and I think it’s also the recommended approach?) I also need to think about how to submit “renderlayers” for the shot too. Because suddenly I can only work with the single lighting layer in the full shot, meaning that separate renderlayers must become either variants or custom rendersettings. With variants becoming the only viable approach due to it actually allowing me to alter scene state between the variants (e.g. one branch changing visibility/active state of prims across the scene, or other prim vars / material overrides, etc.). However this requiring to be variants adds a lot in complexity over just being able to submit a muted layer versionw with custom overrides on top - just for the farm render.

Or maybe the best approach would be to default authoring all our shot layers using an expression variable.

15

Hi @BigRoyNL , I wonder if you’ve had time to digest the concepts in UsdRender? It’s a set of schemas designed for controlling many aspects of rendering, including being able to set up many different variations (elements, fg/bg renders, fog/effects renders, compositing, etc) . I think Solaris has/is building toolset for working with them. Internally, we are using them in conjunction with expression variables, which control inclusion of sequence/prod/lighting-packet-specific layers.