<div dir="ltr"><div>Dear Ton (and all people that might be able to help),</div><div><br></div><div>I am Roberto, one of the people interested in adding better/simpler &#39;expressive&#39; rendering capabilities into Blender and helping with BEER project.</div><div>BEER&#39;s plan after I joined the merry group was to &quot;copy-paste&quot; the Cycles code, using its internal architecture but changing the rendering part, mainly because we don&#39;t want to risk breaking BI (or Cycles) and we&#39;d like to use C++ to be more productive, but if this isn&#39;t advisable or acceptable there are other possibilities.</div><div><br></div><div>To enable anyone to experiment with their preferred render styles and algorithms, we will need to add user-programmable shader algorithms to BI render code.</div><div>My first guess on how to do this would be to try to &quot;extract&quot; the current fixed-pipeline BI render code and transform it into a pluggable module, so that based on some condition (materials? layers?) the render path can call the original code or any one of a series of new render code modules that may then implement the core rendering functions based on any algorithm or technology their authors might choose.</div><div><br></div><div>Since we think that GLSL is a good path (far more standard, stable and simple than OSL and useful as a game design pre-visualization tool) we&#39;d like to go that route: this will require us to extract any required scene, model, lighting, material, etc. information from the Database_FromScene data and prepare it for submission to the GLSL code, that will do the work currently done in new_render_result() (this based on this document: <a href="http://wiki.blender.org/index.php/Dev:Source/Render/Pipeline">http://wiki.blender.org/index.php/Dev:Source/Render/Pipeline</a>). All the existing tile shader functions will have to be implemented in GLSL.</div><div><br></div><div>Needless to say my main worries are:</div><div><br></div><div>  1) will we be able to have a clean separation between data extraction and data rendering without requiring a major rewrite of BI&#39;s render pipeline or breaking the current multithread/multi-tile architecture?</div><div>  2) what would be the best way to enable users to choose one renderer or the other? Scene? (Blender) Layer? Material? Object or Object Group? Or final compositing is enough?</div><div>  3) Will it be possible to use this renderer for the Viewport too? (My guess is &quot;yes&quot;, but I still have to check the existing code, let alone what&#39;s happening in the new Viewport FX code)</div><div>  4) how to document all of this? AKA &quot;what happened to Sphinx/Doxygen docs&quot;?</div><div><br></div><div>At this point, we&#39;d like very much to know your ideas about this and the best way(s) to implement it.</div><div>What are the preferred improvement targets you (Ton) and the BF have for BI? What do you prefer to avoid?</div><div>Any feedback (including &quot;this is totally wrong, there&#39;s a much better way to do it!&quot;) will be very much appreciated!</div><div><br></div><div>Roberto Maurizzi</div><div>(with some help from the others)</div><div><br></div></div>