-
Notifications
You must be signed in to change notification settings - Fork 10
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
base: develop
Are you sure you want to change the base?
Conversation
…gRoy/ayon-houdini into enhancement/more_usd_products
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey this works!
Loaded Render: (Rendered one frame as a review for look we don't have review)
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.
…enhancement/more_usd_products
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
andgroomMain
product as respectivelymodel
product type andgroom
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.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
orpointcache
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 likedriver/abc
orrop/abc
ornode/AlembicRop
(or whatever makes sense) but we could also have e.g. generic file specific validations likefile/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: