# [SMIL30 LC comment] 12. SMIL 3.0 Time Manipulations Classic List Threaded 5 messages Open this post in threaded view
|

## [SMIL30 LC comment] 12. SMIL 3.0 Time Manipulations

 Hello SMIL working group, some comments on chapter 12: 12.3.1 typo: '... as well as any time maniuplations defined ...' -> '... as well as any time manipulations defined ...' ------------- 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): 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. ------------- Example: "     " -> speed="2.0" ? ------------- 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.'
Open this post in threaded view
|

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

Open this post in threaded view
|

## 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): > > > 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. > > > ----