[Bf-python] Modified RenderEngine API Proposal

[Doug Hammond]

A further comment about the general approach here:

By using these callbacks, is there going to be a provision for updating an
existing running rendering process with changed data?

For example, with the viewport "rendered" mode, it would seem rather
inefficient to have to re-export the entire scene if just one object has
changed (either in transform, mesh edit or material assignment, etc) - will
there be a mechanism available to only update that single object and
continue the render while retaining all the other data in memory?

I'm not sure if you've already implied this with the *_update() methods - is
that what you're aiming for ?

Doug.

On Wed, May 11, 2011 at 11:02 PM, Matt Ebb <matt at mke3.net> wrote:

>
>
> 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
>
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> http://lists.blender.org/mailman/listinfo/bf-python
>
>


-- 
Doug Hammond (dougal2),
Developer and Admin for
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20110512/7b2b0aea/attachment.html>