[x3d-public] TimeSensor resumeTime field [Mantis 1106]

Mon Dec 19 11:33:22 PST 2016

On Mon, Dec 19, 2016 at 12:49 PM, Leonard Daly <Leonard.Daly at realism.com>
wrote:

> On 12/19/2016 8:36 AM, Andreas Plesch wrote:
>
> 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.
>
>
> What I did was to create a TimeSensor with a cycleInterval of 1. That was
> ROUTEd to a Script where all of the time control happened. I may have had a
> 1 second granularity on my controls - I don't remember the details. If you
> want continuous control (at least down to 0.01 seconds), then it can get a
> little messy to deal with all of the different possibilities.
>
> I believe I set it up so the single TimeSensor drove as many
> pseudo-TimeSensors as I needed. The calculation was in a local function and
> controls and output events were manually added to the structure as needed.
>
> It seems overkill to require a Script to do something pretty basic.
> Unfortunately, we didn't fully appreciate the fundamental change we were
> making to time.
>
>
Ok, I just was not sure if there is some basic, easy method for pausing. It
looks there is not, and that was motivation to introduce the pausing
related fields.

-Andreas

> Leonard Daly
>
>
>
>
>
> 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-Decembe
>> r/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/listi
>> nfo/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
>
>
>
> --
> *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/1407fcdd/attachment-0001.html>