[Bf-committers] Render API Design

[Bobby Parker]

It's actually workable either way, if designed correctly. All you're talking
about here is a series of callbacks on both sides. In truth, to *fully*
support Renderman, it's going to need a little bit of both.

As an example for that, to do REAL motion blur in renderman, i need to be
able to access "subframe" positioning data for each object affected by
motion blur.

Point of fact, using Blender as a database for scene information is what I
do NOW. That being said, it falls to my exporter to have to make multiple
passes through the scene database to build up an exportable scene. Here's
what I currently do:

I pull scene global setup information from both my own render settings and
Blender's render context. Then I have to determine starting and ending frame
for animation, and my exporter has to then increment the frame pointer to
the starting frame.

After that, I fetch lighting information. Currently, I have to fetch ALL
OBJECTS IN THE SCENE to get the lights and then I have to filter them out to
build the lighting list.

After that I have to iterate object information without the lights. Now
here's where it gets interesting. My exporter has to make decisions based on
the objects received and decide what to do with them. To handle this, I
created object adapters, that each have the intelligence to export the data
it's given for that particular type.

This process, while it works acceptably well, is far from ideal. I export
archives for each object in the scene, but I would like to be able to test
an object to see if it has moved or not, to reduce the amount of data output
that I'm dealing with. I would also like to be able to not have to worry
about iterating frames myself. Based on my own practical experience with it,
having Blender handle frame iteration and object decisions in the Render API
is the superior method of dealing with it, since it makes the authoring of
exporters a far more accessible task than it is currently. Relying upon the
exporter to iterate frames and objects complicates the export process
needlessly, in my opinion.

As to how Blender would control the export process...it would control in
much the same way it handles Yafray/Internal renderer rendering now. Again,
all that's needed is a series of callbacks into both the exporter and the
Render API.

Bobby Parker
ShortWave



On 6/3/07, Aaron Moore <two.a.ron at gmail.com> wrote:
>
> On 6/3/07, Bobby Parker <sh0rtwave at gmail.com> wrote:
> > I think the crux of the issue is that it seems that there's less
> interest in
> > Blender performing as a "database" for an exporter that does it's own
> > thing(ala the way XSI does it), and more interest in allowing Blender's
> > Render API to control the export process.
>
> I just wanted to comment that this is not at all my opinion. I see
> blender as a database that a renderer needs to query. Setting optional
> flags to allow renderers to "opt-out" for support of given features is
> an exception to the rule. This is because it is the renderer that
> changes, not blender. Blender doesn't know what a variable exporter
> needs, it just knows what it has. But an exporter does know what it's
> representative renderer needs. Therefore I suggest let each player in
> this relationship use what they know. Let blender provide flexible
> access to the data, and let the exporter ask the questions.
>
> That's my opinion. In fact, that's the only way that I can make sense
> of the problem... I still haven't managed to figure out how a system
> based on blender controlling the export would even work...
>
> Aaron
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20070603/23c6a728/attachment.htm