Brain storming: Render Animations: prepare next frame before current is finished?

@paulphysicalc @andy


the situation of rendering animations is, some times render times are quite short and load times quite long. So, it can be that a rendering needs 10s and to start the next one needs 10s too (for example Bongo and Octane/Vray…). Couldn’t be possible to prepare the next one during the previous is rendered? Could be something done on the Rhino side to help render plugin developers to get this task easier done?

So far I can see we have two load parts - preparing the scene (geometry/lights) and preparation at the render plugin. The second part could be solved if the first part is ready.

The hardware will faster and faster, but some times it’s difficult to use the power. Is there a chance to speed up the process?


If you are using V-Ray you might be able to figure out a way to export just .vrscene files from Rhino/Bongo, and then use V-Ray Standalone to render out the .vrscenes after they are created. If save the vrscenes on dropbox, you could even render on a different computer. From my experience you might be putting more effort into this than it is worth, might be easier to just buy more seats of Rhino, Bongo, and Render Plugin and maybe even Deadline to increase throughput.

One interesting thought is to let Bongo manage a changequeue (new mechanism in Rhino WIP / v6 for integrating realtime render engines, but it doesn’t have to be limited to that) in such a way that a render engine could use this to manage updating the scene in animation rendering. That would take away quite a bit of unnecessary of overhead if only some objects changed, or even more so if only camera changed.

@mnewberg: the problem of .vrscene files could be that it is a large amount of data. And if I think on GPU rendering than I don’t see the limit in the local calculation power. The question is, how to get the power used?

@nathanletwory: Sounds interesting, maybe the plugin developer could think about it. Communication in real time will be more and more missed.
Isn’t the GPU not a kind of “renderer”? So, like the Rhino-GPU communication is fast and real time, could we not get a render plugin connection?

My current workaround against long load times is to start two or three Rhino tasks with the same scene and render Bongo animations to the same output directory. The option “don’t overwrite exist files” is the key. But this way is cumbersome and cost a lot of resources, since the Rhino tasks occupied the RAM. And so I ask me, could we not get this functionality in one Rhino task? So, if one frame is rendering than the next one is prepared in the background, maybe at an internal second render plugin instance.
If I manual can setup this workaround should it not be possible to find a software solution?

The advantage of the multi task workaround is that if one Rhino task is freezed by scene preparation an other can work. So, if the preparation is longer than the render time, than I need more Rhino tasks only.

If a render engine integrator uses the new realtime integration mechanism, then I think Bongo could be adapted to utilize this mechanism. I mentioned the idea to @andy, but we need to think this through. But Raytraced mode uses this mechanism already, and as such - with the idea I proposed - GPU would be pretty well utilized. Other engines could do this then too. Well, that is the idea. We’ll see what we can do about it in the future (:

For even faster rendering a render farm (multiple machines to do the rendering) would probably a better long-term solution.

Oh yeah when I was doing animations with a dual 10-core Xeon at my old job I had to open about ten Rhino sessions to actually keep the the very expensive CPUs saturated.