Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> But this could be handled in SDL, no ?

  The main problem is that this "store all transformations in an array
inside the object" is a hard-coded solution which makes no sense. It
needlessly fixes this "problem" (which really isn't a problem at all,
which is something they just cannot seem to comprehend) with one single
hard-coded solution. If someone would like to use a different approach
then the internal array would be a completely useless waste of memory.

  Let's assume someone is implementing something where he really wants,
for whatever reason, to store all the individual transformations in a
data structure (instead of simply executing a series of commands which
will accumulate the transformations into a single transformation matrix).
What happens if the data structure he wants to use is a list? What if he
wants to have *several* data structures containing alternative sets of
transformations? What if he wants the transformations in a binary tree?
He will have to implement these solutions in SDL, and the transformation
array inside the object will be a useless waste of memory.

  Moreover: What if, which will be the usual case, he doesn't need to
store the individual transformations anywhere? Who is going to give him
back the memory wasted by the useless internal transformation array?

  The right solution is to be able, at each frame, to apply a set of
transformations to the object as function calls (which syntax is to
be decided). Internally these transformations will work as currently
in POV-Ray (ie. they are accumulated into a transformation matrix).

  If someone really wants to use an array to store individual transformations
then he can do so. However, most importantly, he is not *forced* to do so
if he doesn't want to.

-- 
                                                          - Warp

Post a reply to this message