[Bf-committers] Render API Design

[Robert Wenzlaff (AB8TD)]

On Saturday 02 June 2007 19:55, Bobby Parker wrote:
> >The Blender Render API could have  GetSpheres(), GetNurbs(),
> >GetCCSubSurf(), GetCurve(), (etc.), and a GetTheRest().  The
> >translator will have a function that Blender calls, say,
> >StartRenderExport(). That function then calls each of the above API
> >functions it can use to pull in the scene data.
>
> This is probably not the best way of doing this, for several reasons.
>
> The issue here really is about accessing data in the most appropriate
> manner for A. the object type at hand, and B. the renderer at hand.


As I said, this was a quick off-the-top of the head example meant only to 
illustrate a method.  All of the issues on how to manage scene data and 
renderer data would be handled by the StartRenderExport() function in the 
translator lib for that renderer.  The cleverness would all go in there, as 
trying to come up with a one-size-fits-all type of cleverness is surely 
asking for future growing pains.

> The Render API can have a flag that's set for Metaballs that either
> exports metaball/RiBlobby data to the

This doesn't seem very future-proof.  Renderers will add new features over 
time and Blender will add more types of objects.  These flags eventually get 
obsolete.  You can point to the renderman spec anad claim stability, but 
ideally we should be ready for the next big spec, and at least able to handle 
a renderer with a (possibly poorly engineered) custom interface.

> renderer as actual RiBlobbies OR...actually fetch the blender-created
> mesh as a mesh data type (which the exporter will then correctly
> interpret as a mesh and you can then choose to subdivide or not).

Under my method the same can be done.  If there is no RiBlobbies support in 
RendererX, then the StartRenderExport() for that exporter would not include a 
call to GetMetaballs() and those objects would fall through to the 
GetTheRest() function.  For a generic Renderman Lib, that could be determined 
at run-time.   One additional feature would be to let the Translator Lib be 
in charge of whether the object gets flagged as rendered or not.  This way 
the lib could get data then decide if to use it.  And we'd never get into 
the "RendererX doesn't support this type of object, so it won't be rendered" 
type of thinking.  All objects are eventually rendered, just some get 
exported as VlakRen.

For example, if rendering a sphere as a mathematically perfect surface is CPU 
costly, then the lib could choose to render distant spheres as meshes by 
ignoring them during GetSpheres() and not allowing them to be flagged as 
rendered.

My example here was trying to show how it could be used for _any_ renderer.
The translator lib would have all the information about the renderer and 
decide how to use the data.

> Of course. I think the Renderman case is especially well suited to this
> because of the wide range of feature support that the various renderers
> support (or don't support as the case may be).

Which is why the communications language should be as close to the Renderman 
spec as possible.  Most translator libs would need to be nothing more than 
very simple wrappers.  But if we are flexible in the base method, the lib can 
translate that to anything.

-- 
**********************************************************
New parents can never have enough child  psychology books.  

     It will be 4-5 years before the child can 
      reach the bathroom faucet without them.
**********************************************************
Robert Wenzlaff                rwenzlaff at soylent-green.com