[Bf-committers] Final Design of Basics (render api)
Brecht Van Lommel
brechtvanlommel at pandora.be
Fri Jun 29 22:28:59 CEST 2007
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.
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.
More information about the Bf-committers