[Bf-committers] Final Design of Basics (render api)
lynx at aspect-design.de
Sat Jun 30 16:36:30 CEST 2007
Hm i'm not sure i understand everything.
Do i understand correctly that in the end, all "handlers" are
just void pointers in disguise again? And for each API call i
have to pass it to tell the API which element i mean?
Will it always point to the same struct that just gets updated?
It also seems you plan an extra callback for each and every
property, and only return primitive types (int, float or arrays
of ints, floats and chars...).
I think that way those could become quite a lot of function and
may grow faster than people can update their plugins...
did you consider some "generic" structs for lights, cameras etc. that
hold the basic information that probably every renderer will query anyway,
instead of getting every single attribute with an extra function call?
Unless i'm mistaken, C structs have the nice property that you can
append members without breaking binary compatibility of older plugins,
they simply won't know there's additional information now.
Also some snippets of the pseudo code look a bit odd to me...
/* Export Geometry */
for( object = Rapi_get_objects( scene, Rapi_GEOMETRY );
Rapi_object_exists( object );
Rapi_get_next_object( object ) )
geometry = Rapi_object_get_geometry( object );
Rapi_geometry_to_polygon_mesh( geometry );
export_polygons( object );
Why does export_polygons() get "object" and not "geometry"?
And when is the geometry Rapi_geometry_to_polygon_mesh()
potentially creates freed again?
And what about ID Properties now? Is there a way planned
to get them? Because i think i *really* need them. All the new
yafray features are configured there, because blender settings
simply do no apply for many things.
Setting those has not to be your problem, we currently use/develop a
python interface that gives a nice compromise between integration
and support for non-blenderish things.
More information about the Bf-committers