USD - Asset / Shot initialization - an issue with default settings

Hi everyone,

I’m a bit confused by the default preferences in Core > Collect USD Layer Contributions > Profiles regarding how USD files are initialized.

By default, the default setting seems to initialize every asset as a SHOT, even when the user selects “usdAsset” as the target product during publishing. I’ve tested this several times, and the result is always the same: the publish attributes of the Maya set include "contribution_target_product_init": "shot" (as shown in yellow in the image below). You simply can’t change that from the publishing window as you see.

So, unless the preferences are changed, all assets end up with a structure like the one shown below, where the department contribution is brought in as a sublayer. As far as I’m understanding from context, this structure was originally intended for SHOTs, not assets.

However, if you include the configuration below…


…that indeed makes a difference. Now you can see the the Maya set now includes "contribution_target_product_init": "asset" (in yellow):

The ASSET now is initialized with a payload.usd file, saved alongside the generated version. That payload.usd then includes the department contribution as a sublayer. Again, as far as I’m understanding, this was the intended structure for ASSETs.


Question 1:
In this post by @bigroy:

…there’s a publish window with an “Initialize as” option, allowing the user to choose between Asset or Shot.
Why was this option removed?

Do you agree that the current default setup could be misleading? A user might think they’re initializing an asset (based on their target product selection), when in fact the resulting structure is that of a shot. This seems problematic, specially since changing the target product in the publishing window doesn’t change how the entity is initialized.


Question 2 (this is more of a general USD question):
Is it really necessary for every asset to be initialized with a payload.usd?
Shouldn’t the user have the options so important assets would be referenced into shots instead of payloaded?


I’m sorry for the long post but I couldn’t explain the issue in a shorter way.
I’m still wrapping my head around USD and would love to hear your thoughts about the two different ways of initializing Assets and Shots.

Thanks a lot in advance!

Question 2 (this is more of a general USD question):
Is it really necessary for every asset to be initialized with a payload.usd ?
Shouldn’t the user have the options so important assets would be referenced into shots instead of payloaded?

I’d say, yes - there’s no reason why a USD asset should not have a payload in my opinion. A USD asset usually encompasses heavy geometrical data or alike. The only reason I can see is e.g. an “Assembled USD Asset” that other than assembling from multiple other assets doesn’t contain it’s own data. In that case one could argue that the payloading would already be done at the assets being referenced in - and you’re merely adding some references which you’d likely not want to payload so that the ‘metadata’ of its included children is still easily accessed. So a toggle or option there may be in place - but so far it hasn’t been an issue.

Shots however, can reference or payload in the USD asset so that’s up to you. Usually a shot doesn’t payload in its department layers, but uses sublayers.

…there’s a publish window with an “Initialize as” option, allowing the user to choose between Asset or Shot .
Why was this option removed?

If I’m not mistaken that’s now all based on whether you’re targetting a usdShot or usdAsset. The option itself just kept confusing most people, so it was hidden away.

Also, it only ever really applied to the first publish of that product (making it even more confusing if it remained visible).

I think this may actually point to a bug… this logic was intended to define the ‘init’ state. However, technically if the user would ‘save’ the instance once… then change target product and then publish it’d essentially use that first saved value - because the attribute value was essentially saved into the instance and the default would not be used.

Edit: It’s worse even - the default does not auto-update live on usd target product changes… :slight_smile: So yes, there’s something fishy going on there.

Also, the defaults being ‘confusing’ is because we’re still lacking either of these PRs:

Priority has been low on this however (due to no clients really pushing for it?) and a decision would need to be made from a code perspective which of the approaches is best. I believe PR 206 is the better approach and I’ve been using something along those lines in my studio branch (and it’s been suiting us fine). Very likely because of that I may also not have faced the bug described above much because it defaults to usdAsset in that scenario.


@mustafa_jafar anything to add?

1 Like

AYON USD contribution workflow publish plugins don’t make assumptions based on the name of the target product as outlined here. Therefore, there should be a way to tell AYON plugins about the contribution type.

And, I guess your finding here explains why all my test runs in Maya were following the shot structure.

Also, I wonder why it works fine in Houdini. Maybe the type for generic USD product type is hardcoded to shots contribution workflow?
for reference, in Houdini we have separate product types that are specifically for asset contributions although I don’t know where contribution_target_product_init is set.

AYON USD contribution workflow enables artists to use USD in line with recommended guidelines without worrying about the technical complexities as outlined here.

As far as I know, in these guidelines an asset should have payloads which can be quite helpful in many usecases.

I’m not here dicussing why payloads are important, I’m just highligting that this question should be in a separtate discussion about adopted USD guidelines in AYON OpenUSD contribution workflow.

1 Like

Just pointing out the link that I had in my earlier reply. Logic is currently here.. But as described in my comment - it’s actually buggy and not working as intended.

1 Like

It’s not buggy.
It has a side effect that for generic USD instances they are always going to be considered shots contributions.
Another one, that it compares the literal usdAssetwhich may not work if admins picked different default targete name instead usdAsset.

What about collapsing enable contribution and contribution type?

1 Like

Hey @BigRoy thanks for clarifying the payload usage, it makes sense, we’ll do our tests here and probably we’ll stick from now on utilizing the intended structure: assets initialized as assets with payloads, shots initialized as shots with sublayers. About assemblies, that makes total sense too and keeping the configuration as it its, would cause exactly that. An asset bringing other assets already payloaded would be initialized with the structure of a shot, not using paylods but sublayering the department contribution - but it would be called an usdAsset, which is the expected behaviour.

The point here was bringing to attention that unless the user has customized the configurations to something like the image below, there is no no way to change the contribution_target_product_init to asset via publishing window, as changing the Target Product won’t make a difference in the way the usd entity is initialized - every model would then be initialized with a shot structure with no chance to the user knowing it, as it would be named as usdAsset correctly.

@mustafa_jafar - same case here - we have discovered it by accident. Changing the configuration as mentioned above had the intention to make life easier for departments, since the publishing window would bring the correct target product. All of a sudden, that made the payload files appear in our asset publishes, leaving us scratching our heads because that was not seen until that moment - we thought we were already initializing our assets as assets, but they were being authored as shots.

In Houdini, to me, even having the above mentioned configuration don’t seem to initialize an asset as asset. As you see in the image below, the behaviour differs from what’s happening in Maya and it insists in initializing as a shot structure.

Edit: I can confirm that Blender initializes the usdAsset as asset, with payload, once the configuration shown in the top of this message is changed. Houdini is the one with different behavior so far.

Your help is very much appreciated!

Note that this configuration is for the usd product type itself. which is one in Houdini.

on the other hand, the usd model USD Asset Model should have the following configuration. Note the product type is named model.

ehm, I’m not sure why this happens. Could you double check the configuraiton?

1 Like

Hey @mustafa_jafar
I was thinking every USD output was just being influenced by a “USD” product type configuration, but now I see that Houdini needs it setup another way. I’ve tested here and confirmed, the configs you pointed out are working as they should - now the model is initialized as an Asset in Houdini, thanks for clarifying this setup

About the bigger issue pointed here, thanks to you and to BigRoy for all the explanations. From our side it is comprehended now how to proceed in each case (initializing usd as assets or shots), but I suppose there are a lot of testers out there initializing assets as shots without noticing it, as you pointed out:

Cheers!

1 Like

Wait - aren’t those the setting defaults? :confused:

Agreed - it’s a bug hidden in plain sight that most likely will have gone unnoticed by many if they faced it. So it’s very good you pointed this out. I don’t have time to look into fixing it shortly (have some other priorities myself) but once I get back into USD I can take a peek, otherwise someone else can in the meantime. :heart_hands:

Tank you @diego_kasper, I’ve created an issue for it.

Yes, they are! While trying to customize Maya’s publishing windows we’ve seen no difference when these were removed, as it looks like Maya USD publishing only takes into consideration the USD product type configuration. Now it’s clear why the configs were there - Houdini cares about them as @mustafa_jafar explained

We’ve been super interested in the adoption of Ayon and we’d love to see Ayon’s capabilities in terms of providing the tools for dealing with USD growing more and more. As I commented in other posts, you’ve proposed great PRs regarding USD that we’d very much appreciate seeing integrated! :raised_hands:

Thank you @mustafa_jafar for this and clarifying the configs!