[Bf-cycles] Progressive Animation Rendering

[Daniel Salazar - 3Developer.com]

Greg thanks for starting to experiment with this. I'm the one who asked for
this functionality but others have shown interest too. You're addon is very
cool. However I think this implementation will suffer a lot from the
startup Export and BVH building time. This can be happily ignored with
simple scenes but on large scenes it can represent a good percentage of the
total rendering time. Ideally the progressive animation rendering
implementation would be able to save this scene data to disk along side the
frame to be able to resume as quick as possible, minimizing the overhead.

Thanks for your time and interest in this

Daniel Salazar
patazstudio.com


On Wed, Jul 31, 2013 at 9:25 PM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> Hi Greg,
>
> On Wed, Jul 31, 2013 at 7:48 PM, Greg Zaal <gregzzmail at gmail.com> wrote:
> > I'd like to know if there's any interest in this sort of thing, and if
> > so,(1) if someone could help me with it by coding the image merging bit
> to
> > combine all the different seeds so that an external program is not
> required.
> > And (2), after starting the Progressive Render, it's impossible to stop
> it
> > without actually killing the process, is there a way around this? I've
> had
> > to use Campbell's method from the Cell Fracture addon just to refresh
> the UI
> > and display progress..
>
> For (1) you could run another blender instance in the background and
> create a compositing node setup with python to merge images.
>
> The other option is to simplify things and not do any merging at all
> and just start again each time, just running render animation. This
> would give you a 50% render time increase if you double the samples
> each time (which to me seems somewhat more useful than adding a fixed
> number of samples).
>
> Regarding (2), I think you would need to change the code so that your
> script is not the main loop but is listening to callbacks/events and
> acts on those. You would invoke the render operator (invoke not
> execute so it runs as a job that the user can cancel), and then wait
> for the render to be finished or cancelled. There is a render_post
> handler but launching a new render from that might be a problem as
> it's still running the render then, so some trickery might be needed
> with e.g. an operator listening to a timer that starts the next render
> a bit later.
>
> > Or perhaps there's a better way with more solid integration with the
> > rendering process?
> > Since it's on the Todo list, I assume it's eventually meant to be a part
> of
> > blender itself and not simply an addon.
>
> Integrating this natively will of course give a better UI and
> integration. It needs changes in both Blender and Cycles, and is
> closely related to implementing pause/resume rendering too, since
> progressive animation render is like pausing a render for each frame
> and then resuming it later.
>
> I'd like to add this but it's a matter of time/priorities, I guess
> users will be happy with an addon for now, unless a developer here has
> time to work on a native implementation.
>
> Brecht.
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130803/714d5618/attachment.htm