Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow creating more product types as USD with USD contribution workflow and better defaults. #144

Draft
wants to merge 11 commits into
base: develop
Choose a base branch
from

Conversation

BigRoy
Copy link
Contributor

@BigRoy BigRoy commented Oct 26, 2024

Changelog Description

Allow creating more product types as USD with USD contribution workflow and better defaults.

This must be used together with: ynput/ayon-core#973

Additional info

With this PR one can now create e.g. a modelMain and groomMain product as respectively model product type and groom product type. This is a start of separating what is product type definition families and what is creator or representation specific logic on e.g. how the publish itself works.

image

The idea is that a product type should not be 1:1 tightly coupled to a particular node inside the DCC, so that technically anything could publish a product type like model or pointcache which only consider the product type's validations (like a model must be static) but not care at all about e.g. Alembic properties being set up correctly on the Alembic ROP.

I personally think it'd be a good idea to start separating these further and prefix the families with their intent, so that the (non-prefixed) families are strictly for product type and no conflicts would ever occur down the line. So that e.g. family abc is still free to use as potential product type instead of using that for "Alembic ROP". We could e.g. differentiate more based on a prefix like driver/abc or rop/abc or node/AlembicRop (or whatever makes sense) but we could also have e.g. generic file specific validations like file/usd or certain media types. That way we can target e.g. a specific functionality regardless of how the host exports it. The creator would just need to specify the relevant families based on how the creator attributes are configured.

Testing notes:

  1. Use together with PR here: USD contribution: Set up different default values based on profiles ayon-core#973
  2. In Houdini, start publishing USD model, groom and look products, each should work with their own validations but also with the asset contribution workflow. Each product should also have different defaults and target the right 'default layer'
  3. Regular model publish in Houdini should also still work.

@BigRoy BigRoy added the type: enhancement Improvement of existing functionality or minor addition label Oct 26, 2024
@BigRoy BigRoy self-assigned this Oct 26, 2024
Copy link
Contributor

@MustafaJafar MustafaJafar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey this works!

Here are some snippets.
image

Loaded Variants:
image
image

Loaded Render: (Rendered one frame as a review for look we don't have review)
image

Render (20 frames): (Here's the generated review of one of the two renders)

RB_Axel_Steelblade_Render_UsdrenderBlueCyan_Beauty_v002_h264.mp4

Also, this makes me feel that supporting review using opengl node in lops can be useless as my materials looked way off.
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement Improvement of existing functionality or minor addition
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants