[Bf-committers] Render API Design

[Bob Wenzlaff (AB8TD)]

At 04:58 PM 5/31/2007, you wrote:
>It's really not the purpose that Aaron is going to write exporting to
>all different render systems. What I do need all of you guys for is to
>help in the design phase, and verify that what he does is future proof.

What I had suggested in the past was to make an export system that 
passed scene data in a basic Renderman spec language.  If a 
particular renderer had extensions or subsets or dialects of the 
spec, then an intermediate run-time loadable library file could be 
created to "translate" for that renderer.  Note that if the renderer 
was not Renderman compliant, it could still be used, it's just the 
amount of work that goes into the translation lib goes up.

So for Aqsis, the translator lib might just be a pass-trough wrapper, 
while for Yaffray, it would be a bit more complex.

The question arises if we are pushing data to the renderer or 
allowing it to pull data.  I think the latter is a little more 
flexible.  I haven't given this a lot of thought, but I came up with 
a limited illustrative example.

Say we have a RendererX that internally can do Spheres, NURBS, and 
generic Polygons.  And a Blender Scene with a Sphere a NURB, a Cube, 
and a CC Subsurf.
(The upcoming version, RendererY will also do Metaballs.)

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.

The first do what you'de expect, return a Renderman encoded object of 
that type, and return NULL when finished with that type.  As an 
object is exported, it is flagged.

When you've used up all the specific data types you can handle, the 
translator calls GetTheRest().   GetTheRest() returns meshes of the 
VlakRen of all objects that haven't been flagged by the other functions yet.

So the translator for RendererX  calls GetSpheres() untill done, 
Calls GetNurbs() till done, doesn't bother calling GetCCSubSurf() or 
GetCurve() since internally it has no code to render those as 
anything other than a bunch of faces, and finally calls GetTheRest() 
and is given the Cube and the Subsurf as a generic mesh of VlakRen.

The nice thing about this system is it can be built up 
incrementally.  The GetTheRest() serves as a catch-all for things 
that we haven't implemented yet,  and the translation lib, since it 
is coded specific to a renderer, can be written specifically to take 
advantage of each renderer's features.

We can also put in placeholders for all exports not done yet. Say we 
plan a GetMetaball(), but it's not done yet.  The RendererY 
translator lib can go ahead and call GetMetaball(), we just return a 
NULL, and instead the Metaballs will just be converted to VlakRen and 
retrieved by the GetTheRest() function.     When a new version of 
Blender is released that has GetMetaball() done, the RendererY 
translator doesn't even need to be updated, it will just work.

If we add a new primitive, we can add it to the API or not as we like 
and nothing breaks.  If we add it, the translators need to get 
updated to use the new call, but they continue working the same as 
before until that happens because of the GetTheRest() call.

I didn't intend this to be even a start of the actual API, just a 
simple case to illustrate the method.

The downside that I see is that a translator need to exist for all 
renderers, even if they are fully Renderman complient, but a 
GenericRenderman lib could be offered with the release distro.  Then 
if people want extensions for their renderer of choice, they can mod 
the GenericRenderman lib and release it as an add-on, much the way 
python scripts are done now.

Robert Wenzlaff
(Det. Thorn)


-- 
No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.472 / Virus Database: 269.8.4/825 - Release Date: 5/30/2007