Re: Frame System
"Miguel Angel Gómez Márquez" <[email protected]> Thu, 5 Oct 2006 10:14:50 +0200
| Newsgroups | gmane.comp.kde.devel.kpovmodeler |
|---|---|
| Message-ID | <[email protected]> |
--===============0728140652==
Content-Type: multipart/alternative;
boundary="----=_Part_5318_11676352.1160036090945"
------=_Part_5318_11676352.1160036090945
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
---
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 =3D 0 )
box{ <2,1,1>,<2,1,2> pigment{} (initial status)
//PMEnd5 (stop tween in frame 5 or clock =3D 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 =3D 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 exportatio=
n
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 permi=
t
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 t=
o
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 animatio=
n
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 Begi=
n
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 =C1. G=F3mez
------=_Part_5318_11676352.1160036090945
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
---<br>That sounds nice, but I need an example for that.<br>---<br>Yes, i a=
m working on it. <br><br>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 d=
o it, but it doesn't convince me yet.=20
<br>(by layout design reasons).<br><br>---<br>How will your povray code (in=
clusive the animated points) look<br>like?<br>---<br>The answer to your cue=
stion may cause confusion.<br>The povray code before de serializer will loo=
k like:
<br><br>union {<br> box{ <-1, -1, -1>, <1, 1, 1> pigment{=
}}<br> //Linear (says that we will use a linear tween)<br> //PMBo=
x1Begin (because is the first animated box fo the whole)<br> //P=
MStart1 (start tween in frame one or clock =3D 0 )
<br> box{ <2,1,1>,<2,1,2> pigment{} (initial status)<br>&=
nbsp;//PMEnd5 (stop tween in frame 5 or clock =3D 4 )<br> //PMBox1End&=
nbsp; (the tween ends here)<br> box{ <2,4,1>,<2,6,2> pigm=
ent{} (final status)<br>
}<br> rotate x*clock (the clock should be used onl=
y for frame control)<br>}<br><br>We have virtually (in the opengl window) 3=
boxes, 1 real box and 2 tweenpoints for an animated box.<br><br>So in the =
tween (or animation) processor, we parse the animation tags and should end =
up like this:
<br> =
&=
nbsp; CLOCK =3D 3<br><br>union {<br>
box{ <-1, -1, -1>, <1, 1, 1> pigment{}}<br> box{ &l=
t;2,2.8,1>,<2,4,2> pigment{}}<br>
rotate x*clock (the clock should be used only for frame contro=
l)<br>
}<br><br>so, we call the render widget for each clock time, and we get the =
animation done<br>:D :D :D :D<br><br>And with this struct=
ure i can make the script/parser to make the exportation to 1povray file :)=
(i already know how to do it).
<br><br>---<br>Putting comments at the beginning and end of an object shoul=
d be<br>possible in a clean way with the current povray serializer.<br>---<=
br>Yes, i just wanted to make it out of the serializer because, it would pe=
rmit to cleanly modify the animation "parser" or serializer witho=
ut compromising the stability of the actual serializer.
<br><br>---<br>If you implement a frame system there needs to be<br>an obje=
ct that records the scene changes during animation or during<br>--- <br>No =
it wouldn't need it ammm perhaps with the example its more clear what i int=
ended to do, we would calculate the specific parameters for the object to b=
e tweened and it would depend on a global clock, not a clock inserted in ea=
ch 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).
<br><br>---<br>Maybe it can use the undo/redo system with the<br>PMMemento =
class. That should make your two objects obsolete.<br>---<br>No, you alread=
y implemented it i mean the objects should be manages just as they are mana=
ged actually, the tags may be inserted as "objects" click Begin t=
ween, drop End tween, or just a box, layout, or something (this is exactly =
what i am worried ad i posted in the beginning.)
<br><br>And well, as result of this techky, we keep the clean framework, mo=
dularity and flexibility of the parts, and won't modify but 4 o 5 files.<br=
><br>Have a bright day<br>Miguel =C1. G=F3mez<br>
------=_Part_5318_11676352.1160036090945--
--===============0728140652==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
List archive and information: https://mail.kde.org/mailman/listinfo/kpovmodeler-devel
--===============0728140652==--