[Bf-committers] Preliminary Design (render api)

Campbell Barton cbarton at metavr.com
Thu Jun 28 01:58:43 CEST 2007


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

IMHO this issue is one of the most important issues that needs to be 
resolved ASAP so you can start writing up the code API.

Ton said

"""I would look starting with a call that makes a list of all
render-objects (instanciation, groups, duplicators). This is
blender-specific, and exporters then don't have to worry about our
weird features. Instancing information you can store at this stage too.
(Note; this only for objects, not render geometry)"""

To me this reads- dont let the render api worry about blender weirdo 
features, just collect the objects to render (and store instancing info 
at this stage too)

Im repeating myself here a bit :/ but I think this is important.
if others have better ideas, chime in.

get all the objects as one linked list for the render API to access. and 
give the render API access to it (the API wont modify it)

thats all you really need. - if you want to be explicit, call it 
get_all_objects()

for (ob = get_all_objects(); ob; ob = ob->next) {
     if (ob->type==OB_TYPE_CAMERA) {
         ...
     }
}


if youd prefer to have a type specific iterator you could make it work 
like blenders GHASH iter - BLI_ghash.c

/* its implicit that your looping on the 1 list of render objects
    this has the advantage that you dont need to expose that list to the 
API and are not dealing directly with ob->next
  */

/* could be all types to save you typing them all in */
iter = ObjectIterator_new(NULL);

/* or explicitly OR the types you need to loop over */
iter = ObjectIterator_new(OB_CAMERA_TYPE | OB_LAMP_TYPE);

while(!ObjectIterator_isDone(iter)) {
     ob = ObjectIterator_getValue(iter)
     ....
     ....
     ObjectIterator_step(iter);
}




More information about the Bf-committers mailing list