[Bf-committers] Preliminary Design (render api)
cbarton at metavr.com
Wed Jun 27 23:35:48 CEST 2007
I re-read the wiki and heres some suggestions for the 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.
**// returns a list of all data which is instanced multiple times within
** 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?
More information about the Bf-committers