[Bf-committers] Render API Design

Bobby Parker sh0rtwave at gmail.com
Mon Jun 4 02:10:46 CEST 2007

I think the crux of the issue is that it seems that there's less interest in
Blender performing as a "database" for an exporter that does it's own
thing(ala the way XSI does it), and more interest in allowing Blender's
Render API to control the export process.

I'm still not sure a "translator lib" is the smartest approach, since we'll
need much more than that for effective support of things like Crystal Space,
Renderman, MentalRay, etc...Renderman and Gelato, especially, require extra
interface elements (GUI that is) to support things like custom materials,
attributes, all the extended stuff that Renderman is capapble (see the
Neqsus/BtoR interface here http://wiki.aqsis.org/guide/btor/ ). While some
support will be provided for blender's materials, truth be told, the more
advanced users will want the kind of functionality that Neqsus/BtoR offers
now for handling materials/shaders, and to that end, I see Neqsus/BtoR
having great relevance as the exporter interface. A "translator lib"
approach might work for other renderers (like for instance Yafray), but I
don't see it being practical for something like renderman.

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.

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.

> For example, if rendering a sphere as a mathematically perfect surface is
> 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.

It normally works in the opposite direction. Procedural objects such as a
sphere primitive is easier for the renderer to generate than a mesh would

> 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.
> I confess to a bit of confusion here....it sounds like you're expecting
Blender to output a kind of limited RIB code?  I think that would confuse
the issue a bit if that's the case. The Render API should be less of a
language and more of just an interface and expected set of callbacks for
both exporters and Blender to communicate back and forth. At least that's
how I see it.

Bobby Parker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20070603/4fd7c865/attachment.htm 

More information about the Bf-committers mailing list