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

[Brecht Van Lommel]

Hi,

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.

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 would also keep out of the API the functions to get/set coordinate 
systems, instead define clearly in which space each coordinate is.

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

Cheers,
Brecht.

Aaron Moore wrote:
> This is the way I'm currently thinking about the temporary custom data
> for exporters. It could be implemented using ID properties on the back
> end, but ID properties were design for something else, so I think that
> that would potentially create a conflict of interest when either
> system is subject to change, this is why I suggest leaving the design
> as it is. Unless there is a good reason not to support arbitrary data,
> but that is another discussion.
> 
> Aaron