[Bf-committers] Preliminary Design (render api)

[Campbell Barton]

Hi Aaron,
I re-read the wiki and heres some suggestions for the render API...

http://wiki.blender.org/index.php/Render_API

**>>> 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?

** >>> 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.

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.

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)

To start with Id not add this function,
or, add it but make it check that none of the objects it returns have 
any of the above options enabled for them.
instancing lamps and other types are not as problematic as mesh data, 
however its usually mesh data that gains the most benefit from 
instancing (dont have to write the geometry data many times)


** 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.


**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)

** void *get_objects_by_type( unsigned int type, void *from )

Again, probably a get_objects() would do.

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?


- Cam