Clone Control Panel - save images?
811 7 2-
- eikonoklastes
- Member
- 333 posts
- Joined: April 2018
- Online
-
- mtucker
- Staff
- 4444 posts
- Joined: July 2005
- Offline
No, clones are meant to be interactive renders like in the viewport in your current Houdini session. There is no way to save the resulting images to disk as husk is able to do. However we do have it on the roadmap to allow you to "snapshot" clone renders and preserve them in the render gallery. But the AOVs will al be saved to a single EXR in a Houdini-chosen location, just like snapshots of viewport renders.
-
- eikonoklastes
- Member
- 333 posts
- Joined: April 2018
- Online
Thank you for the clarification. That is an unfortunate limitation. Having simultaneous live per-shot previews is a pretty niche situation for me. It's a nice-to-have, yes, but I'm not really sure what value it adds as a practical tool.
When I'm working on a shot, I'm generally pretty happy to work on just that shot, i.e. independently set up the camera, lighting, materials, etc. for that shot, and preview it in Karma in the viewport - what Solaris has been doing since its inception.
Don't get me wrong, I do see some value in — as an example — live-previewing an object in different lighting, or with different materials, but again - that's pretty niche for me. Is this something that was RFE'd a lot?
I was hoping it could serve as a Render Queue Manager, but since it cannot save a file, that hope ends immediately there.
As an aside, could we then get a command in the Render Gallery to save out all images? Surely the output path can be stored with the image as metadata, and then be used to write the images out?
When I'm working on a shot, I'm generally pretty happy to work on just that shot, i.e. independently set up the camera, lighting, materials, etc. for that shot, and preview it in Karma in the viewport - what Solaris has been doing since its inception.
Don't get me wrong, I do see some value in — as an example — live-previewing an object in different lighting, or with different materials, but again - that's pretty niche for me. Is this something that was RFE'd a lot?
I was hoping it could serve as a Render Queue Manager, but since it cannot save a file, that hope ends immediately there.
As an aside, could we then get a command in the Render Gallery to save out all images? Surely the output path can be stored with the image as metadata, and then be used to write the images out?
Edited by eikonoklastes - Feb. 7, 2024 01:13:43
-
- Jonathan de Blok
- Member
- 253 posts
- Joined: July 2013
- Offline
It's a bit of a detour but I had something for this in the works, the lack of some proper API calls for this makes it depended on the UI and a bit tricky.
You can run the code below if there is:
-A clone that has produced output (100% completed)
-Output from that clone being shows in the gallery
Its saves all AOVs for clone snapshots to $HIP/CloneOutput
And to state the obvious.. The code below is not something you want run in production
You can run the code below if there is:
-A clone that has produced output (100% completed)
-Output from that clone being shows in the gallery
Its saves all AOVs for clone snapshots to $HIP/CloneOutput
And to state the obvious.. The code below is not something you want run in production
import hou from datetime import datetime from pathlib import Path from time import sleep import hdefereval @hdefereval.do_work_in_background_thread def save_all_AOVs(): print("init") yield for clone in hou.clone.clones(): if clone.imagePath() and clone.percentComplete()==100: for aov in clone.availableAovs(): clone.setDisplayAov(aov) yield sleep(0.5) snapshots=clone.renderGalleryDataSource() if snapshots!=None: snap=clone.renderGalleryItemId() if snap: snapshots.setLabel(snap, aov ) cam=Path(clone.cameraPath()).name lop=clone.lopNode().name() frame=hou.text.expandString(clone.frameExpression()) if not frame: frame=str(int(hou.frame())) tmpfile = Path(hou.text.expandString("$HIP")) / "CloneOutput" / f"{lop}_{cam}_{aov}_{frame}.exr" snapshots.prepareItemForUse(snap) try: f=hou.node("/img/comp1").createNode("file") membuf= snapshots.filePath(snap) #clone.imagePath() f.parm("filename1").set( membuf ) tmpfile.parent.mkdir(exist_ok=True, parents=True) f.saveImage(tmpfile.as_posix()) f.destroy() print(f"{aov}: {tmpfile}") except: pass yield yield print("Done!") save_all_AOVs()
Edited by Jonathan de Blok - Feb. 7, 2024 08:19:54
More code, less clicks.
-
- mtucker
- Staff
- 4444 posts
- Joined: July 2005
- Offline
One of the big use cases we see for clones is having a single local clone that is exactly following the current session. i.e. Having a background process doing your continuous karma interactive render of your whole scene, while you work in the OpenGL viewport. So I do think you might find that style of cloning useful. Especially if you have access to a render farm so that interactive karma render could be running on a different machine...
Once the clone can be "snapshotted", you can already RMB-click on a snapshot in the gallery and say "open in file browser" which takes you to the image on disk (render gallery entries are just exr files on disk). What I was saying is basically that the render product name will be ignored because the full generality of what husk can do with this information is a lot more than we would want to try to manage just because the user hits "snapshot" (generating and trying to display 100 separate exrs in the snapshot gallery would be a UI nightmare).
So no, this isn't a render queue, and if that's what you're looking for clones aren't the answer. For what you're looking for, what is missing from the current ROP based workflows (just hit Render in Background on a USD Render ROP when you want to generate a non-updating test render)?
Once the clone can be "snapshotted", you can already RMB-click on a snapshot in the gallery and say "open in file browser" which takes you to the image on disk (render gallery entries are just exr files on disk). What I was saying is basically that the render product name will be ignored because the full generality of what husk can do with this information is a lot more than we would want to try to manage just because the user hits "snapshot" (generating and trying to display 100 separate exrs in the snapshot gallery would be a UI nightmare).
So no, this isn't a render queue, and if that's what you're looking for clones aren't the answer. For what you're looking for, what is missing from the current ROP based workflows (just hit Render in Background on a USD Render ROP when you want to generate a non-updating test render)?
-
- eikonoklastes
- Member
- 333 posts
- Joined: April 2018
- Online
mtuckerYes, that does sound pretty useful. Thanks again for clarifying.
One of the big use cases we see for clones is having a single local clone that is exactly following the current session. i.e. Having a background process doing your continuous karma interactive render of your whole scene, while you work in the OpenGL viewport. So I do think you might find that style of cloning useful. Especially if you have access to a render farm so that interactive karma render could be running on a different machine
mtuckerIt's an unwieldy user experience when managing multiple shots and frame ranges, in that you cannot get a high-level overview of the settings of all your shots that you want to queue up.
...what is missing from the current ROP based workflows (just hit Render in Background on a USD Render ROP when you want to generate a non-updating test render)?
Much as I shudder to use 3ds Max as an example of what I'd like to see, their Batch Render dialog provides a dead-simple but high-confidence UX when queuing up multiple shots.
Here is a screenshot of it, albeit unpopulated, but the column headings should give you an idea of what it will look like filled up:
I emphasized "high-confidence" earlier, because before hitting the Render button for an overnight (or over-weekend) render, I can at-a-glance tell exactly what to expect from all the shots I am rendering, and I can even queue up the same camera with different frame ranges, something that Houdini doesn't do (not without separate ROPs anyway).
With Houdini, the experience is low-confidence, because I have to manually inspect each ROP to ensure correct frame ranges - this gets extremely tedious when doing rapid iterations with several quick renders. I have taken to writing down manually a node comment on the ROP what frame range that that is outputting, because I cannot see it anywhere without first selecting the ROP and then looking at the Parameters pane. If I need to re-render a subset of that frame range, or change it, I have to again manually update that comment.
With the separating of the Karma Render Settings and USD Render ROP nodes, this gets to be even more fiddly work, because now I have two nodes per shot to check for settings.
I know how to queue these up with TOPs, but that does not address the core issue of seeing all the critical settings of your render queue at a glance.
That's basically what I'm looking for. While Houdini can queue up renders, I just wish it was a more user-friendly and higher-confidence experience.
Edited by eikonoklastes - Feb. 8, 2024 05:34:34
-
- Jonathan de Blok
- Member
- 253 posts
- Joined: July 2013
- Offline
Besides the batch thing, even a single shot can get of the rails quite quickly during development.
The Karma ROP has a 'render to disk' and a 'render to mPlay' option, both not nice for doing iterative renders in a comfortable way.
The gallery has a 'render in background' button but it's tied to a viewport, so that's a very loose thing with very 'low confidence' of what you're going to get as eikonoklastes puts it. It's quite easy to accidently change a viewport, jump out of a camera or even mess a camera up.
The clones can be locked to a certain lop/cam/frame which is great, but they don't have a render button. They are either on pause or start to render every time you touch a node. Which is nice in demos but is quite a waste in energy and money with power-hungry GPUs and such. Needing to toggle the pause button for this is quite an annoying UX.
As a stop gap I made something [www.sidefx.com] that adds a 'render' button to the clone panel that add the functionality of a 'single shot' render-on-demand so I can use a clone as a locked-in background render. The only issue is that AOVs are a bit clunky to handle since the clones only deliver one AOV to the gallery at a time.
So what we need it a simple 'render' button that renders to the gallery using an explicit set, or sets, of camera/lop/frame and only renders when you tell it to. Ideally this is added for the 'normal' render and well as for the clones so you can check multiple shots/settings with a single click render action.
I know it's not a sexy as interactive viewport renders, which certainly have their place, but they are just too volatile and hard to work with if you need a locked in shot.
btw: @eikonoklastes if you need to control a lot of shots, have a look at https://jdbgraphics.nl/script/prosequencer-2-0-houdini/ [jdbgraphics.nl] you can visually control ranges and what not and use a single ROP and have ProSequencer control it for each shot.
The Karma ROP has a 'render to disk' and a 'render to mPlay' option, both not nice for doing iterative renders in a comfortable way.
The gallery has a 'render in background' button but it's tied to a viewport, so that's a very loose thing with very 'low confidence' of what you're going to get as eikonoklastes puts it. It's quite easy to accidently change a viewport, jump out of a camera or even mess a camera up.
The clones can be locked to a certain lop/cam/frame which is great, but they don't have a render button. They are either on pause or start to render every time you touch a node. Which is nice in demos but is quite a waste in energy and money with power-hungry GPUs and such. Needing to toggle the pause button for this is quite an annoying UX.
As a stop gap I made something [www.sidefx.com] that adds a 'render' button to the clone panel that add the functionality of a 'single shot' render-on-demand so I can use a clone as a locked-in background render. The only issue is that AOVs are a bit clunky to handle since the clones only deliver one AOV to the gallery at a time.
So what we need it a simple 'render' button that renders to the gallery using an explicit set, or sets, of camera/lop/frame and only renders when you tell it to. Ideally this is added for the 'normal' render and well as for the clones so you can check multiple shots/settings with a single click render action.
I know it's not a sexy as interactive viewport renders, which certainly have their place, but they are just too volatile and hard to work with if you need a locked in shot.
btw: @eikonoklastes if you need to control a lot of shots, have a look at https://jdbgraphics.nl/script/prosequencer-2-0-houdini/ [jdbgraphics.nl] you can visually control ranges and what not and use a single ROP and have ProSequencer control it for each shot.
Edited by Jonathan de Blok - Feb. 8, 2024 03:53:19
More code, less clicks.
-
- eikonoklastes
- Member
- 333 posts
- Joined: April 2018
- Online
Jonathan de BlokThank you kindly. That looks pretty good. I generally try to stay with vanilla Houdini as much as possible, but I just might dip into this.
btw: @eikonoklastes if you need to control a lot of shots, have a look at https://jdbgraphics.nl/script/prosequencer-2-0-houdini/ [jdbgraphics.nl] you can visually control ranges and what not and use a single ROP and have ProSequencer control it for each shot.
-
- Quick Links