Re: [SMIL30 LC comment] 12. SMIL 3.0 Time Manipulations

.....

>
> > -------------
> >
> > 12.3.2
> >
> > 'It will produce a simple pendulum swing on the target
> > (assume that the target is a pendulum shape with the transform
> > origin at the top):
> > <animateTransform type="rotate" from="20" to="-20" dur="1s"
> > repeatCount="indefinite"
> >         accelerate=".5" decelerate=".5" autoReverse="true" ... />
> >
> > The pendulum swings through an arc in one second, and then back again
> > in a second.
> > ....
> > This produces a realistic looking animation of real-world pendulum
> > motion.'
> > -> Note that the motion of a (rotating, mathematical) pendulum is an
> >     anharmonic oscillation. It is technically not easy to build a
> >     pendulum
> >     with such a motion, therefore real-world pendulums behave
>>     different.
> > -> The motion related to these attributes is that of a constant force
> >     (free fall close to the earth surface) as far as I understand this.
> >     With this example it should be possible to produce a quadratic spline
> >     approximation for a harmonic oscillation, because it includes
> >     autoReverse="true", however I did not check, if the given example
> >     really is the correct quadratic spline approximation for a sine
> >     related
>
> >     to a harmomic oscillation and it is not the motion of a pendulum,
> >     especially not for large amplitudes.
> > -> For (an)harmonic oscillations the autoReverse is still very useful,
> >     but the approximation of the motion requires itself a 
> >     values-animation with calcMode spline and maybe keyTimes. 
> >     Additionally the values list needs to be calculated symmetrically
> >     around '0' to make use of the autoReverse.
>
> Changed the wording to "... a rough approximation of a pendulum swing".
> Note that it can hardly be expected that an implementation is accurate
> enough to tell the difference.
>

'... an approximation of a pendulum swing' would be already sufficient,
qualitative or even quantitative evaluation on the approximation quality 
for whatever purpose can be left to the reader/user in this case...

....

> > -------------
> > 12.3.3
> >
> > wording?
> >
> > 'r(t) is the speed modification due to acceleration and deceleration,
> > at any time t within the simple duration.'
> >
> > -> as far as I understand this, r(t) is the run rate itself at any time t,
> > not its modification, this would be dr/dt and would be called 
> > acceleration. 
> > better:
> > ->
> > 'r(t) is the run rate, time dependent due to acceleration and 
> > deceleration, 
> > at any time t within the simple duration.'
>
> Actually it *is* a modification, since there is a cascading effect if
> time manipulations are nested.

Well, if r(t) is something different than r, this requires another 
symbol/glyph, especially if it appears in the same section/chapter.

If r is a constant, then r(t) = r, constant and nothing else.
To describe the change or r one may write
dr(t)/dt, especially if r is constant in time, dr(t)/dt=0. 

If the recommandation has another term/variable/entity in mind,
another symbol has to be used, for example
s(t) is the speed at each time t during the duration of the element.

This is not much related to the meaning of the local 'time' t in the
current position of the document. To get the relation to an 'ordinary 
time', lets call it 'o', one may write dr(o)/do = dr/dt * dt/do.

>
> The run rate r is defined as the maximum speed during playback.  The
> speed accelerates from 0 to the run rate during the acceleration phase,
> runs at the run rate until the deceleration phase, and then decelerates
> to 0.   Using this definition the total time that is needed to play the
> element doesn't change.
>
> r(t) is the speed at each time t during the duration of the element,
> taking acceleration and deceleration into account.  But because of
> cascading effect, it isn't necessarily the speed, but just the local
> modification of the speed.
>
>
> ----

Received on Thursday, 25 October 2007 13:07:27 UTC