Patrick Elliott <sel### [at] rraznet> wrote:
> See, I don't disagree with you about that at all. But it brings up a 
> problem how how you "tell" the parser that the object you are defining 
> is "supposed" to be changed later. It also doesn't address other issues.

  How are you going to tell it that regardless of the transformation array?

  The only "problem" your transformation array "solves" is that it makes
it possible to change individual transformations stored in that array.
However, that doesn't solve the issue of *how* you are going to change
those transformations in later frames. What kind of code will you write
in order to do that?

  And that's exactly why the transformation array is not needed: The exact
same code that can be used to change the array can also be used to apply
all the transformations (optionally modified from previous frames) to the
object.

  Besides, your array solution presents other problems which are not
problems in a "apply transformations with SDL code". For example, what
if you want to insert a new transformation somewhere in the series of
transformations? Or what if you want to remove some transformation?
What if you want an alternative series of transformations at different
frames?
  You would need to offer all kinds of functions to modify the array,
and the user needs to write some SDL code to call those modifications.

  However, with the same effort the user could simply call the functions
which apply transformations to the object directly. Adding or removing
transformations is simply a question of putting them in conditional
statements. Applying alternative series of transformations is simply a
question of if-else or switch blocks.

  There's no need for a transformation array.

> Sigh.. Your just getting it at all. The ***existing*** SDL assumes that 
> each "frame" is "static", as so is the object. Its not possible in the 
> current design to change the matrix for and object in "any" sense other 
> than in the final object.

  That's not a technical limitation. That's just a syntax limitation.

  It would be perfectly possible in the current POV-Ray to change the
transformation matrix of an existing object if someone simply added the
proper syntax for it. (And that's exactly one of the reasons why the
whole new SDL is being discussed. To add easy support for such things.)

> In an SDL that supports its own animation/render functions, you can't 
> have "static" objects.

  POV-Ray doesn't assume that objects are "static". It's just that there's
no syntax to change the transformation matrix of an existing object. Plain
and simple.

> 1. Track the transforms for the object, then simply 
> replace the one you need to change. 2. Generate a static object 
> "anyway", then apply your own transform to its parts, to produce the 
> result you want. Either way you are going to be using memory to do it.

  Why do you have this obsession that individual transformations *must*
be stored somewhere?

  You *apply* transformations in the SDL code. You don't *store* them
(not as individual transformations anyways). That's because the individual
transformations are already "stored" in the SDL code itself. Why do you
need to store them in two places?

  At each frame you simply execute that SDL which applies the transformations
to the objects.
  You are going to have to execute some SDL at each frame anyways (to
change transformations). It's not any more difficult to simply execute
the SDL code which applies all the transformations.

> Look, if you still think I am full of it, then why not agree on some 
> example concept, with a specific number of parts, etc. Then each of us 
> can give a psuedocode example of what the hell we are talking about, 
> because I am not entirely sure I am not missing something you are trying 
> to get across too.

  Let me see your suggestion about the new SDL code which modifies the
"transformation array" at each frame.
  My answer is that it's the exact same thing, but without the transformation
array. Simply apply all the transformations to the object at each frame.

-- 
                                                          - Warp

Post a reply to this message