[Bf-committers] Render API Design
Ramon Carlos Ruiz
ramoncarlosruiz at gmail.com
Mon May 28 18:52:50 CEST 2007
The looong wait is finish :-) . . .
Aaron, I will send you by email the help files of mentalray . .
As a commentary as I saw on mentalray and povray we also need a
costume area for definition of materials, general configurations of
cameras , light, environment, options, etc where we can add code in a
native language of each render and the use of the structure (only) of
the pynodes for define shaders on lights, cameras, materials and
environments . . . Also again in the current convert area I have some
comment on managing of the normals but that can came later.
On 5/28/07, Mathias Wein <lynx at aspect-design.de> wrote:
> 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:
> 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
> 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 :)
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers