Hello @Ronald_Anzenberger
Thanks for reaching out, I cannot share an ETA on its support but I linked your request to already present internal ticket.
1 Like
That’s a very important deal. I’m avoiding rendering on AWS right now because that.
With rusk we can render without using a Houdini license, and thus reducing a lot the costs.
We use a modified version of the Deadline ROP. I will post it here soon.
1 Like
Hi Mois,
thank you very much in advance and also thanks to @Glacierise for initiating and sharing this.
Here it is. I asked in another thread, if it is fine license-wise, I will post this on GitHub as well.
It is untested, because I quickly cleaned some of our customizations.
houdini_submission.zip (63.6 KB)
Edit: oh you need the modified hda as well. I will post this in a bit.
1 Like
On other thing: what about Karma licenses??
@mois.moshev thanks for the ROP. I’m just wondering what it is I need to plug into that ROP? I tried a usdrender ROP and a fetch ROP which pointed to a USD render rop in STAGE and in both cases hython was called and rendered the scene. I did tick “Export USD Locally”. What am I missing?
Also, it seems I need to ad a houdini verison (19.0.xxx) specific executable into the houdini.param file for the plugin to find hython.exe now (it won’t use the major version exe) - but that might be by your design.
Indeed this stuff is implicit in the code. I will expand this, but in the meantime, the submitter fetches the first Render Product with type “raster”. Here is the relevant bit:
rule = hou.LopSelectionRule()
rule.setPathPattern("{ usd_istype(0, @primpath, 'RenderProduct') } & { usd_attrib(0, @primpath, 'productType') == 'raster' }")
lopNode = node.parm("loppath").evalAsNode()
if lopNode is not None:
outputFile = lopNode.stage()\
.GetPrimAtPath(rule.firstPath(lopnode=lopNode))\
.GetAttribute("productName")\
.Get(hou.frame())
So in the lop network, you need to add a render product
Realized I missed information here.
You need to create a USD ROP node, which points to the lop path to render. Connect this to Deadline.
In the lop network, the first render product is used. The “Product name” field shall contain the render path. For me this is roughly the correct usd workflow.
@mois.moshev I still couldn’t make it work. when you say USD ROP, are you talking about the USD Render ROP (I mean I suppose because how else would you set the render delegate). I did have a “Product name” set to a path (and file) because I set this up using the “karmarendersettings-LOP”.
I also suppose we should wait a little until the licensing situation has somewhat cleared/improved.
Here is a USD rop
What is unclear about the licenses? Isn’t it the case that you need houdini_engine for the export jobs, and karma for the USD jobs?
Submitting in such way will require a houdini license, since houdini must open the hip to generate the final USD file for rendering. But that’s just waste of resources, since it’s just a matter of writing down to disk the final USD and render from there, directly from husk, so we would need just a karma license, which is much cheaper. As a bonus, it’ll be a bit faster too, because instead of the route houdini->husk->karma, it would be just husk->karma.
Well, in the submitter you can select “Local export” in the Husk tab. I have not tested this workflow, though it will probably work. It is the same as exporting ifds or vrscenes.
I haven’t tested the submitter, but UBL still lacks Karma licenses, so that won’t help much when rendering on AWS.
Oh ok, I was not aware of this. We have postponed AWS rendering for the time being, more focus on on-prem.
Well, even on-prem, karma licenses are cheaper, but it’s easier to manage since you don’t need to wait 10 years for the guys at thinkbox-aws to update UBL.
I think we’re doing that for performance reasons - not to lock up the artist workstation for long while submitting, if the scene is big. It’s worth testing the local export for smaller scenes though, will do that, thanks!
ok, it’s submitting, the local export also seems to work and it is also rendering on the farm. the only thing that is not working is saving the correct (rendered) file that should be coming from the renderproduct. I am using a karmasettings LOP to set this up (which is pretty much automatic), I can see the renderproduct and the path etc. but it is trying to save the rendered image into the same directory as the usd (usd_path\render\3D_render/usdfilename.framenumber.exr) and failing at it.
Also, I am not sure how one would set a different render-deligate, or is this just for karma for now?
Ok interesting. I suppose the render path is taken from elsewhere. Oh btw I guess you are using the HuskStandalone plugin without modifications? It is probably selecting the path from another node, because I remember seeing render/3D_render in the code. Somehow you need to pass the correct output name to husk. Let me check our modifications.