[Bf-committers] Render API: Framework and Scene Break-Down

[Aaron Moore]

First of all, thanks for the positive feedback, I appreciate that. I
begin to wonder sometimes if people think the ideas I just throw out
there are utterly insane or not.

> 1. Define the exporter callbacks in a Python script.  (i.e. a Python
> script or class or whatever is a valid exporter if it defines those
> callbacks.)
> 2. Write the exporter as a Python script.
> 3. For exporters that need to use C/C++, write a Python binding (either
> in pure C or using pyrex et al.)
>
> Then you could re-use all of the existing Python API for accessing parts
> of the Blender database, and your job is cut in half...  Your SoC
> project would then revolve around setting things up so that the render
> buttons can call a Python script, and writing a Python binding to the
> Blender renderer.  (Both of which would seriously Kick Ass IMHO! :-).
> Again, I'm just throwing this out there... mostly for a reality check...
>  >:-]

Interesting idea. The subject of using/integrating with existing
systems is a very valid design subject and I'm afraid I'm not in a
wonderful position to be the judge of whether it makes sense.

Here are my thoughts:

Python is interpreted. XSI's Render API is only in the c++ format
because of performance concerns. However, in theory my API could make
use of the Python API on a lower level. It is true that we are
performing similar tasks. My intuition, though, is that they are not
similar enough...  Ok, I've got it.

If both systems derived from a larger more general Blender API, then
the reuse would make sense. But the Python API has it's own concerns
and so does the Render API. In order to do what your suggesting what
would really need to happen is for the Python API to go through a
refactor like this:
    before: Python API
    after: Blender API (based on old PyAPI code) > Python API (derives
from Blender API)

Only then could the Render API be setup for reuse:
    Blender API > Render API

In XSI there is no deriving going on, it's just all one big XSI API
with different subsections.

Ok, now comes the practical side to this equation. Where it seems to
me that this massive system would be ideal, and additionally this
system would be the only way such reuse could work, it would be an
utterly massive amount of work, way more than I could do over a single
summer. I'm in deep with the Render API as it is. So, I simply don't
have the man power to do it. And I don't feel good about integrating
these two systems if this refactor were not done.

Reuse is a tricky issue. It can create glorious elegant code that is
easy to maintain. It can also link things in  ways that are hard to
follow and create complex webs of dependencies that are impossible to
debug. I guess that's why I hesitate here. When in doubt..., you know.

But it's a very valid criticism, the similarity with the existing
system. In fact, as I said, IMHO that's how it would ideally be done.
So, good point.

Aaron