[x3d-public] TimeSensor resumeTime field [Mantis 1106]
Andreas Plesch
andreasplesch at gmail.com
Mon Dec 19 12:26:06 PST 2016
On Mon, Dec 19, 2016 at 12:42 PM, Don Brutzman <brutzman at nps.edu> wrote:
> I agree that this is a really important behavior that we must ensure is
> well specified and consistently implemented: whether TimeSensor follows a
> wall clock or a simulation clock when paused/resumed.
>
> a. A related pathology is when a TimeSensor with loop="true" commences; it
> looks like some players assume startTime = 0 instead of startTime =
> clocktime at initial start. This means that such a TimeSensor commences
> somewhere in the middle of the loop... not good for animation initiation.
> Identifying test scenes for conformance would be good. Perhaps at
>
> X3D Example Archives: Conformance Nist, Sensors, Time Sensor
> http://www.web3d.org/x3d/content/examples/ConformanceNist/
> Sensors/TimeSensor/
>
>
There are good tests but I did not see any for pausing ?
The default value for startTime in the node signature at
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#TimeSensor
is indeed 0 which is the time origin. Is it possible/sensible to specify
now as a default ?
> b. We should further specify that multiple TimeSensors getting loaded from
> the same initial scene will also initiate at the same time.
>
> Further synchronization with Inline scenes is possible by employing
> LoadSensor and having a shared author-initiation event once everything is
> loaded.
>
> c. 8.4.1 TimeSensor does not mention elapsedTime isPaused pauseTime or
> resumeTime, which is poor style. In addition to the TimeSensor sentence
> referring to 8.2 Concepts, we should add something like
>
> The computation of elapsedTime is defined in _8.2.4.2 Time cycles_.
> http://www.web3d.org/documents/specifications/19775-1/V3.3/
> Part01/components/time.html#Timecycles
>
> The effects of the isPaused pauseTime and resumeTime fields are
> defined by _8.2.4.4 Pausing Time_.
> http://www.web3d.org/documents/specifications/19775-1/V3.3/
> Part01/components/time.html#PausingTime
>
> d. It looks like paragraph 3 of 8.2.4.4 Pausing Time answers the original
> question:
>
> "An active but paused time-dependent node shall resume at the
> first simulation tick when now ≥ resumeTime > pauseTime. The time-dependent
> node then resumes generating its output events from the paused state at the
> simulation tick. A resumeTime_changed event is also generated reporting the
> simulation time when the node was resumed."
>
>
Yes, it should. It just was not quite clear to me what the "state"
includes. If it includes startTime in addition to fraction_changed, then
the formula given for fraction_changed cannot apply anymore after resuming.
Also, x3dom behaves in a different way and other browsers may as well.
> e. If an author indeed wants wall-clock related behavior instead of smooth
> pause/resume continuation of state (i.e. smooth fraction_changed values),
> then their event resumption should simply set startTime = 0.
>
Probably only if the initial startTime was also 0. But resuming needs to
continue the paused state ? So resuming would reset startTime anyways ?
It looks to me that resumeTime can only be used for smooth continuation.
Stopping and starting with startTime of 0 (rather than now) should work.
But it probably requires first sending a stopTime of now (should
deactivate), and then sending a startTime of 0 (should activate?), then
sending a stopTime of 0 or a desired future time (to keep it running).
f. We should check the following closely: "Figure 8.1 — Examples of
> time-dependent node execution".
>
Yes, since the figure is in the 8.2.4.4 Pausing Time section I was looking
there for clarification how pausing time works. But pauseTime et al. is not
shown. The figure probably should be in the previous section 8.2.4.3 Time
activation. It is a complicated, busy figure though I think accurate and
helpful.
> Likely a good topic for X3D Working Group discussion.
>
>
> 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.
>> 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
>> <mailto: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 <http://web3d.org/pipermail/x3
>> d-public_web3d.org/2016-December/005692.html>.____
>>
>> __ __
>>
>> Regards,____
>>
>> __ __
>>
>> Roy____
>>
>> __ __
>>
>> *From:*x3d-public [mailto:x3d-public-bounces at web3d.org <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 <mailto:
>> Leonard.Daly at realism.com>>
>> *Cc:* X3D Graphics public mailing list <x3d-public at web3d.org <mailto:
>> 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
>> <mailto: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 <http://www.web3d.org/document
>> s/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
>>
>
> all the best, Don
> --
> Don Brutzman Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzma
> n
>
--
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/8411d30a/attachment-0001.html>
More information about the x3d-public
mailing list