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!
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?
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?
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.
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.
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