Skip to content

Conversation

@moonyuet
Copy link
Member

@moonyuet moonyuet commented May 30, 2025

Changelog Description

This PR is to implement the publishing aspect for vdb product type. It is only supported for the vdb publish from TyFlow.

Solve #48
TODO List:

  • Refactor instance.data["operator"]
  • Refactor on the product name based on templated profile product name like we did in Houdini

Additional review information

  • As vdb publishes can be supported by multiple external party plugins, so some of the codes are structured to make the implementation of vdb published from other parties easier to be integrated in the future.
  • Make sure you included Export VDB operators in the tyflow editor, otherwises nothing shows up for publishing in the insrance container
  • Users need to add vdb as product type into the ayon+settings://core/tools/publish/template_name_profiles/6/product_types
    image

Testing notes:

  1. Create VDB (TyFlow)
  2. Publish

@moonyuet moonyuet requested a review from LiborBatek May 30, 2025 09:45
@moonyuet moonyuet self-assigned this May 30, 2025
@moonyuet moonyuet added type: enhancement Improvement of existing functionality or minor addition sponsored This is directly sponsored by a client or community member labels May 30, 2025
@moonyuet moonyuet linked an issue May 30, 2025 that may be closed by this pull request
@moonyuet moonyuet marked this pull request as ready for review May 31, 2025 04:34
@moonyuet moonyuet requested a review from antirotor June 3, 2025 05:37
@moonyuet
Copy link
Member Author

moonyuet commented Jun 3, 2025

@antirotor guess the representation trait you implemented in core addon would be super helpful for the implementation of this product type as there should be different templates used for publishing if we have some different vdb extractors (other than tyflow one) included in the future.

@BigRoy
Copy link
Contributor

BigRoy commented Jun 3, 2025

guess the representation trait you implemented in core addon would be super helpful for the implementation of this product type as there should be different templates used for publishing if we have some different vdb extractors (other than tyflow one) included in the future.

Why would it need different templates?

Comment on lines 59 to 62
# make sure the tyflow vdb extractor would not be triggered
# when the non-tyflow vdb workflow is adopted by the user
# in the future
"is_tyflow": True,
Copy link
Contributor

@BigRoy BigRoy Jun 3, 2025

Choose a reason for hiding this comment

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

If that ever happens, that would be a different product type? Because this one is tyflow_vdb? It just feels like we're overcomplicating code here for a non-existing use case yet (since there isn't any other VDB extractor yet?)

Copy link
Member Author

Choose a reason for hiding this comment

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

If that ever happens, that would be a different product type? Because this one is tyflow_vdb? It just feels like we're overcomplicating code here for a non-existing use case yet (since there isn't any other VDB extractor yet?)

I am thinking the approach to be less complicated. It's just that the tyflow vdb export(select the target exporter node from the tyflow editor) is totally different from the general vdb export(select the target asset from the max editor).
I am thinking if it is possible to just implement the vdb product type in the creator but with quite specific creator identifier(as if what we did in Houdini for abc/bgeo pointcache).

Copy link
Contributor

Choose a reason for hiding this comment

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

We recently did something similar with 'render' creators in Houdini. Those are now all render product type, regardless of renderer. It's this one: ynput/ayon-houdini#214

"""Creator plugin for TyFlow VDB."""
identifier = "io.ayon.creators.max.vdb"
label = "VDB (TyFlow)"
product_type = "tyflow_vdb"
Copy link
Contributor

Choose a reason for hiding this comment

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

Note that a lot of VDB based loaders currently target the vdbcache product type, and hence will not allow loading this product type.

For example, these all target vdbcache product type.

ayon_maya/plugins/load/load_vdb_to_vray.py
ayon_maya/plugins/load/load_vdb_to_redshift.py
ayon_maya/plugins/load/load_vdb_to_arnold.py
ayon_houdini/plugins/load/load_vdb.py

"productName": f"{container_name}_{prod_name}",
# get the name of operator for the export
"operator": operator,
"productType": "vdb",
Copy link
Contributor

Choose a reason for hiding this comment

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

Pretty sure it's vdbcache in other hosts.

"label": f"{container_name}_{prod_name}",
"family": "vdb",
"families": ["vdb"],
"productName": f"{container_name}_{prod_name}",
Copy link
Contributor

Choose a reason for hiding this comment

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

Please do not override productName directly - this should really be targeting vdbcache product type from the get go... from the creator itself so that the product naming templates apply accordingly. @iLLiCiTiT thoughts?

Copy link
Member Author

Choose a reason for hiding this comment

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

Please do not override productName directly - this should really be targeting vdbcache product type from the get go... from the creator itself so that the product naming templates apply accordingly. @iLLiCiTiT thoughts?

if that's the case, we need to also change the similar variable to not override productName in tycache collector.

Copy link
Member

Choose a reason for hiding this comment

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

Don't know full flow, usually when this is needed then the product name template contains some key that is kept unfilled, e.g. {some_key} then create plugin returns the key value in get_dynamic_data as unfilled.

def get_dynamic_data(self, *args, **kwargs):
    return {
        "some_key": "{some_key}",
    }

With that you can fill the product name during collection phase.

@BigRoy BigRoy requested a review from iLLiCiTiT June 3, 2025 06:56
elif attribute == "ty_vdb_data":
node.modifiers[0].name = "AYON TyFlow VDB Data"
else:
node.modifiers[0].name = "OP Data"
Copy link
Member

Choose a reason for hiding this comment

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

Why "OP Data"?

Copy link
Member Author

Choose a reason for hiding this comment

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

It's the name of general container attributes for other product type. It would be renamed after the related PR for this issue as the backward compatibility needs to be implemented for this.

# in the future
"is_tyflow": True,
"publish_attributes": {
"ValidateTyVDBFrameRange": {
Copy link
Member

@iLLiCiTiT iLLiCiTiT Jun 9, 2025

Choose a reason for hiding this comment

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

This looks like out of the scope. Is the ValidateTyVDBFrameRange plugin ever showed in publisher UI? Because it looks like it is not, and you're using the "optional" plugin only to enabled/disable validation of instances based on "has_frame_range_validator".

If that's the true, then don't use Optional plugin, just add something like families = ["vdb_frame_validation"] filter there and add the family "vdb_frame_validation" to the instance (the family vdb_frame_validation is first random name that came to my mind).

if attr_values.get("has_frame_range_validator",
self.validate_tyvdb_frame_range):

instance.data["families"] += "vdb_frame_validation"
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
instance.data["families"] += "vdb_frame_validation"
instance.data["families"].append("vdb_frame_validation")

class ValidateTyVDBFrameRange(ValidateFrameRange):
label = "Validate Frame Range (TyFlow VDB)"
families = ["vdb_frame_validation"]
optional = True
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
optional = True

default_factory=BasicValidateModel,
title="Validate Frame Range (TyCache)"
)
ValidateTyVDBFrameRange: BasicValidateModel = SettingsField(
Copy link
Member

Choose a reason for hiding this comment

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

This should probably have only enabled in settings, the others will not affect anything.

@moonyuet moonyuet marked this pull request as draft June 30, 2025 10:05
class CreateTyVDB(plugin.MaxTyflowVDBCacheCreator):
"""Creator plugin for TyFlow VDB."""
identifier = "io.ayon.creators.max.vdb"
identifier = "io.ayon.creators.max.vdbcache"
Copy link
Member

Choose a reason for hiding this comment

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

This change means all existing instances won't be collected.

icon = "gear"

def get_publish_families(self):
return ["vdbcache", "tyflow_vdb"]
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't that "tyflow_vdb" be added during collection phase based on create plugin identifier instead?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

sponsored This is directly sponsored by a client or community member type: enhancement Improvement of existing functionality or minor addition

Projects

None yet

Development

Successfully merging this pull request may close these issues.

AY-7855_Exporting VDBs with the tyFlow "Export VDB"

4 participants