[Bf-blender-npr] BEER: a possible action plan and request for comments/feedback.

Roberto Maurizzi roberto.maurizzi at gmail.com
Wed Oct 29 07:25:51 CET 2014


Dear Ton (and all people that might be able to help),

I am Roberto, one of the people interested in adding better/simpler
'expressive' rendering capabilities into Blender and helping with BEER
project.
BEER's plan after I joined the merry group was to "copy-paste" the Cycles
code, using its internal architecture but changing the rendering part,
mainly because we don't want to risk breaking BI (or Cycles) and we'd like
to use C++ to be more productive, but if this isn't advisable or acceptable
there are other possibilities.

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.
My first guess on how to do this would be to try to "extract" 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.

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'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:
http://wiki.blender.org/index.php/Dev:Source/Render/Pipeline). All the
existing tile shader functions will have to be implemented in GLSL.

Needless to say my main worries are:

  1) will we be able to have a clean separation between data extraction and
data rendering without requiring a major rewrite of BI's render pipeline or
breaking the current multithread/multi-tile architecture?
  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?
  3) Will it be possible to use this renderer for the Viewport too? (My
guess is "yes", but I still have to check the existing code, let alone
what's happening in the new Viewport FX code)
  4) how to document all of this? AKA "what happened to Sphinx/Doxygen
docs"?

At this point, we'd like very much to know your ideas about this and the
best way(s) to implement it.
What are the preferred improvement targets you (Ton) and the BF have for
BI? What do you prefer to avoid?
Any feedback (including "this is totally wrong, there's a much better way
to do it!") will be very much appreciated!

Roberto Maurizzi
(with some help from the others)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-blender-npr/attachments/20141029/deb122f8/attachment.htm 


More information about the Bf-blender-npr mailing list