Frame System

[Miguel Angel Gómez Márquez]

---
That sounds nice, but I need an example for that.
---
Yes, i am working on it.

What i am exactly doing is reviewing all the code (draft review) so i can
give a more structured example, i've found how to do it, but it doesn't
convince me yet.
(by layout design reasons).

---
How will your povray code (inclusive the animated points) look
like?
---
The answer to your cuestion may cause confusion.
The povray code before de serializer will look like:

union {
 box{ <-1, -1, -1>, <1, 1, 1> pigment{}}
 //Linear (says that we will use a linear tween)
 //PMBox1Begin  (because is the first animated box fo the whole)
 //PMStart1 (start tween in frame one or clock = 0 )
  box{ <2,1,1>,<2,1,2> pigment{} (initial status)
 //PMEnd5 (stop tween in frame 5 or clock = 4 )
 //PMBox1End  (the tween ends here)
  box{ <2,4,1>,<2,6,2> pigment{} (final status)
   }
 rotate x*clock  (the clock should be used only for frame control)
}

We have virtually (in the opengl window) 3 boxes, 1 real box and 2
tweenpoints for an animated box.

So in the tween (or animation) processor, we parse the animation tags and
should end up like this:
                                 CLOCK  = 3

union {
 box{ <-1, -1, -1>, <1, 1, 1> pigment{}}
 box{ <2,2.8,1>,<2,4,2> pigment{}}
 rotate x*clock  (the clock should be used only for frame control)
}

so, we call the render widget for each clock time, and we get the animation
done
:D  :D  :D  :D

And with this structure i can make the script/parser to make the exportation
to 1povray file :) (i already know how to do it).

---
Putting comments at the beginning and end of an object should be
possible in a clean way with the current povray serializer.
---
Yes, i just wanted to make it out of the serializer because, it would permit
to cleanly modify the animation "parser" or serializer without compromising
the stability  of the actual serializer.

---
If you implement a frame system there needs to be
an object that records the scene changes during animation or during
---
No it wouldn't need it ammm perhaps with the example its more clear what i
intended to do, we would calculate the specific parameters for the object to
be tweened and it would depend on a global clock, not a clock inserted in
each propertie. if we use the clock as global counter, and all the animation
algorithms relative to that clock, we would get a ready made frame control
(sort of).

---
Maybe it can use the undo/redo system with the
PMMemento class. That should make your two objects obsolete.
---
No, you already implemented it i mean the objects should be manages just as
they are managed actually, the tags may be inserted as "objects" click Begin
tween, drop End tween, or just a box, layout, or something (this is exactly
what i am worried ad i posted in the beginning.)

And well, as result of this techky, we keep the clean framework, modularity
and flexibility of the parts, and won't modify but 4 o 5 files.

Have a bright day
Miguel Á. Gómez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kpovmodeler-devel/attachments/20061005/8b38c1cb/attachment-0001.html