[Bf-committers] Render API Design

[Ramon Carlos Ruiz]

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.

Regards,
Carlos


On 5/28/07, Mathias Wein <lynx at aspect-design.de> wrote:
> 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
>
>
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
> 
>
>
>

!DSPAM:18,465b16de36372687915566!