[Bf-python] Modified RenderEngine API Proposal

[Wenzel Jakob]

Hello Brecht,

Thanks for starting this discussion! I am currently traveling through Japan, hence my lack of participation :). I will be back in a week and look forward to reading the proposals.

Best,
Wenzel



On May 11, 2011, at 21:24, Brecht Van Lommel <brechtvanlommel at pandora.be> wrote:

> Hi all,
> 
> To kick of discussion, here's a proposal for how to modify
> RenderEngine to support preview and viewport rendering, and solve
> issues with thread safety and context. Link:
> http://wiki.blender.org/index.php/Dev:2.5/Source/Render/RenderEngineAPI
> 
> Some questions about the proposal:
> 
> Is it worth preserving backwards compatibility, or do you think it's
> work breaking it for an improved api? The main difference is the
> separate update callback, which exists mostly for thread safety.
> 
> Each type of rendering has separate callbacks. This seems like it
> would lead to the clearest implementation, if the same callbacks are
> used in different use cases the code may get confusing. Are the 3
> types a sensible distinction to make?
> 
> For viewport rendering, it is basically expected that the renderer
> runs in a separate thread itself, and callbacks should return as quick
> as possible to keep the UI interactive. The reason is that with python
> we can't really have one thread running one callback and then have the
> main thread calling the draw callback at the same time.
> 
> There is a similar problem with cancelling a render, currently the
> RenderEngine is expected to poll self.test_break(). This should
> perhaps be a callback too, but the same issue exists, no real
> threading support in python. Is this acceptable, or can anyone think
> of a better solution for this?
> 
> For animation rendering, the RenderEngine instance will not be shared
> between frames. I remember reading some request for putting animation
> render under the control of the external engine, but the problem is
> that not all animation renders are simply rendering frames from start
> to end. Due to the compositor and sequencer, render farms, frame
> stepping, etc, this can't be assumed, and it seems to tied to Blender
> internal works to leave this to the external engine?
> 
> Thanks,
> Brecht
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python