[Bf-committers] Preliminary Design (render api)

[Aaron Moore]

Campbell,

> **>>> CAMERA, needs scale if its to support Ortho cameras.
> Additions like depth of field settings I assume your saving for later,
> and keeping the API simple for now?

Yes, it's not complete yet.

> ** >>> ALL SCENE DATA
>
> Agree with ton that we should just give the render API all blenders
> objects no matter if they are dupliGroups, or whatever...
> Just all the objects that are rendered - flattened into one list. (Ton,
> correct me if Im wrong)
>
> That could be in the form of a linked list or an array.

I *think* this is in agreement with the comment I made in my response
to Ton's email: object instances should be provided without respect to
how they were instanced: with groups, with duplicators, or using
alt-d. All that is necessary is to derive the transformations that
produced the instance.

> Why not just have one linked list of objects? - getting the type of
> object in one list could be nice, but that also means you need to create
> a new linked list each time the functions called. OR make an iterator
> that stores its type flag and only returns the object types you requested.

You could get all objects by doing:
void *allobjects = get_objects_by_type( GEOMETRY | LIGHT, scene );

I need to add a get_type function. You're right that some kind of list
would have to be setup for each of the several kinds of list-returning
queries in this system. I need a general freeing function for
handlers. I the longest lists that need exporting already have
structures within blender, so the api would only have to create an
interface structure to sit on top of them. The number of objects in a
scene would not be so great that performing sorting operations would
lead to significant inefficiency.

> Its not hard for the Plugin to loop through data of a spesific type
> (3 lines of a for loop) so Id recommend not adding tricky ways for the
> API to access spesific data types, probably more effort then its worth.
>
> **Instancing...
> **// returns a list of all data which is instanced multiple times within
> from
> ** void *get_instanced_data( void *from )
>
> You need to be careful here. even if a mesh is instanced in 10 places,
> one instance may have a modifier applied, the other dupliverts,
> particles, and another could have object materials (that are different
> from the mesh datas)

This means instanced data from the render's point of view. Like you
said, all modifiers would be collapsed and only if the resulting mesh
was instanced, then

>
> ** void *get_data_using( void *used, void *from, bool recursive )
>
> This seems arbitrary to me, there are so many ways data can link to
> other data, that 'using' could mean many things.
> A mesh can use a texmesh, material, an object can use other objects
> through modifiers, shape key IPO's etc.
>
> Id suggest not adding this. OR, clearly define how it works and give
> examples of where you would need it.

I think you're right, I need to rethink this function. If this kind of
query would be useful or needed for producing a render I will put in a
more rigorously defined version.

> **LIGHT_POINT = (1<<0),
> **LIGHT_SPOT = (1<<1)
> **LIGHT_SUN = (1<<2),
> **LIGHT_HEMI = (1<<3),
> **LIGHT_AREA = (1<<4),
>
> I dont see why these need to be unique bits, a simple enumerate should
> be fine for light types (since they cant be 2 types at a time)

I designed it this way so that these types could be or-ed together and
used in the get_objects_by_type function to request any combination of
types the render wishes to loop through at one time. It is the
get_lights, get_geometry, get_subsurfaces, etc. generalized. In fact,
it's generalized to the point that there are ways to use it that are
not conceivably useful.

> ** void *get_objects_by_type( unsigned int type, void *from )
>
> Again, probably a get_objects() would do.

I named it that to make it as explicit as possible what it does, and
to possibly allow the addition of "get_objects_by_*somethingelse*()"
For example the HTML DOM api uses these:
GetElementById()
GetElementsByName()

...after all, code is read more often than it is written. This is a
fact that much of blender's code is lamentably ignorant of. The heavy
use of extreme abbreviation makes the code significantly more
difficult to follow. I would not like to let these issues to bleed
into the API. A few extra characters on a name save a lot of time in
understanding the code later on.

>
> interested in other peoples feedback on this once, perhaps this is
> common and useful in other render api's.
>
> ** int get_index( void *index )
>
> What does this do?

Faces and edges return lists of index handlers. This is to retrieve
the index value from the handler.

Aaron