[Bf-committers] Render API: Framework and Scene Break-Down
two.a.ron at gmail.com
Tue Jun 5 14:51:15 CEST 2007
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
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
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
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?
Object - contains instantiation information, and can be arranged
in hierarchies for groups
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
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:
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.
More information about the Bf-committers