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

Mon Dec 19 09:42:13 PST 2016

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/

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

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.

f. We should check the following closely: "Figure 8.1 — Examples of time-dependent node execution".

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-December/005692.html <http://web3d.org/pipermail/x3d-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/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

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/brutzman