Max: TyCache Family Enhancement

[moonyuet]

Changelog Description

This PR introduces several small enhancements on TyCache Family

1. Code tweaks to support multiple export-particle operators with different names in both TyCache and TySpline Family.

2. Supports the export mode of tyCache Splines (Split tycache families into two, one is tyCache and the other is tySplineCache)

3. Optional Validator for frame range in both TyCache and TySpline Family

4. Add Loader with tySplineCache modifiers for tySpline Family

Additional info

Template path naming has changed so please ensure you have the updated settings with updated addons. Check with the following project settingto see if it has the aligned settings with the screenshot below Openpype: project_settings/global/tools/publish/template_name_profiles

AYON: Make sure your addons are at the right version. Core: v0.1.5, Max: v0.1.4, Openpype: 3.17.7-nightly.7 And make sure you have the tycache template path set in Anatomy Presets

***This can be ready for review after the adjustment on the representation data.

Testing notes:

1. Launch 3dsMax via launcher
2. Create TyCache/TySpline Family with tyFlow object which has events and export-particle operators with different names
3. Publish
4. Make a new scene
5. Load the cache back

[ynbot]

Task linked: OP-7406 3dsmax: tyCache enhancements

[moonyuet]

Will close the related PR https://github.com/ynput/OpenPype/pull/5901 on removing creating TyCache Object after this PR has been approved.

[moonyuet]

Note: Im not an TyFlow expert so maybe some guidance from you @moonyuet also needed when speaking of tyFlow graph setup too?! Im really not sure if both Events should have Export Particles nodes because there arent any for producing tySplines ?! So pls also inspect my scnr grab of my setup nodes too...thx

Not sure if I understand the question correctly. But if you want to produce tySpline, you need to have the spline path nodes created. (Maybe I can also add validation for that) And then the export particle nodes would use tycache(spline) instead.

[moonyuet]

I made an updated commit on the PR, but I still left it to draft as I am not quite certain about several things related to representation. The scenario is I have two export-particles operators in tyflow node editor, they are being exported with different representation but with same subset. If the users have tyc files from multiple operators to be published, the loader would be filled by copyfile with different representation names. I am trying to create one representation for the outputs from multiple operators, but it seems the integrate.py deosn't allow me to and error out.

I am thinking about if it deserves to write another creator just for this family, although it is from the external plugins. It acts relatively different from other instances. Unlike for just selecting the objects and put it into container, we need to select the tyFlow objects into the container and access layers of layers of sub anim to find the operators node. (I hope it won't confuse you).

Or should we, for current stage, set limits for operators to be published? @antirotor , any thought?

[antirotor]

I am trying to create one representation for the outputs from multiple operators, but it seems the integrate.py deosn't allow me to and error out.

This is indeed the limitation of current representation system we have. But good news, we have finally green light to change it!

Just explanation what is the current limitation:

representation can have either one file files = "file.ext" or list of files files = ["foo.001.ext", "foo.002.ext"] but with the list, it expects that it is real sequence. In other words, you can't do files = ["texture_diffuse.tif", "texture_specular.tif"] for example. For this to change, we'll need to change how integrate.py works, maybe handle some loaders across DCCs, provide some validators for product type that should never ever recieve list of files that are not a sequence. And maybe even have some way for user to be able to specify if it is a sequence or not. Like in the case of reference images files = ["ref001.jpg", "ref002.jpg"] that are related in content, are not sequence and we can't automatically know.

[moonyuet]

I am trying to create one representation for the outputs from multiple operators, but it seems the integrate.py deosn't allow me to and error out.

This is indeed the limitation of current representation system we have. But good news, we have finally green light to change it!

Just explanation what is the current limitation:

representation can have either one file files = "file.ext" or list of files files = ["foo.001.ext", "foo.002.ext"] but with the list, it expects that it is real sequence. In other words, you can't do files = ["texture_diffuse.tif", "texture_specular.tif"] for example. For this to change, we'll need to change how integrate.py works, maybe handle some loaders across DCCs, provide some validators for product type that should never ever recieve list of files that are not a sequence. And maybe even have some way for user to be able to specify if it is a sequence or not. Like in the case of reference images files = ["ref001.jpg", "ref002.jpg"] that are related in content, are not sequence and we can't automatically know.

For my case it is more like <InstanceName>_<operator>__tyPart_<frame>.tyc, it is published with some other template profile name. You can find the reference below(Lazy to type)

[mkolar]

@moonyuet we'll need AYON port before merging please

[moonyuet]

Quite a big PR - didn't go through it in too much detail since it's 3DsMax and TyFlow - two things I know close to nothing about. Just commented on stuff that stood out to me on a quick read. Likely best for someone from the Ynput team to go through in more detail instead.

I have a feeling that it's a bit overcomplicated for some reason, but I can't put my finger on it why I feel that way because maybe it's needed for what you're trying to do.

I can see your point. I can't find the best way to get the multiple operators to be exported due to the limitation of tyflow API (maybe the 3dsmax api limitation too). I hope tyFlow API can eventually improve the API so that I dont need to implement some new stuff which is a bit over-engineered for the host to store the related data.

[dee-ynput]

closing: won't do - implemented in AYON (https://github.com/ynput/ayon-3dsmax/pull/1)