[x3d-public] dynamic cycleInterval changes

Fri Feb 21 13:33:12 PST 2020

Hi Mike,

it is currently possible to make a Timesensor inactive by stopping or
setting loop to false. Then cycleInterval can be set to a new value and the
Timesensor can be restarted by setting a startTime, to now for example.

This will restart at the start of a cycle but should beat reloading the
page. Actually, you may be able to compute the exact startTime which would
give you the same fraction before cycleInterval was changed.

I agree with Leonard that spec. changes would be necessary to allow for
consistent, unrestricted cycleInterval changes without jumps in the
fraction.

I became interested in Godot, a fully open game engine which allows for x3d
like multiparenting. For animations it allows a time scale factor,
apparently like most game engines. A scale factor makes time run faster or
slower by multiplying any time by it. I am not sure that such a factor
could be useful for x3d but it seems it is a common concept.

Andreas

Date: Fri, 21 Feb 2020 11:21:40 -0800

> From: Mike McCann <mccann at mbari.org>
> To: X3D Graphics public mailing list <x3d-public at web3d.org>
>
>
> A brief shoutout to the value of this mail list, and the Pipermail archive!
>
> I?m finally attempting to improve the user experience of my web app and
> one of the things that?s annoyed me is that in order to adjust the
> animation playback speedup I would simply reload the whole scene (using
> x3dom). This always seemed unnecessary to me as only thing being changed in
> the scene was the cycleInterval in the TimeSensor.
>
> Reading through this old thread has been instructive, though not
> encouraging. I?m wondering now what is the best practice. Should I adjust
> the keyValues in my interpolators instead of adjusting cycleInterval in
> TimeSensor?
>
> -Mike
>
> Mike McCann
> Sr Software Engineer
> P (831) 775-1769   F (831) 775-1620
>
>
> Monterey Bay Aquarium Research Institute
> 7700 Sandholdt Road, Moss Landing CA 95039
> www.mbari.org <http://www.mbari.org/>
> Advancing marine science and engineering to understand our changing ocean.
>
>
> > On Nov 25, 2016, at 3:01 PM, Andreas Plesch <andreasplesch at gmail.com>
> wrote:
> >
> > The purpose of modifying the cycleInterval is to slow down or speed up a
> linked interpolater, in most cases. There is another way to achieve the
> same effect which is to modify the keyValue field of an interpolater. The
> equivalent of doubling the cycleInterval would be to half all values in the
> keyValue field array.
> >
> > Should both modifications have the same effect ?
> >
> > I think it is possible to change keyValues at any time. When the
> interpolater is then used for the next time step, the interpolated value is
> then computed from the new keyValues, eg. to half of the value it was
> before the change, in the example above. The animation jumps back.
> >
> > To mimic this effect for changes to cycleInterval, it would be necessary
> that the fraction is recomputed in the time step following the change. So a
> doubling of the cycleInterval would lead to jump from 0.4 to 0.2 of the
> fractional time.
> >
> > Overall, I do think that the expectation of most would be that changes
> in cycleInterval do not lead to jumps, eg. that fraction does not change.
> >
> > Andreas
> >
> >
> > On Nov 25, 2016 3:50 PM, "Don Brutzman" <brutzman at nps.edu <mailto:
> brutzman at nps.edu>> wrote:
> > [continuing dialog...]
> >
> > On 11/23/2016 10:59 AM, Leonard Daly wrote:
> > Don,
> >
> > I disagree with your concluding comment "Best place to fix this is in
> TimeSensor algorithm/code itself." The specification states (as you quote)
> "An active TimeSensor node ignores set_cycleInterval ... events". The spec
> needs to change for the TimeSensor to receive, process, and act of an
> incoming event that changes cycleInterval.
> >
> > Perhaps a better solution is to change the spec to allow TimeSensor to
> accept and process cycleInterval changes.
> >
> > Yes that was the entire point of the specification comment: to change
> TimeSensor specification prose (and corresponding algorithm) to allow
> dynamic cycleInterval changes.
> >
> > So perhaps there is some basis for agreement here after all?
> >
> > Am looking at the specification comment description, hopefully it is
> clear.  Roy if appropriate please improve when entering in Mantis, as you
> think best.
> >
> >
> >         "Issue: TimeSensor cycleInterval needs to be modifiable when
> running"
> >
> > The question that would need to be resolved is what happens to the
> current cycle.
> >
> > Yes that is the important next question if cycleInterval is dynamically
> modified for a running TimeSensor.
> >
> >  I can see three options
> >
> > 1) The TimeSensor would reset (stop and start from the beginning). This
> works for looping sensors, but may cause problems on a single pass sensor,
> or one that must have a specific number of cycles before stopping.
> >
> > 2) The TimeSensor would jump to the same fractional time. For example if
> the TimeSensor is .4 of the way through a cycle with cycleInterval of 10
> (i.e. 4 seconds in), and the cycleInterval was changed to 20, the
> fractional time would still be .4, but it would take 12 seconds to complete
> the remaining interval. This is probably the most benign option. It does
> lead to sudden velocity changes in any animating object.
> >
> > 3) The TimeSensor would jump to the same real time. For example if the
> TimeSensor is .4 of the way through a cycle with cycleInterval of 10 (i.e.
> 4 seconds in), and the cycleInterval was changed to 20, the fractional time
> would become .2 taking the full 20 seconds to complete this cycle. This
> options leads to sudden position changes in any animating object.
> >
> > There can be other variants where the change happens smoothly, but it
> may not be worth trying to standardize all possibilities.
> >
> > Leonard Daly
> >
> > My thinking was that, other than accepting a set_cycleInterval event, we
> should try to avoid any other algorithmic changes unless shown to be
> absolutely necessary.  Specification complexity can be confusing to authors
> (witness the current cycleInterval problem) and inconsistently implemented
> if not careful.
> >
> > Suggested approach is to consider typical animation examples, use those
> to determine if anything must be changed in spec, implement and evaluate.
> >
> > I suspect that your option (2) is most likely closest to a
> least-interference update in the algorithm.
> >
> > This minimalist approach seems workable if cycleInterval is dynamically
> reduced (or lengthened) significantly.  Of interest is that subsequent
> set_fraction events make sense as well.
> >
> > Of course an author retains full control whatever is decided here...
> They can always stop/modify/restart a TimeSensor clock, but have to be
> willing to do that across multiple event loops in order to achieve
> deterministic response (just like the currently existing situation).
> >
> > Thanks for scrutiny of this relatively small X3D change which appears to
> have important potential improvements for HTML5/DOM and VR external
> interoperability.
> >
> >
> > Comment on 19775-1: Abstract X3D Definitions - V3.3
> > 8.4.1 TimeSensor
> >
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#TimeSensor
> <
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#TimeSensor
> >
> >
> > -----------------
> > Issue: TimeSensor cycleInterval needs to be modifiable when running
> >
> > It is not feasible to modify TimeSensor cycleInterval without major
> > machinations and likely failure.
> >
> > Spec sayeth:
> >
> > 8.4.1 TimeSensor
> > "An active TimeSensor node ignores set_cycleInterval and set_startTime
> > events. An active TimeSensor node also ignores set_stopTime events for
> > set_stopTime less than or equal to startTime."
> >
> > Email discussion illustrates difficulties with modifying cycleInterval
> > without error.
> > Subject: dynamic cycleInterval changes
> >
> http://web3d.org/pipermail/x3d-public_web3d.org/2016-November/005566.html
> <http://web3d.org/pipermail/x3d-public_web3d.org/2016-November/005566.html
> >
> >
> > Issues such as event-arrival nondeterminism, usability and HTML5/DOM
> > interoperability are all interrelated on this topic.
> >
> > Best place to fix this is in TimeSensor algorithm/code itself.  Necessary
> > change is to make TimeSensor cycleInterval modifiable when running in
> order
> > to avoid two-phase commits and a host of other difficulties.
> >
> > -----------------
> >
> > Submitted on Wednesday, 2016,  November 23 - 8:42am
> > by brutzman (brutzman )
> > IP: 162.225.68.164 <tel:162.225.68.164>
> >
> > See: http://www.web3d.org/node/1694/submission/1072 <
> http://www.web3d.org/node/1694/submission/1072>
> >
> > all the best, Don
> > --
> > Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu <mailto:brutzman at nps.edu>
> > Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
>  +1.831.656.2149 <tel:%2B1.831.656.2149>
> > X3D graphics, virtual worlds, navy robotics
> http://faculty.nps.edu/brutzman <http://faculty.nps.edu/brutzman>
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200221/6bddbb7d/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 131, Issue 21
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200221/63232c96/attachment-0001.html>