Houdini: 20.0.547
Houdini Addon: 0.2.11
Heyall,
I am just wondering what the correct procedure is to create versioned render publishes from Houdini. I have created a mantra_ropMain item within the publisher and I can render the frames locally but when I publish, it doesn’t seem to recognise that I am publishing renders.
A notable change from default is to change the driver from the local drive location that holds the .ifd files back to “mantra” as I cannot get it to even make frames unless mantra is set as the driver. I am also curious if there is a way to publish without having to recache and rerender the output nodes or if this is intended to ensure that the current workfile is what produced those render versions.
Cheers,
Stephen
Are you using Deadline? Because I believe the render logic is currently designed to render on the farm in deadline - and with that addon disabled may just appear to be doing nothing and indeed skip it completely.
You may be interested in this upcoming PR/feature where local rendering for Houdini gets implemented.
Ah yep, that would almost certainly do it. Thank you for the clarification. If that is the case, is there currently a way to test or triage sims and frames before publishing as it is not unheard of that a worker produces a dud frame or something breaks in the sim etc? I guess it would be nice to be able to run a job through DL without it publishing then publish the existing work files. What is the expected artist workflow to account for these sorts of things currently?
I also wonder how this impacts Shotgun versioning as it appears that the whole process is locked in once you hit that publish button so you would be possibly producing bad versions. This also wraps around to quality assurance before publishing.
Cheers,
Stephen
A lot of AYON / OpenPype has been designed around creating published versions - of which some may very well be intermediate versions. Whether that works for your workflow of course can be debatable. But in a lot of cases the export itself is quite tied to the integration directly.
Having a step in-between where one can ‘validate the result’ or just have the ‘publish/integrate’ step separate has come up before. (see linked discussions below)
Anyway, I know this has come up quite a bit. @fabiaserra has been quite verbal about that - and Fusion/Nuke integrations have something along those lines where publishing can “publish existing frames” - so it does not trigger the actual render, but just publishes what had been previously rendered. This workflow could be very well transferred to Houdini so that publishing would just mean - take my existing caches/outputs and publish those instead. @mustafa_jafar / @milan might have something to say about that.
Some relevant discussions on Discord:
Haha indeed I’ve been quite vocal about this issue (and others 
), also here there’s some extra context Enhancing Houdini integration and also in a bunch of different PRs. We encountered the same limitations you are seeing @StephenScollay months ago once we started using OP and instead of painfully redesigning the whole integration (which would certainly be possible but production time constraints make this very hard) we decided to work in a very vanilla Deadline/Houdini way and only use a very thin layer of OpenPype that I had already created to be able to do batch publishing (Batch publishing (ingest) - #9 by fabiaserra) so they can explictly publish what we produce through Deadline/Houdini as a post-process after the artist has validated it and artists were much happier with this approach.
In order to do that, we mostly make use of the Deadline ROP submitter (Houdini — Deadline 10.3.2.1 documentation) and we set a bunch of defaults on the vanilla node parameters through Houdini OnLoaded/OnCreated python script events (Python script locations) to reduce artist mistakes (i.e. enable split of extract/render on render nodes, default paths where cache/renders live, default to checkpoint, disable TX generation on Arnold…).
Then I created this custom HDA ROP called “OP Publisher” which basically wraps the functionality of this module I created that allows us to publish anything in the farm OpenPype/openpype/modules/deadline/lib/publish.py at release/alkemyx-next-minor · fabiaserra/OpenPype · GitHub where they are able to select the destination Asset, Task, Name of Subset, Family (render, point_cache, camera…), add a comment and set the different paths of the representations of the subset.
The HDA has some simple code like this to facilitate the parameters to be filled automatically on connection with other ROP nodes so they don’t need to type anything in most of the cases:
In the future I’d rather make AYON collect Houdini vanilla nodes as publish instances so I can reuse some of the validators and other features but as I said, it’s hard to find the time to do those things, specially when you already have a working system artists can work with…
2 Likes
Also regarding your comment on Shotgrid publishes, we ONLY publish versions in Shotgrid of things that we add the shotgridreview tag on the representation so we avoid adding too much noise. At the moment we only add that tag to render, reference and review families
Fabulous, greatly appreciate the explanations guys and certainly some stuff I will need to look into. Making these sorts of changes myself might be a bit interesting as don’t really have the expertise to implement this sort of stuff (I am a relatively green wrangler/Tech Assist) but I’ll give it a crack and find out.
On that note, we’ve been struggling to find someone to help with implementing these sorts of systems. Would you guys have any suggestions for this keeping in mind time zones and budgets of a smaller Australian studio?
Your best bet might be reaching out to @Ynput team and see if you could pay credits to get support from them and perhaps fund some of their development.
Alternatively, for now without spending any dev efforts I would probably stick to the vanilla implementation of AYON and get used to all the quirks and gotchas so you can support your team with any questions and keep posting here all the things you encounter you’d like to change so the community is aware and can perhaps chip in to try work on something together
3 Likes
