[x3d-public] TimeSensor resumeTime field [Mantis 1106]
Andreas Plesch
andreasplesch at gmail.com
Mon Dec 19 08:36:29 PST 2016
Thanks Roy,
the next step may be to come up with a simple test scene (as I could not
find any in the x3d examples collection) and check how different x3d
browsers behave.
A directly related question is how x3d/vrml scenes managed pausing of
animations before pause/resumeTime was introduced ? If there is a well
known strategy/method for pausing, this issue may become almost irrelevant.
But it seems pausing would involve stopping, and then restarting with a
startTime at the appropriate time in the past:
timeOffset = fraction_changed_whenStopped * cycleInterval
startTime = now - timeOffset
Setting startTime of an inactive sensor to a time in the past seems to be
allowed.
This looks like it would require scripting, and does make a built in
pausing functionality more attractive.
-Andreas
On Mon, Dec 19, 2016 at 10:30 AM, Roy Walmsley <roy.walmsley at ntlworld.com>
wrote:
> Hi Andreas and Leonard,
>
>
>
> This is an interesting topic to capture for subsequent discussion and
> resolution. Thank you Andreas for raising it.
>
>
>
> I have, therefore, raised a Mantis issue based on Andreas’ original
> comment, to which I have appended Leonard’s reply and Andreas’ subsequent
> response as notes. The Mantis issue is 1106. It is available for Web3D
> members at http://web3d.org/pipermail/x3d-public_web3d.org/2016-
> December/005692.html.
>
>
>
> Regards,
>
>
>
> Roy
>
>
>
> *From:* x3d-public [mailto:x3d-public-bounces at web3d.org] *On Behalf Of *Andreas
> Plesch
> *Sent:* 17 December 2016 03:53
> *To:* Leonard Daly <Leonard.Daly at realism.com>
> *Cc:* X3D Graphics public mailing list <x3d-public at web3d.org>
> *Subject:* Re: [x3d-public] TimeSensor resumeTime field
>
>
>
> Leonard,
>
> On Dec 16, 2016 8:52 PM, "Leonard Daly" <Leonard.Daly at realism.com> wrote:
> >
> > [Note: I am OK with this being posted to x3d-public. I did not do so
> because it is originally Andreas' comment.]
> >
> > The answer depends on what is meant by a TimeSensor. Up until V3.2 (when
> pause was introduced), TimeSensor was always real-world time -- we didn't
> have a Dick Tracy watch that would pause (most) of the world. When pause
> was introduced, the intent was to create a pause in the progression of
> time, similar to a "Pause" button on tape/VCR/CD/DVD/Netflix... player. I
> believe that to be the desired behavior based on my memory of the
> discussions.
>
> The history is interesting and may explain the friction between the rigid
> fraction_changed formula and the expected resume behavior. elapsedTime
> explicitly excludes paused intervals. Would then a formula
>
> fraction_changed = elapsedTime mod cycleInterval / cycleInterval
>
> work to define fraction_changed ?
>
> I did not test other x3d browsers resumeTime behavior. Is there a
> conformance test scene ?
>
> > TimeSensor "senses" the passage of time and takes certain actions based
> on its internal (field) settings. This includes start, stop, pause, and
> resume. It also emits system time at certain points ('cycleTime' at the
> beginning of each cycle/loop and 'time' for event timestep). Except for
> these two fields everything else is relative (either a fraction or seconds
> of running-time).
>
> Ok, let's take the opportunity to review the time component.
>
> > What would it take to eliminate the system time from TimeSensor?
>
> System time is the same for all nodes within a scene and across scenes on
> the same system, so it does seem to play an important role, no ?
>
> > Obviously the startTime, stopTime, pauseTime, and resumeTime fields
> would need to change for controlling the sensor. The cycleTime field would
> not apply or perhaps it would be 'elapsedTime' when the loop restarts. The
> 'time' field is currently represented by elapsedTime for units of total
> seconds or fraction_changed for the fractional portion of the loop. Perhaps
> this could be extended to include the # times through the loop (e.g.,
> instead of .3, it would be 2.3 indicating two full loops + .3 through the
> third loop).
>
> The fractional portion only is needed for interpolators. Unless Yves
> suggestion for simple arithmetic expressions is adopted. An additional
> output field 'elapsedCycles' is another option.
>
> > The fields the control the input (startTime, stopTime, pauseTime, and
> resumeTime) would need to change (by function or replaced by a new field)
> to either indicate an operation (start, stop, pause, resume) or some sort
> of relative time in the world. Most everything is based on user action to
> initiate an in-world action. The biggest issue (I see) is synchronizing
> actions between multiple users. I don't think TimeSensor is the right way
> to do this anyway as TimeSensor depends on the local computer's clock and
> there is no guarantee that the time is correct or intervals are accurate.
>
> Synchronization requires synchronization of clocks at some point. Should
> there be a way to do this in x3d ? Intervals should be assumed to be
> reliable across systems (or all hope is lost?).
>
> Andreas
> >
> > Leonard Daly
> >
> >
> >
> >> A time sensor has a concept of pausing time:
> >>
> >> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/
> components/time.html#PausingTime
> >>
> >> When now reaches a pauseTime, the TimeSensor is put into a paused mode.
> It then resumes to generate output events such as fraction_changed when now
> reaches a resumeTIme.
> >>
> >> My question is if when resumeTime is reached, generated
> fraction_changed values should continue from where they were when the
> sensor was paused. To me this behaviour seems to be the intent of the
> pausing concept.
> >>
> >> "The time-dependent node then resumes generating its output events from
> the paused state at the simulation tick." is the spec. language.
> >>
> >> On the other hand, the formula given to calculate fraction_changed
> includes the difference between now and the startTime. In order to keep
> using this formula, startTime would need to be (internally) adjusted after
> resuming a paused sensor such that fraction_changed equals fraction_changed
> at pauseTime. Does adjusting the startTime constitute a change of the
> paused state ?
> >>
> >> x3dom currently does not continue fraction_changed from where it was
> paused. Instead, it just continues the output as if the sensor was never
> paused, eg. does not adjust startTime.
> >>
> >> -Andreas
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Andreas Plesch
> >> 39 Barbara Rd.
> >> Waltham, MA 02453
> >>
> >>
> >> _______________________________________________ x3d-public mailing
> list x3d-public at web3d.org http://web3d.org/mailman/
> listinfo/x3d-public_web3d.org
> >
> >
> >
> > --
> > Leonard Daly
> > 3D Systems & Cloud Consultant
> > LA ACM SIGGRAPH Chair
> > President, Daly Realism - Creating the Future
>
--
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161219/e97c872b/attachment.html>
More information about the x3d-public
mailing list