[prev in list] [next in list] [prev in thread] [next in thread]
List: kpovmodeler-devel
Subject: Re: Frame System
From: "=?ISO-8859-1?Q?Miguel_Angel_G=F3mez_M=E1rquez?=" <atomicmx () gmail ! com>
Date: 2006-10-05 13:08:15
Message-ID: c49bcf870610050608r33079126hea59b6720d542f91 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
---
No, that is far to inflexible
---
Why? i'd ask in this case an example as an answer.
----
1) There may not allways be a simple function or interpolation. Imagine a
box that follows a sinus wave or an animation that is calculated in discret=
e
steps (explosions, flow simulation etc.)
----
And if there are not simple or easy what happens?
I didn't understand that comment, i don't have problems with math nor
numerical methods.
and if we use "external" functions this will let to implement several
functions and keep adding more functions without modifying the program code=
.
---
2) You modified my example scene to make it easier for you ;-)
----
Hmmm i didn't, thats how it would work, and it was going to be
easier to understand, i am not the kind of people who hiddes the
already found mistakes, if i were like that i would be only wasting
my time and speaking non sense.
I modify the example (and very little btw) because, i got to be a little bi=
t
stubborn with this
special point.
The clock (for the frame system) should not be used inside the code.
The clock should only be used as frame indicator.
---
I deliberately inserted the animated inverse flag and choose a scene where
an object (the csg) and a child object are both animated. Following your
example, the whole csg has to be exported twice with all child objects.
----
I didn't understood your inverse flag setting.
and please don't use clock parameters, clock
should only be used as global.
You don't need to declare each parameter, only
the "first child" or the child of your convenience.
example for this case:
With those comments you are impliying that those elements are to be
animated.
You don't need to declare inner levels.
//start csg
csg {
box {}
box {}
}
// end csg
csg {
box {}
box {}
}
---
My present approach to export non-povray properties is to serialize these
attributes with special comments. After all discussion I tend to do that
with all animation objects and scripts. Example of an animated scene with a
script where the rotation is calculated in discrete steps (the script will
be called once for each frame), and where corner 1 of the cube follows a
spline.
---
I thought i explained this earlier, or arent //PMBox1Begin special comments=
?
---
You still have all information for the animation for later use.
---
:S
In my approach you can have the numbers before the render if you like
remmember the animation parser before sending it to the serializer, (so you
can preview them in opengl, before rendering if you like to implement it)
And your approach is wrong because:
Say you stored all the animation in memory (instead of calculating for the
frame you are working on) if you increase from 10 frames to 20 (to smooth
the animation)
Your data in memory is totally useless
Suppose you want to start asynchronaly an object, that start in frame 3
instead of 0.
You will have to recalculate them all.
----
When the result satisfies you, you can render the scene without to
recalculate the animation.
----
So, in my explanation.
I feel like i am not making myself clear.
I already give an example about how to do that, without modifying the code.
// end csg
csg {
box {}
box {}
}
---
My present approach to export non-povray properties is to serialize these
attributes with special comments. After all discussion I tend to do that
with all animation objects and scripts. Example of an animated scene with a
script where the rotation is calculated in discrete steps (the script will
be called once for each frame), and where corner 1 of the cube follows a
spline.
---
I thought i explained this earlier, or arent //PMBox1Begin special comments=
?
---
You still have all information for the animation for later use.
---
:S
In my approach you can have the numbers before the render if you like
remmember the animation parser before sending it to the serializer, (so you
can preview them in opengl, before rendering if you like to implement it)
And your approach is wrong because:
Say you stored all the animation in memory (instead of calculating for the
frame you are working on) if you increase from 10 frames to 20 (to smooth
the animation)
Your data in memory is totally useless
Suppose you want to start asynchronaly an object, that start in frame 3
instead of 0.
You will have to recalculate them all.
----
When the result satisfies you, you can render the scene without to
recalculate the animation.
----
So, in my explanation. (if you like, its just matter of saving the
calculated tweend objects)
but you'd fall in the problems i posted before.
I feel like i am not explaining myself.
Buen d=EDa
Att. Miguel A. G=F3mez
[Attachment #5 (text/html)]
---<br>No, that is far to inflexible<br>---<br>Why? i'd ask in this case an=
example as an answer.<br><br><br>----<br>1) There may not allways be a sim=
ple function or interpolation. Imagine
a box that follows a sinus wave or an animation that is calculated in
discrete steps (explosions, flow simulation etc.)<br>----<br>And if there a=
re not simple or easy what happens?<br>I didn't understand that comment, i =
don't have problems with math nor numerical methods.<br>and if we use "=
;external" functions this will let to implement several functions and =
keep adding more functions without modifying the program code.
<br><br>---<br>2) You modified my example scene to make it easier for you ;=
-)<br>----<br>Hmmm i didn't, thats how it would work, and it was going to b=
e<br>easier to understand, i am not the kind of people who hiddes the<br>
already found mistakes, if i were like that i would be only wasting<br>my t=
ime and speaking non sense.<br><br>I modify the example (and very little bt=
w) because, i got to be a little bit stubborn with this<br>special point.
<br><br>The clock (for the frame system) should not be used inside the code=
.<br>The clock should only be used as frame indicator.<br><br><br><br>---<b=
r>I deliberately inserted the animated inverse flag and choose a scene wher=
e an object (the csg) and a child object are both animated. Following your =
example, the whole csg has to be exported twice with all child objects.
<br>----<br>I didn't understood your inverse flag setting.<br>and please do=
n't use clock parameters, clock<br>should only be used as global.<br><br>Yo=
u don't need to declare each parameter, only<br>the "first child"=
or the child of your convenience.
<br>example for this case:<br>With those comments you are impliying that th=
ose elements are to be animated.<br>You don't need to declare inner levels.=
<br>//start csg<br>csg {<br> box {}<br> box {}<br>}<br>// end c=
sg<br>
csg {<br> box {}<br> box {}<br>}<br><br>--- <br>My present approa=
ch to export non-povray properties is to serialize these attributes with sp=
ecial comments. After all discussion I tend to do that with all anima=
tion objects and scripts. Example of an animated scene with a script where =
the rotation is calculated in discrete steps (the script will be called onc=
e for each frame), and where corner 1 of the cube follows a spline.
<br>---<br>I thought i explained this earlier, or arent //PMBox1Begin speci=
al comments?<br><br>---<br>You still have all information for the animation=
for later use.<br>---<br>:S<br>In my approach you can have the numbers bef=
ore the render if you like remmember the animation parser before sending it=
to the serializer, (so you can preview them in opengl, before rendering if=
you like to implement it)
<br>And your approach is wrong because:<br>Say you stored all the ani=
mation in memory (instead of calculating for the frame you are working on) =
if you increase from 10 frames to 20 (to smooth the animation)<br>Your data=
in memory is totally useless
<br>Suppose you want to start asynchronaly an object, that start in frame 3=
instead of 0.<br>You will have to recalculate them all.<br><br>----<br>Whe=
n the result satisfies you, you can render the scene without to recalculate=
the animation.
<br>----<br>So, in my explanation.<br>I feel like i am not making myself cl=
ear.<br>I already give an example about how to do that, without modifying t=
he code.<br>// end csg<br>
csg {<br> box {}<br> box {}<br>}<br><div><div><br>--- </div>=
My present approach to export non-povray properties is to serialize these a=
ttributes with special comments. After all discussion I tend to do th=
at with all animation objects and scripts. Example of an animated scene wit=
h a script where the rotation is calculated in discrete steps (the script w=
ill be called once for each frame), and where corner 1 of the cube follows =
a spline.
<br>---<br>I thought i explained this earlier, or arent //PMBox1Begin speci=
al comments?<br><br>---<br>You still have all information for the animation=
for later use.<br>---<br>:S<br>In my approach you can have the numbers bef=
ore the render if you like remmember the animation parser before sending it=
to the serializer, (so you can preview them in opengl, before rendering if=
you like to implement it)
<br>And your approach is wrong because:<br>Say you stored all the ani=
mation in memory (instead of calculating for the frame you are working on) =
if you increase from 10 frames to 20 (to smooth the animation)<br>Your data=
in memory is totally useless
<br>Suppose you want to start asynchronaly an object, that start in frame 3=
instead of 0.<br>You will have to recalculate them all.<br><br>----<br>Whe=
n the result satisfies you, you can render the scene without to recalculate=
the animation.
<br>----<br>So, in my explanation. (if you like, its just matter of saving =
the calculated tweend objects)<br>but you'd fall in the problems i posted b=
efore.<br><br>I feel like i am not explaining myself.<br><br><br>Buen d=EDa
<br>Att. Miguel A. G=F3mez<br></div>
List archive and information: https://mail.kde.org/mailman/listinfo/kpovmodeler-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic