Bootstrap asset or shot on creation? (e.g. USD Asset)

[BigRoy]

Issue

It seems it's very common for a pipeline surrounding USD to prepare the "common ground" for an asset or shot. Basically bootstrapping some default .usd contents for an Asset which would act as a placeholder.

More details on that can be found in this USD Pipeline topic on usd-interest.

I was wondering, what would be the way to potentially do this in Avalon? And when/where? Or is this "too odd" behavior for Avalon and is this unexpected for Avalon core to be possible.

Consider this a discussion and the issue is to track ideas that come up.

[mkolar]

It actually aligns with some feature requests we are getting outside USD. namely master versions, which is how usd is kind of designed on the base level.

Clients want to be able to choose between explicit pull system and master version push, where they references v0, or simply versionless asset, therefore they won't need to update all the scenes with new versions. Dangerous at times, but saving tons of time at others.

[BigRoy]

Clients want to be able to choose between explicit pull system and master version push, where they references v0, or simply versionless asset, therefore they won't need to update all the scenes with new versions. Dangerous at times, but saving tons of time at others.

Technically you can hack your way into this. Set up an Integrator that will symlink a file to v000 or v999 or master which the loader will then use. Going v999 might be the easiest. So what you could do is just publish regular versions 1, 2, 3.. etc and update the symlink in master. Then your loader could load the path from anywhere, e.g. if version == 999: load_master. The only reason I'm mentioning the v999 as an idea is that with that one the Scene Inventory will automatically try and force users to update to v999 ;)

Anyway, your use case actually sounds quite different than what I tried to describe. In your case it doesn't sound like you need to bootstrap these files on asset creation. They can just be generated when you publish.

Be aware that USD can use versioning however you will be needing to implement a custom ArResolver for your use case. I'm hoping to do this for Avalon before end of February as we need it in production.

With USD however, the usdAsset would reference usdModel and usdShade of which the latter two must exist before usdAsset. Producing manually per asset would be too cumbersome and unmanageable in production so we have an automated Python script currently to prepare these initially however it seems odd compared to how the rest is provided in Avalon through its toolset. This seems to become a strange exception to its behavior. Even these could be generated on first publish. I will take a look at that coming week.

Currently I am looking in ways to streamline this without making these very odd exceptions.

[BigRoy]

Regarding the Bootstrapping I ended up taking a different approach which we'll be testing coming week whether it works as Users would like.

What I've done now is perform the bootstrapping on Publish. This had some benefits:

• Publishing is a step that is already being done anyway, no new "need to do this first" or callback on asset create.
• The bootstrapped files are only generated when they actually start having something to show, e.g. now the usdAsset gets generated right when the first usdModel is being published.

From a developer's point of view it still has some downsides:

• Slightly more complexity during publishing.
  • What I have done is create a CollectUsdBootstrap that runs after the instances (order + 0.1) that will generate new instances of family colorbleed.usd.bootstrap. Then I have a ExtractBootstrapUSD plugin that generates the USD layers and files in memory using the USD Python API and generates the files on disk so that the regular Integrator picks it up. Basically the Collector create some extra "dependencies" on instances up for publishing.
• A user could technically deactivate the Bootstrap instances in the UI, or vice versa, deactivate the one instance they were dependent on and keep the others active.
  • I haven't looked into what the best way would be to sync those up. Technically you can set up an extra "callback" on active changed with Pyblish and have it make sure the statuses are in sync. Which would again introduces more lines of code which I'm feeling this shouldn't really warrant.

Will follow up later this week after some artists started to try this workflow.

[mkolar]

A user could technically deactivate the Bootstrap instances in the UI, or vice versa, deactivate the one instance they were dependent on and keep the others active.

It's a bit cheeky, but how about generating this instance as different data in the context (bootstrapInstances for argument sake)> The your extractor would run on context and iterate through them, but they wouldn't show up in the UI, so Artist can't mess them up.

[mkolar]

I was wondering what family are you going to use for this, if any. We're kinda running into a need to create a new family that acts in a very similar way to asset.usd. Technically it should be a render ready model with all the shaders applied. So we don't have to reference model and apply it's look in the set dressing for example. The question is what to call it.

I'm assuming that you have usdModel family for these?

[BigRoy]

For now we are working with family usd and subset usdAsset that references usdModel and usdShade.