ynput / ayon-core

Apache License 2.0
26 stars 31 forks source link

USD Contribution Workflow: Default to off for 'usd' but allow easy defaults for asset or shot contributions #791

Open BigRoy opened 1 month ago

BigRoy commented 1 month ago

Is there an existing issue for this?

Please describe the feature you have in mind and explain what the current shortcomings are?

Currently whenever creating a USD instance in a host that generates a usd product the default values for USD Contributions are for it to be enabled and targeting the usdAsset. This can be a source of confusion for those starting with USDs in their pipeline yet not using the AYON USD contribution workflow for assets and shots at all.

Add to that that it requires some training to get really well-versed in how AYON's USD contribution workflow works (there's still lacking documentation) AND the fact that a Shot specific contribution always still requires publisher instance attribute changes by the artist to use it for Shot contributions, because it defaults to Asset contributions - making it easy to misuse and prone to user mistakes.

How would you imagine the implementation of the feature?

Preferably the Publisher UI or the creation of these USD publishes comes with "presets" with their own defaults, so that e.g. an artist can pick to:

  1. Generate a USD publish (nothing special, just generate a single USD file)
  2. Generate a USD asset contribution (same as above, but preconfigured to use AYON USD asset contribution workflow adding the file as variant to a layer of the usdAsset.
  3. Generate a USD shot contribution (same as 1. but preconfigured to use AYON USD shot contribution workflow adding the variant as layer to the department layer of the usdShot.

Are there any labels you wish to add?

Describe alternatives you've considered:

An approach could be to create a dedicated Creator class for each, but that would then need to be done for EACH host supporting the usd format - easily generating a lot of duplicated code.

At the same time, the 'attribute defaults' that need to be updated are on the ayon-core plugin CollectUSDLayerContributions yet you can't have different defaults for those attributes per Creator class - so we'd also need to duplicate that targeting each specific entry. To support that we could then for each host have e.g. a USD creator specific to each 'preset'.

That would make it e.g. this in each host:

class CreateUSD:
    identifier = "ayon.io.usd"
    product_type = "usd"
    families = ["usd.generic"]

class CreateUSDAsset:
    identifier = "ayon.io.usd"
    product_type = "usd"
    families = ["usd.asset"]

class CreateUSDShot:
    identifier = "ayon.io.usd"
    product_type = "usd"
    families = ["usd.shot"]

_Note that "families" isn't a thing for the CreateContext or Publisher UI. We'd actually need to make the "producttype" different for each for the Publisher UI to actually update what attributes are shown in the Publisher UI. However, we WANT to just generate a USD file... seems odd to make it a different product type altogether maybe?

And then have specific defaults for each of those:

class CollectUSDLayerContributions:
    families = ["usd.generic"]

    @classmethod
    def get_attribute_defs(cls):
        return [attrs_with_generic_defaults]

class CollectUSDLayerContributionsAsset:
    families = ["usd.asset"]

    @classmethod
    def get_attribute_defs(cls):
        return [attrs_with_generic_defaults]

class CollectUSDLayerContributionsShot:
    families = ["usd.shot"]

    @classmethod
    def get_attribute_defs(cls):
        return [attrs_with_generic_defaults]

That would make it e.g. this in the Publisher UI in Houdini: image

Just so that each has their own 'defaults' for the publishing.

Additional context:

I'm a bit at loss what the best approach is here @iLLiCiTiT @antirotor @dee-ynput - ideas are welcome.

This may be related to 'redesigns' of the publisher UI or new features for it - but I think it'll always be hard how to expose this without having "presets" maybe or without having a lot of code of course managing each of these unique defaults/presets.

iLLiCiTiT commented 1 month ago

Wouldn't that be solved by having option to return different attribute definitions per instance? Because I think that's what is next publisher backlog task I have.

That would also mean that the publisher plugin has to explicitly define instance attributes, based on his logic. That will be families based for backwards compatibility, but can be arbitraty. In that case you don't have to care about families as it can be based on something else on created instance (not families). Not sure why you need 3 creators? But you would not need 3 publish plugins for that.

Note: I don't know when I'll get to publisher tasks, as now I'm focusing on webactions.