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

[Bobby Parker]

Interesting batch of ideas. I especially like the "data changed" flag for
animation purposes.

Bobby Parker
ShortWave

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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20070605/565f7cc8/attachment.htm