[Bf-python] Modified RenderEngine API Proposal

[Brecht Van Lommel]

Hi,

On Thu, May 12, 2011 at 12:02 AM, Matt Ebb <matt at mke3.net> wrote:
> Perhaps there might be different solutions, yes. A most basic example is
> disabling modifiers before render (could be alleviated with more fine
> grained control over getting geometry data out of the modifier stack?), but
> the main trouble I'm having right now is with generating RNA types.

This seems to be something that should be solved at the property
editing level, rather than in the RenderEngine. For the undo system,
if you edited data this way, it will be part of the wrong undo push,
and you can't be sure a preview render will be done even.

That said, my intention is to allow scene modifications in the update
callback, thread safety wise it doesn't really matter if you have it
read only or read-write. The user can't edit the scene while update is
running, but can edit while render is running. So you could probably
do those updates then, but the right solution would be to wait for the
python update/notifier stuff that Campbell was going to tackle.

> Anyway, there might be other ways of fixing this particular issue, but I bet
> there are other use cases out there too. IMO the simplest would just be to
> allow writing data at certain defined moments, perhaps with some special
> callbacks that get run before export in a blocking/thread safe manner. As a
> side note having this capability would not just be useful for render
> engines, but for normal users too - many 3d apps have this kind of
> functionality (Houdini has pre-render, pre-frame, post-frame, post-render
> python callbacks, which are very handy).

Yes, that is kind of script link stuff would be useful, though it's
not really something to put RenderEngine I think, as it's more for
users not render engine developers.

> IMO yes, it should be left to the renderer entirely - even after potentially
> changing blender's internal preview scene, it's still never going to be
> appropriate for all renderers out there. As another example, renderers might
> want to have their own preview scenes set up using the different types of
> geometry that that renderer supports (eg. parametric prims, curves, points
> etc in renderman).

I've modified the proposal now to have the callback as "def
preview_update(self, context, id):". The datablock being previewed is
id, type(id) can be used to find out what kind of datablock it is. The
current scene and object should then be in the context that is passed.
Sometimes there may be no current object, if e.g. the material is
pinned.

> As a side note related to preview rendering, currently it's launching off
> new instances of the render engine on every redraw. This is a bit of a
> problem, especially when resizing the property editor and having hundreds of
> renders started - especially if the render engine needs to do things like
> contacting a license server on the network. Something like a way to limit
> how many of these get spawned would be helpful, either to limit the
> frequency or perhaps provide another callback to the engine to check if its
> ok to start a new render?

Maybe some modifications to the jobs system are needed here, but in
principle a new preview job should not be started until the previous
one is finished? Then it would be up to the render engine to decide
how quickly it wants to react to self.test_break.

Brecht.