[Bf-committers] Render API Design

Mathias Wein lynx at aspect-design.de
Mon May 28 14:25:15 CEST 2007


Hi,

as for the yafray interface, there is indeed no written documentation.
However, the current ("old") interface makes heavy use of STL-containers
which is not nice, and the new one is somewhat incomplete and pretty basic.
But you may have a look at this new header anyway:
https://ssl.little-isp.de/svn/lynx/yafaray/mainline/include/interface/yafrayinterface.h

 From what i understood, Ton basically wants the render-API to
clean-up the mess in convertblender.c, so it has to be suited for blender's
own render pipeline in the first place and in my opinion should attend
scene preparation for rendering as far as feasible.

And since you already recognized that different renderers have very
different levels of abstraction, i think the API has to respect that to
some degree anyway.
Say, one renderer has its own tessellation or displacement algorithm (like
a renderman renderer), the other one doesn't and will gladly take the result
of blender's built-in method (like YafRay).
So the API should be able to deliver data at different stages of
processing in blender's own pipeline, so it becomes easier to
make external renderers take over control at the intended point.

Currently YafRay tediously dissects all the final blender internal data, and
convertblender.c has some YafRay specific code to skip unnecessary
stages (octree, shadowmap etc. which probably would not go into a 
render-API)
and AFAIK there's no chance to free preprocessed geometry in blender (which
is only needed temporarily until it's exported via the interface) before
rendering which wastes memory.

But that's really just my point of view :)

Mathias


!DSPAM:18,465acaef36371793976501!




More information about the Bf-committers mailing list