[Bf-python] Modified RenderEngine API Proposal

[Doug Hammond]

Hi,

I've got a few suggestions based issues we faced in the existing exporter,
and your document.

1.
At times it would have been good to know in the RenderEngine instance
whether the render.render() operator was called with animation=True or
=False.
I hear what you say about the fact it shouldn't make any difference, however
under certain circumstances (for "offline" batch exporting etc) it would
be useful to have access to this boolean value.

2.
I agree with Matt's opinion of the existing preview.blend preview scene
data. The built-in scene is entirely unsuitable for LuxRender, IMO it might
be more efficient to not bother loading/passing it at all and let the
external engines provide their own data from scratch.

There's also the issue of passing in other settings and data from the
current scene into the preview. Our users' top request is to be able to
adjust the scale of the preview scene to match the size of the objects
they want to apply to material/texture to, since in physically-based
rendering the scale of the object is important for many properties
of the material.
Another thing would be to provide custom preview types, eg. the
'strand' preview is not relevant to LuxRender, and we might also want
to switch the Monkey type to the LuxBall type, for example.

3.
RenderResult has been a difficult beast to control so far. My experience
of setting the .rect property has been that it can lock the UI momentarily.
Also, the .layers[0] access somehow seems like an incomplete implementation.
I would like to perhaps see something like this for full support of named
layers:
ly_combined = result.add_layer('Combined')
ly_combined.rect = combined_data()
ly_depth = result.add_layer('Depth')
ly_depth = depth_data()

4.
Rendering progress bar. Can update_stats() provide a way to update the
progress bar in the info header too?

Cheers,
Doug.


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

> On Wed, May 11, 2011 at 10:24 PM, 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.
>
> No strong opinions here, but one thing that's very annoying about the
> current API is the lack of access to modify data - even data that's
> owned (custom rna properties) by the engine. It makes it quite
> difficult to update data as needed, eg. at render time.
>
> > 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?
>
> I think so, different types of renders will require different data too
> - eg. preview renders can get data like the current material passed
> into it directly. I made a basic patch for this sort of thing [1] but
> it could be a lot better. The current method of sending blender's
> preview.blend scene isn't that practical really, I have problems
> trying to retrieve data from the current scene (eg. shader paths)
> which isn't accessible via the preview scene.
>
> Rest of the doc seems fine to me at this point.
>
> cheers
>
> Matt
>
>
> [1]
> https://projects.blender.org/tracker/index.php?func=detail&aid=25092&group_id=9&atid=127
> _______________________________________________
> 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/20110511/91b37c41/attachment.html>