<div><div>Interesting batch of ideas. I especially like the "data changed" flag for animation purposes. <br><br>Bobby Parker<br>ShortWave<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
FRAMEWORK<br><br>My framework divides the render work into 3 parts, the render
<br>pipeline, the render API structures, and the plugin.<br><br>The render pipeline will have several callbacks within it's structure,<br>at least: load_renderer, setup_render, do_frame, finish_render, abort.<br>These will be implemented in the plug-in and do the meat of the render
<br>work. For blender internal, the 'plug-in' will be hard coded into the<br>source.<br><br>Additionally, blender will have functions implemented that allow the<br>renderer to feed data back in: post_progress, which reports buckets or
<br>pixels that are finished, and error, to report errors.<br><br>The render API will present a scene description that contains<br>everything that the renderer needs to know--and nothing more. This<br>will be implemented as a hierarchal meta-data structure which will
<br>serve as a filter, and organizer of blender's scene data. In fact<br>something like this already exists: "render." I would rework this<br>structure and turn it into the access point for the render API.<br>
Furthermore, in object oriented fashion, I would follow the lead of<br>the DerivedMesh programmer in implementing OO methods using function<br>pointers as struct fields. The render API would build the initial,<br>most basic scene description, then hand over control to the plugin.
<br>The idea is that the render API does not do anything that the plugin<br>didn't tell it it wanted it to do. For example, initially everything<br>will be accessible merely as a bounding box. The renderer then has the
<br>option to ask for the geometry in whatever way it wants, all at once,<br>or piece by piece.<br><br>The plug-in would use the methods and data provided in the render API<br>to query blender feed data to it's respective renderer and return
<br>results.<br><br>SCENE BREAKDOWN<br><br>Since the internal renderer itself is going to be re-routed through<br>this system, it needs to encompass everything that can be rendered in<br>blender. Is this not everything?<br>
<br>RenderContext<br> Settings<br> World<br><br> Object - contains instantiation information, and can be arranged<br>in hierarchies for groups<br> Camera<br> Light<br> Geometry - contains material link<br>
Meta-Geomtry - because it's not similar enough to the other kinds<br>to put in with them<br><br> Material - contains texture links<br> Texture<br> Radiosity<br><br>Also, for animation purposes, all data will contain a flag to denote
<br>if it has changed since<br>the last render.<br><br>More information about both of these design subjects can be found here:<br><a href="http://wiki.blender.org/index.php/Render_API" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://wiki.blender.org/index.php/Render_API
</a><br><br>Things I have discussed here are in the sections called:<br>Framework, Access Methods, and Pseudocode according to Mosani<br>...however feel free to comment on any part of that page.<br><br>Aaron Moore<br>mosani
<br>_______________________________________________<br>Bf-committers mailing list<br><a href="mailto:Bf-committers@blender.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Bf-committers@blender.org
</a><br><a href="http://lists.blender.org/mailman/listinfo/bf-committers" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.blender.org/mailman/listinfo/bf-committers</a><br></blockquote></div><br>