[Bf-python] Modified RenderEngine API Proposal

Brecht Van Lommel brechtvanlommel at pandora.be
Wed May 11 14:24:06 CEST 2011


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



More information about the Bf-python mailing list