Let’s discuss the idea of having a Houdini cache node
So, How do you guys imagine it ? and what are your needs ?
There are a lot of questions that come to my mind.
What would be special about it ? I mean why not using the vanilla houdini cache node
Should it exist as a product-type that’s managed by the Publisher UI ? or should it be an HDA/OTL ?
Should the cache be versioned ?
Should it be registered in DB ?
Should the cache be shown in ayon loader ?
Should it be possible to submit it to render farm ?
How should the cache files be managed, deleted ?
for discussion I’m including images of our current geo cacher. it allows you to write/write over/ version up geo. it allows farm submission. it allows building a corresponding rop network of links using fetches to submit multiple to farm with dependencies linking intact. It also has some proxy mode features to write out cut down versions at the same time.
and once you update the read side and youre happy with it you can select the node and ‘publish’ from it to register the loaded results into the DB and hardlink to publish folder and update paths accordingly).
those images attached in reverse order. so the last one is the main one. I’d be happy to contribute a version of this to the collective good as we start to explore Ayon. so maybe we can just feed the open source community with this and get ayon’s geo cacher to just match ours.
and publishing the path of the geo in our system doesnt release it to downstream though. it just lets you include it in what we call an 'fx_houdini_element" which is an otl in a subnet that does become available downstream to lighting. that was you can wrap some other stuff like attribute or time manipulation, or shaders or whatever into it.
We have actually a pull request made for farm caching submission(Houdini: Farm caching submission to Deadline by moonyuet · Pull Request #4903 · ynput/OpenPype · GitHub) in github. You can do somd test on it if you are interested.
Our current process is adding toggle button “farm” in the families and it would submit to the farm once enabled and it would be published in the related family folder once the render is finished.
Currently we haven’t supported usd family yet.
I think it’s doable to make custom node for the farm caching. And for the writing over nodes, I think we should develop a separate nodes for farm caching since I am not sure writing over would affect the way the ayon system works(it is possible to add the toggled button for publishing without increment).The current farm caching submission would upversion to publish and save the cache workfile to the related family folders after.
FYI, this exists in OpenPype/AYON as well by publishing along the workfile and having the submitted render use that published workfile instead. I know it does for Maya, I’m not sure if it’s currently implemented for Houdini too.
So your secufile would be render using the published workfile within AYON instead of rendering the artist’s workfile.
It just that the artist name his render how he want by changing the name of the render node $OS, but if the artist doesn’t change it, the node ask if it should continue
Adding support for USD is a must IMO. Also adding support for USD stiching so we can export through the farm but then the separate USD files must be stitched into a single file to be usable. H20 will facilitate this process.
There are two ways to export (animated)geometry to USD in Houdini. The first one is to simply use the USD Export SOP node directly inside the SOP network used to build the geometry. That’s pretty straight foward.
The second way is to use a SOP import node in a LOP context, or a SOP Create or a SOP Modify. The advantage of this is you can test your output in context before exporting it. For example, in USD, it is common to export just the animated point positions of a mesh without exporting the topology, unlike what we used to do with Alembic. So if a CFX artist works on the cloth simulation of a character, they probably want to export the animated point positions of just the cloth meshes, and leave untouched all other meshes of the hierarchy. So before they export their work, they want to test that applying their layer on top of the animation layer will produce the desired results. This can easily be done in the LOP context with something like this.
so the last one is the main one. I’d be happy to contribute a version of this to the collective good as we start to explore Ayon. so maybe we can just feed the open source community with this and get ayon’s geo cacher to just match ours.