[Bf-committers] Render API Design

[Robert Wenzlaff (AB8TD)]

On Sunday 03 June 2007 20:10, Bobby Parker wrote:
> Actually it's not much different from your own idea. All we're really
> talking about is where the black magic and voodoo happens. The general idea
> is to come up with a way for Blender to decide what to give the exporter in
> terms of data. Using Metaballs as an example, if the renderer capabilities
> setting for a given renderer indicates that it can support that kind of
> data, then Blender simply provides it. Otherwise, Blender provides the
> converted mesh.

Yes, we are just talking about where the black magic occurs but do we want 
the "black magic" code for 20 different renderers (not all Renderman 
compliant and possibly with features we haven't even thought of yet) in the 1 
blender source tree, or in 20 different libs* that any particular user needs 
only 1 or 2 of, and only 1 is loaded at any time?  There's a lot of 
Me-Too-ism in software design and it tends to bloat software that is designed 
monolithically.

The Generic Renderman lib could use all the discovery calls to determine how 
to best use a particular renderer making it _very_ generic. So in effect, it 
might do 99% of what you want and support a vast majority of the renderers 
out there.  But it will also get out of the way for non-renderman exporters.

If you are working on the RendererX code, you should only be working on the 
RendererX code, with no chance of breaking the RendererY code (or Blender in 
general).

External material editors are another area where we need work, but that really 
doesn't effect whether the magic code is in Blender or a loadable lib.  It is 
particularly important to have materials external to Blender as every 
renderer will have different material specs.   Perhaps a 
DrawMaterialEditor(), DrawRenderSetup(), etc. functions to popup a 
customizable set of Blender controls for each lib?  At that point the Blender 
material becomes a quick preview of the material as it will be used for final 
render. 

*Ideally, Blender.org would only maintain one of these libs, the 
GenericRenderman one, (maybe 2, since Yafray is currently supported 
internally), with all others being maintained by the people who want that 
particular renderer.  So the total number of lines of code we're supporting 
is about the same.
--
*************************************************
 What if it turned out that the only thing wrong
  at Microsoft is that Bill just _really_ loves
       the sound of hard disks indexing?
*************************************************
Robert Wenzlaff       rwenzlaff at soylent-green.com