[Bf-committers] Render API: Framework and Scene Break-Down
sh0rtwave at gmail.com
Wed Jun 6 02:50:01 CEST 2007
Interesting batch of ideas. I especially like the "data changed" flag for
> 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
> 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?
> 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.
> Aaron Moore
> Bf-committers mailing list
> Bf-committers at blender.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-committers