I guess what we would be interested in is some sort of AYON Create → Houdini TOPs options that could control the publish node (possibly with TOPs variables). It could be something like “here are 55 building variants that we’ve asked for in the project” or some tray publishing version like “here are 33 variants for the pecan tree item for this library project.”
There’s also the scenario of “here are a bunch of fbx files with textures that need to be published as USD files for a library.” Bane of my existence but way nicer with TOPs automation.
Is that how other people are thinking about automation in Houdini? How does that fit into AYON world? Does this already exist, and I haven’t gotten there yet?
Technically this ROP could be used in a TOPS network with the input attributes for the target product type and variant updated by the TOPs network as it renders. Like using TOPs variables assigned to some of its parameters.
There is work being done on pinpointing an improved publishing API at the AYON core - which could make it easier to ingest it anywhere without conforming to the usual required needs of a host integration. Being able to just say “this file (or set of files) is something I want to publish” with a few lines of code would make e.g. a great entry point for TOPs. The tricky thing there is that we have an ecosystem of ‘validations’ and ‘secure consistent publishes’ and are investigating how much we should let go to support simple API for these free-form publishes or whether there’s need (and possibility) to still allow those to conform to the regular validations without getting in the way. So that even if you publish a model through TOPs it still adheres to the rules of a model product type for example. I’m not sure where to link best to for this point though.
Nonetheless - a lot of these are investigations and prototypes of what could serve the Houdini users best in the long run. As such, any examples you could set up - even if almost like a node-based ‘pseudocode’ of how you’d like it to work or ideas you have are more than welcome.
However, likely best suited for a separate thread than this one on here We might even want to separate your post and my reply into the spun off thread then to give it a clear topic title here.
@mustafa_jafar should we separate? and did you have anything to bring to the table here?
Low Level publishing API: Personally, This one has two meanings as shown in point 3 and 4 above,
Dynamic Runtime Creator: Publishing from code pyblish way which just runs the AYON publish workflow from code. (you still need to create publish instances and publish through pyblish api which runs the pipeline plugins, this not only runs the validations but also keep the current features e.g. extract review will still work with render instances.) I like to think of it like using tray publisher but from code.
Anyways, here’s we used it in TOPs.
Low Level AYON publish library: which as far as I can tell is only about registering the files in the DB and move the files to their publish location with the proper naming. this logic lives in the pipeline plugin integrate.py which uses ayon_api.operations.OperationsSession to register the files.
Thanks for this, both of you. I’m trying to understand the Houdini and ingest/editorial sides of the process which feel more untamed by their nature. I appreciate the primer and will hang out in the PRs more often.
We currently have a TOPs setup that creates USD files, thumbnails, proxies, and turntables and dumps them to Das Element. I think the Dynamic Runtime example will work well within this setup. I’ll let you know what I run into and share my results.
We might even want to separate your post and my reply into the spun off thread then to give it a clear topic title here.
