[Bf-committers] Render API: Framework and Scene Break-Down
shaul.kedem at gmail.com
Wed Jun 6 15:28:33 CEST 2007
Ok; although I think changing the information the blender renderer uses can
be a nice thing (especially if it will be using these functions to begin
with) so future enhancements to the blender renderer *could* be done from
I gave some thought to your *Push vs. Pull. *paragraph. The way I see it,
different renderers may need different information segments at different
times, so given that this is an API (vs. a data structure pre-populated with
all of the data) I think that your conclusion is right; The API should
provide the, well, API.
On 6/6/07, Aaron Moore <two.a.ron at gmail.com> wrote:
> Hi Shaul,
> I'm glad you're interested in the project!
> > Also, am reading the wiki (haven't finished) but wanted to ask if this
> > will be able to change the information before the render, and if so,
> will it
> > go back to the scene or be part of the rendering only?
> Here's how I see this issue. The exporter, given that it's task is
> clearly defined, to produce the rendered image data, will not have the
> ability to change any of the scene data from the API. The scene data
> will be available for read-only query. All information will be there
> to allow many kinds of renderers to access the data they need in the
> way they need it in order to fulfill their task within blender: to
> produce image data.
> However, some things are not implemented in a given renderer, and some
> things are too complected to provide exact representations of the way
> blender does them. Material settings are a good example: shader
> implementations will not be accessible through the API, merely
> declarations of the type and input values: type = "phong" spec=".5"
> hardness="50" In these cases, the exporters are expected to make
> local copies of the input data so that they can manipulate them for
> use in an exporter specific implementation of the type "phong." At
> least this is how I currently see it.
> Generally speaking, it is a bad idea to make things mutable when they
> don't need to be.
> Bf-committers mailing list
> Bf-committers at blender.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-committers