The Karma ROP has a checkbox which is labeled "Render All Frames with a Single Process". What exactly does it do under the hood?
Documentation "Render all frames in a background process. Default is off. This allows continued interaction with Houdini while the render process runs.
To render multiple frames, the render process renders an image then advances the time on the scene and renders the next image (just like how the Solaris viewport plays back animation). If there is a lot of data shared between frames, this can render significantly faster compared to rendering a single frame per process."
When checked it renders out my frame sequence in 4 seconds per frame, unchecked it's around 20 seconds per frame, so why is this unchecked by default? Any drawbacks or situations where using this is a bad idea?
Edited by Jonathan de Blok - Feb. 29, 2024 02:45:19
I think it avoids doing pre-render stuff for each frame again and again, regardless of whether they are animated or not, so that by switching it on it goes 'aha, all this stuff stays the same, cool cool'. It's like a postman who would stop at every house, switch off engine, lock doors, deliver, unlock doors, get in, wipe off some dirt, start the engine again, etc, vs getting out once and doing the round on foot for a while. As for downsides, I'm not sure but perhaps it avoids building up caches, general stability, and doing the whole sequence processing on every machine (if on farm).
By default Karma ROP (and USD Render) render the current frame to a temp USD file and render that image. Very similar to how Mantra generates .ifd files, Renderman does .rib, etc...
When you turn on "Render All Frames in a Single Process" Houdini cooks out the specified frame range into a single USD file, and renders that scene which has a range of animated data. This has the advantage of not requiring husk to have to load a new stage, saving composition costs. Advancing frames should always be faster than composing a stage from scratch.
The only downside I can see, is sometimes you can animate things in Houdini, that USD doesn't actually support as animated. For example, you can use a time-based expression in LOPs to animate variant selections over time. However USD itself does not allow for animated variant set selections. I think with the Karma ROP, those situations may not be as easy to hit as they might be in proper LOPs, but just something to be aware of. It's also a fairly new concept, as most rendering processes are accustomed to thinking in "file-per-frame" terms.
Thanks for the insights! So if it will be 99% fine for Karma ROP users to enable it and get a great speed improvement it might be worth considering checking it by default?
If you have frames that render for 30 minutes a piece it doesn't really matter but if I rarely have scenes that go over a minute per frame and then all the fluffy bits starts to make an impact. And Just curious, do you guys also do performance test with simple spinning cube scenes? If not please consider it, rendering 2000 frames with 5 seconds of actual rendering and 20 seconds of prep per frame really really hurts!
There are a couple of potential problems with rendering all frames from a single process: 1. it's harder to track progress 2. problems can occur when objects move from far away to up close - redicing may be required, but may not happen 3. Problems with some LOP setups can be "papered over" by rendering each frame separately (as described above by @goldleaf) 4. there used to be a much bigger problem, where the more frames you render from a single process, the more likely the renderer is to crash. It still happens of course, but far less frequently than when we made the decision on this default.
If we solved that first problem I'd be more likely to consider changing this default... Even more so if husk could detect frames that had already been rendered and skip ahead to the first frame in the sequence that didn't already exist on disk (in case it crashes half way through the sequence).
Anyway, it's definitely something we should consider...
mtucker There are a couple of potential problems with rendering all frames from a single process: 1. it's harder to track progress 2. problems can occur when objects move from far away to up close - redicing may be required, but may not happen 3. Problems with some LOP setups can be "papered over" by rendering each frame separately (as described above by @goldleaf) 4. there used to be a much bigger problem, where the more frames you render from a single process, the more likely the renderer is to crash. It still happens of course, but far less frequently than when we made the decision on this default.
If we solved that first problem I'd be more likely to consider changing this default... Even more so if husk could detect frames that had already been rendered and skip ahead to the first frame in the sequence that didn't already exist on disk (in case it crashes half way through the sequence).
Anyway, it's definitely something we should consider...
Therefore I‘ve made a feature request for a progress display for the cooking process, especially if you start render from TOP. And it would be helpful to something like the cache to disk nodes, if it‘s finished, that you always can read the file again and render as long there is no change.
mtucker 2. problems can occur when objects move from far away to up close - redicing may be required, but may not happen
Is there an option to force redicing every frame?
Karma knows whether it's rendering in the viewport or from husk. If it's rendering from husk, it should redice every frame. The same behaviour as "IPR Continuous Dicing".
mark Karma knows whether it's rendering in the viewport or from husk. If it's rendering from husk, it should redice every frame. The same behaviour as "IPR Continuous Dicing".
For interactive it would be great to get a button to re-dice only the current selection (based on the current view) since it can take a while on large scene. It would also be great to get a button to skip dicing and/or displacement for fast debugging (without messing around with object settings).
