[Bf-python] Modified RenderEngine API Proposal

[Matt Ebb]

On Thu, May 12, 2011 at 1:54 AM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> > Well, yes that's what I meant ;) And if you're using a renderer via the
> API
> > it's not going to be directly accessing DNA data like blender internal
> > currently does anyway, it'll be in its own format. But being able to
> modify
> > data eg. before/after renders, when opening files, etc. would make life
> much
> > easier.
>
> I would like to hear the practical use cases for this though, I have
> an impression there's different problems here that need different
> solutions. For example temporarily disabling a modifier in the
> update() callbacks, that seems reasonable to me. But setting data
> before and changing it back after rendering is problematic, as the
> scene can be edited during render.
>

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.

All my RNA types for shaders are generated dynamically - by querying an
external compiled shader file for parameter info, and then generating new
RNA types and properties on the fly. It also allows one to edit, re-compile,
and edit shaders in the blender UI in a pretty smooth automatic process.
Previously I was doing this in the UI at draw time, and at render time - it
wasn't nice but it was pretty safe - it wasn't really modifying data that
blender was likely to access at the same time.

Now this has all been disabled, and it's a real pain without other ways to
modify this data. I've had to put that functionality inside an operator
which users must click a button for, upon first viewing shader UIs (and each
time they change active shaders or recompile one). It also seems that
sometimes rna modification is disabled during the export/render process too
(it definitely is for preview renders), which I was using to make sure that
scenes are up to date with valid rna types and properties created when a
file is opened and rendered directly.

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).

> Doing totally custom preview scenes would be possible, just add a
> property for the preview type and ignore the scene blender gives you.
> So question is then, is this something we should then just leave to
> render engine entirely, and have Blender only pass on the datablock?
> Or should we improve the builtin preview scenes?

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).

It's not very easy right now though - currently exporters (well at least
lux, mitsuba and mine) have to have ugly code [1] that attempts to extract
what material (or texture etc) is actually being previewed by interpreting
blender's preview scene that gets passed in. I also have a problem where the
list of shader directory paths are stored in the original blender scene, but
that doesn't get sent at all with the preview render api callback - so I
just guess with bpy.data.scenes[0] which of course isn't correct.

I'd personally like to see the preview render work something more like:

render_preview (type_enum, material, texture, world, brush, orig_scene)

... where it passes through the type of preview that's being displayed, and
then pointers to the material, texture, world, etc that is being previewed
(or None if its the wrong preview data type). It would also help to have the
original scene data (or context?) in order to derive render settings from
the scene too.

btw Doug, it should be quite easy to have your own preview models, need to
remove those sphere/cube/monkey buttons from the preview render UI template
so engines can define their own preview types and add their own buttons.


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?

cheers

Matt


[1] http://www.pasteall.org/21539
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20110512/ce1ed8c4/attachment.html>