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

 Dear Dr. Olaf Hoffmann ,

The SYMM Working Group has reviewed the comments you sent [1] on the Last
Call Working Draft [2] of the Synchronized Multimedia Integration Language
(SMIL 3.0) published on 13 Jul 2007. Thank you for having taken the time to
review the document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at www-smil@w3.org if
you agree with it or not before 02 nov 2007. In case of disagreement, you
are requested to provide a specific solution for or a path to a consensus
with the Working Group. If such a consensus cannot be achieved, you will
be given the opportunity to raise a formal objection which will then be
reviewed by the Director during the transition of this document to the
next stage in the W3C Recommendation Track.

Thanks,

For the SYMM Working Group,
Thierry Michel
W3C Staff Contact

 1. http://www.w3.org/mid/200708121301.42551.Dr.O.Hoffmann@gmx.de
 2. http://www.w3.org/TR/2007/WD-SMIL3-20070713/


=====

Your comment on 12.3 Module Overview:
> 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):
> <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.
> 
> 
> -------------
> 
> Example:
> 
> "<par speed=2.0>
>    <animate begin="2s" dur="9s" speed="0.75" .../>
> </par>"
> 
> -> 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.'


Working Group Resolution:
Dr. Olaf Hoffmann wrote:
> 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 ...'

Fixed.

> -------------
> 
> 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.

> -------------
> 
> Example:
> 
> "<par speed=2.0>
>    <animate begin="2s" dur="9s" speed="0.75" .../>
> </par>"
> 
> -> speed="2.0" ?

Fixed.

> -------------
> 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.

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 Tuesday, 23 October 2007 09:08:28 UTC