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

[Aaron Moore]

Hello,

Within the last few days I have developed a draft of my own thoughts
in terms of a system framework and a breakdown of the API into
sections.

FRAMEWORK

My framework divides the render work into 3 parts, the render
pipeline, the render API structures, and the plugin.

The render pipeline will have several callbacks within it's structure,
at least: load_renderer, setup_render, do_frame, finish_render, abort.
These will be implemented in the plug-in and do the meat of the render
work. For blender internal, the 'plug-in' will be hard coded into the
source.

Additionally, blender will have functions implemented that allow the
renderer to feed data back in: post_progress, which reports buckets or
pixels that are finished, and error, to report errors.

The render API will present a scene description that contains
everything that the renderer needs to know--and nothing more. This
will be implemented as a hierarchal meta-data structure which will
serve as a filter, and organizer of blender's scene data. In fact
something like this already exists: "render." I would rework this
structure and turn it into the access point for the render API.
Furthermore, in object oriented fashion, I would follow the lead of
the DerivedMesh programmer in implementing OO methods using function
pointers as struct fields. The render API would build the initial,
most basic scene description, then hand over control to the plugin.
The idea is that the render API does not do anything that the plugin
didn't tell it it wanted it to do. For example, initially everything
will be accessible merely as a bounding box. The renderer then has the
option to ask for the geometry in whatever way it wants, all at once,
or piece by piece.

The plug-in would use the methods and data provided in the render API
to query blender feed data to it's respective renderer and return
results.

SCENE BREAKDOWN

Since the internal renderer itself is going to be re-routed through
this system, it needs to encompass everything that can be rendered in
blender. Is this not everything?

RenderContext
    Settings
    World

    Object - contains instantiation information, and can be arranged
in hierarchies for groups
    Camera
    Light
    Geometry - contains material link
    Meta-Geomtry - because it's not similar enough to the other kinds
to put in with them

    Material - contains texture links
    Texture
    Radiosity

Also, for animation purposes, all data will contain a flag to denote
if it has changed since
the last render.

More information about both of these design subjects can be found here:
http://wiki.blender.org/index.php/Render_API

Things I have discussed here are in the sections called:
Framework, Access Methods, and Pseudocode according to Mosani
...however feel free to comment on any part of that page.

Aaron Moore
mosani