[Bf-committers] Render API Design
two.a.ron at gmail.com
Mon Jun 4 02:38:22 CEST 2007
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...
More information about the Bf-committers