[Bf-committers] Render API Design

Robert Wenzlaff (AB8TD) rwenzlaff at soylent-green.com
Mon Jun 4 14:12:25 CEST 2007

On Sunday 03 June 2007 22:49, Bobby Parker wrote:
> Using the other method...each exporter that's created that has to make its
> own decisions about object support winds up with a ream of code required to
> make those decisions.

Yes, but it's their code to maintain not ours and they're all isolated from 
one another.  We provide the API as part of Blender, the exporters are 
provided by special interest groups with the exception of 1 or 2 render 
exporters that we "officially" support.  That would be Yafray and Generic 

> As far as a "generic renderman" lib goes...I don't think such a thing is
> neccessary. The exporter only needs to be aware of what each renderman
> renderer supports, and from there it specifies those capabilities to the
> render API, and voila', all renderers are supported.

That's what I mean about making the Generic Renderman lib very generic.  It 
would do most of what you want - it could be set up to do your query and 
decide method and thus support Aqsis, Serious, U3D, etc.).  But you can't 
assume that U3D will never extend or stray from the spec, and that Serious 
won't extend or stray in a different, non-compatible way and thus each  
require a "custom Renderman" exporter to use all their features.  That's all 
I meant by "Generic", a starting position based on the common spec.

Maybe I should have called it "Fully Compliant Renderman Lib". If your 
renderer sticks to the spec, it's all you'll ever need.  If you want custom 
features beyond the spec, you need a custom exporter to support them.  If you 
were never to spec (like Yafray), then you need a custom exporter from the 
start.  Again, it's just where we put the magic code.  Since we need custom 
exporters for some renderers anyway, put the magic there so we can be extra 
flexible with it in the future. 

Let's be really optimistic and assume Blender will outlive the Renderman spec. 
Trying to come up with a universal solution _inside_ blender means some day 
we will have to fit a square peg in our round hole. So let Blender provide 
the wood and let the exporter drill the holes in whatever shape it wants.   

Blender should just provide the data requested (with the loadable exporter 
controlling the requests).  That is the only thing design-wise we are in 
control of.  The makers of Aqsis don't really care what our API can or can't 
do (yet).
As Socrates once said:
               "I drank what?????"
Robert Wenzlaff        rwenzlaff at soylent-green.com       

More information about the Bf-committers mailing list