[Bf-committers] Render API Design

[Bobby Parker]

I'm not sure what you mean about where the code is for 20 different
renderers.I actually don't think that giving the Render API the
functionality to make those decisions of renderer capabilities is going to
contribute to code bloat. I don't really see what you think is going to
contribute to such bloat. In fact, I believe it will have the result that
exporters become far easier to write. Here's why.

>From a renderman standpoint, my exporter only needs to maintain a simple
array of renderer names, and a set of fields per renderer that lists each
capability and whether it's supported or not. Thus, when I select, say,
Aqsis, the exporter knows what Aqsis supports.

Then at render time, the Render API asks the exporter for the renderer's
capabilities and reacts accordingly on each object.

Let's also consider the Serious Engine exporter. That particular exporter
only recognizes mesh objects and bones only. So with the render API, we
simply say that the exporter only supports mesh objects, and for authoring
our exporter, we only have to worry about writing code that deals with the
data it's provided and leave it at that.

Also, the U3D exporter that I'm working on operates on the same principle.
Mostly mesh data, with some limited primitive support. Again, I only need to
register some capabilities and the render API gives me what I need.

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.

Thus, Neqsus requires that for each object adapter, I make a decision
somewhere in the code for whatever renderer I have supported.

Same goes for Serious Sam and the U3D exporter (while not renderers, they do
export the scene and the Render API can provide functionality for that).

While yes, doing it this way means a bit more code for the Render API...but
in the long run it results in more efficient exporter authoring.

For those reasons, I don't see how it encumbers the code unnecessarily. I
think this approach enables exporter authors to be more efficient in their
coding.

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. I personally envision
Neqsus/BtoR remaining as the exporter interface, enabling me to simply add
the required callbacks for the Render API to communicate with it.

Bobby Parker
ShortWave


On 6/3/07, Robert Wenzlaff (AB8TD) <rwenzlaff at soylent-green.com> wrote:
>
> On Sunday 03 June 2007 20:10, Bobby Parker wrote:
> > 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.
>
> Yes, we are just talking about where the black magic occurs but do we want
> the "black magic" code for 20 different renderers (not all Renderman
> compliant and possibly with features we haven't even thought of yet) in
> the 1
> blender source tree, or in 20 different libs* that any particular user
> needs
> only 1 or 2 of, and only 1 is loaded at any time?  There's a lot of
> Me-Too-ism in software design and it tends to bloat software that is
> designed
> monolithically.
>
> The Generic Renderman lib could use all the discovery calls to determine
> how
> to best use a particular renderer making it _very_ generic. So in effect,
> it
> might do 99% of what you want and support a vast majority of the renderers
> out there.  But it will also get out of the way for non-renderman
> exporters.
>
> If you are working on the RendererX code, you should only be working on
> the
> RendererX code, with no chance of breaking the RendererY code (or Blender
> in
> general).
>
> External material editors are another area where we need work, but that
> really
> doesn't effect whether the magic code is in Blender or a loadable lib.  It
> is
> particularly important to have materials external to Blender as every
> renderer will have different material specs.   Perhaps a
> DrawMaterialEditor(), DrawRenderSetup(), etc. functions to popup a
> customizable set of Blender controls for each lib?  At that point the
> Blender
> material becomes a quick preview of the material as it will be used for
> final
> render.
>
> *Ideally, Blender.org would only maintain one of these libs, the
> GenericRenderman one, (maybe 2, since Yafray is currently supported
> internally), with all others being maintained by the people who want that
> particular renderer.  So the total number of lines of code we're
> supporting
> is about the same.
> --
> *************************************************
> What if it turned out that the only thing wrong
>   at Microsoft is that Bill just _really_ loves
>        the sound of hard disks indexing?
> *************************************************
> Robert Wenzlaff       rwenzlaff at soylent-green.com
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20070603/60ddd009/attachment-0001.htm