[Bf-committers] Render API Design
Bob Wenzlaff (AB8TD)
rwenzlaff at soylent-green.com
Fri Jun 1 00:39:11 CEST 2007
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.
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
More information about the Bf-committers