[Bf-committers] Final Design of Basics (render api)

Aaron Moore two.a.ron at gmail.com
Fri Jun 29 23:30:39 CEST 2007

Hi Brecht,

> I agree ID properties are not necessary here. In fact I would only
> allow storing a single pointer, not multiple name/value pairs. That
> pointer could internally be stored in a hash with a ID* -> void*
> mapping. Alternatively, the API could expose some pointer that the
> user of the API can use in their own hash.

I saw this kind of thing being done in the plugin api. I thought it
would work well here. Let the renderer define what custom data it
wants to keep tabs on. Of course, this means that the same custom data
structure must be used for the various types of library data, but I
think it's possible to design it so this isn't a problem.

struct TemporaryData;
typedef struct TemporaryData TemporaryData;

TemporaryData *get_objects_temporary_data( ObjectHandler object )
void set_objects_temporary_data( ObjectHandler object, TemporaryData *temp )

The temporary-data structure must be implemented in some way by the
exporter, albeit this could be an empty definition if it's not needed.

I've written this into the render API page:

Does this seem good? I thought of this before reading your email. It
would work, but this might be a bit cleaner, I think, and avoids using

> For object transformations, I would use only the 4x4 matrix. The
> object transforms are stored as rotation / scale / translation, but
> after that there can be additional transformations due to parenting,
> constraints, .., that will only update the matrix. I think the matrix
> might also include shearing? It seems the most simple and least
> ambiguous to use a matrix.

I could leave these out. The idea was that both sets of transformation
would be getting their data from the final transformation matrix, so
the parenting/constraints issued wouldn't come up.

 The translation, rotation, scale (I could add shear) functions would
save individual exporters from writing their own separate definitions
of commonly needed functions. For example, I know that renderman
lights need coordinates in xyz and not in a transformation matrix.
Furthermore the exporter would need to use the rotation information to
determine the direction of the light. These functions would have to be
written for renderman, and possible others, so why not included them
in the API. Though if these are considered shaky by others, it never
hurts to leave out functions not strictly needed.

> I would also keep out of the API the functions to get/set coordinate
> systems, instead define clearly in which space each coordinate is.

So you're saying from a rendering standpoint, each set of data only
needs to be possible to get one well-defined transformation for? I
admit, I can't think of when this would be needed, it was just an
intuition. Since this can always be added later if it is needed, I'll
leave these out for the moment.

> I think all functions, enums and typedefs need a prefix, to make clear
> what is part of the API, and to avoid name collisions.

Right, I'll do this.

Thanks for the feedback!


More information about the Bf-committers mailing list