<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 19, 2016 at 12:42 PM, Don Brutzman <span dir="ltr"><<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
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<br>
<br>
X3D Example Archives: Conformance Nist, Sensors, Time Sensor<br>
<a href="http://www.web3d.org/x3d/content/examples/ConformanceNist/Sensors/TimeSensor/" rel="noreferrer" target="_blank">http://www.web3d.org/x3d/conte<wbr>nt/examples/ConformanceNist/<wbr>Sensors/TimeSensor/</a><br>
<br></blockquote><div><br></div><div>There are good tests but I did not see any for pausing ? </div><div>The default value for startTime in the node signature at <a href="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</a> is indeed 0 which is the time origin. Is it possible/sensible to specify now as a default ? </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
b. We should further specify that multiple TimeSensors getting loaded from the same initial scene will also initiate at the same time.<br>
<br>
Further synchronization with Inline scenes is possible by employing LoadSensor and having a shared author-initiation event once everything is loaded.<br>
<br>
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<br>
<br>
The computation of elapsedTime is defined in _8.2.4.2 Time cycles_.<br>
<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#Timecycles" rel="noreferrer" target="_blank">http://www.web3d.org/documents<wbr>/specifications/19775-1/V3.3/<wbr>Part01/components/time.html#Ti<wbr>mecycles</a><br>
<br>
The effects of the isPaused pauseTime and resumeTime fields are defined by _8.2.4.4 Pausing Time_.<br>
<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#PausingTime" rel="noreferrer" target="_blank">http://www.web3d.org/documents<wbr>/specifications/19775-1/V3.3/<wbr>Part01/components/time.html#Pa<wbr>usingTime</a><br>
<br>
d. It looks like paragraph 3 of 8.2.4.4 Pausing Time answers the original question:<br>
<br>
"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."<br>
<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br></blockquote><div><br></div><div>Probably only if the initial startTime was also 0. But resuming needs to continue the paused state ? So resuming would reset startTime anyways ?</div><div>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).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
f. We should check the following closely: "Figure 8.1 — Examples of time-dependent node execution".<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Likely a good topic for X3D Working Group discussion.<br>
<br>
<br>
On 12/19/2016 8:36 AM, Andreas Plesch wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks Roy,<br>
<br>
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.<br>
<br>
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:<br>
<br>
timeOffset = fraction_changed_whenStopped * cycleInterval<br>
startTime = now - timeOffset<br>
<br>
Setting startTime of an inactive sensor to a time in the past seems to be allowed.<br>
<br>
This looks like it would require scripting, and does make a built in pausing functionality more attractive.<br>
<br>
-Andreas<br>
<br>
On Mon, Dec 19, 2016 at 10:30 AM, Roy Walmsley <<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.com</a> <mailto:<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.<wbr>com</a>>> wrote:<br>
<br>
Hi Andreas and Leonard,____<br>
<br>
__ __<br>
<br>
This is an interesting topic to capture for subsequent discussion and resolution. Thank you Andreas for raising it. ____<br>
<br>
__ __<br>
<br>
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 <a href="http://web3d.org/pipermail/x3d-public_web3d.org/2016-December/005692.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x3d<wbr>-public_web3d.org/2016-Decembe<wbr>r/005692.html</a> <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/2016-December/005692.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x3<wbr>d-public_web3d.org/2016-Decemb<wbr>er/005692.html</a>>.____<br>
<br>
__ __<br>
<br>
Regards,____<br>
<br>
__ __<br>
<br>
Roy____<br>
<br>
__ __<br>
<br>
*From:*x3d-public [mailto:<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@web<wbr>3d.org</a> <mailto:<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@web<wbr>3d.org</a>>] *On Behalf Of *Andreas Plesch<br>
*Sent:* 17 December 2016 03:53<br>
*To:* Leonard Daly <<a href="mailto:Leonard.Daly@realism.com" target="_blank">Leonard.Daly@realism.com</a> <mailto:<a href="mailto:Leonard.Daly@realism.com" target="_blank">Leonard.Daly@realism.c<wbr>om</a>>><br>
*Cc:* X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>><br>
*Subject:* Re: [x3d-public] TimeSensor resumeTime field____<br>
<br>
__ __<br>
<br>
Leonard,____<br>
<br>
On Dec 16, 2016 8:52 PM, "Leonard Daly" <<a href="mailto:Leonard.Daly@realism.com" target="_blank">Leonard.Daly@realism.com</a> <mailto:<a href="mailto:Leonard.Daly@realism.com" target="_blank">Leonard.Daly@realism.c<wbr>om</a>>> wrote:<br>
><br>
> [Note: I am OK with this being posted to x3d-public. I did not do so because it is originally Andreas' comment.]<br>
><br>
> 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.____<br>
<br>
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____<br>
<br>
fraction_changed = elapsedTime mod cycleInterval / cycleInterval____<br>
<br>
work to define fraction_changed ?____<br>
<br>
I did not test other x3d browsers resumeTime behavior. Is there a conformance test scene ?____<br>
<br>
> 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).____<br>
<br>
Ok, let's take the opportunity to review the time component. ____<br>
<br>
> What would it take to eliminate the system time from TimeSensor?____<br>
<br>
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 ?____<br>
<br>
> 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).____<br>
<br>
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.____<br>
<br>
> 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.____<br>
<br>
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?).____<br>
<br>
Andreas<br>
><br>
> Leonard Daly<br>
><br>
><br>
><br>
>> A time sensor has a concept of pausing time:<br>
>><br>
>> <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#PausingTime" rel="noreferrer" target="_blank">http://www.web3d.org/documents<wbr>/specifications/19775-1/V3.3/<wbr>Part01/components/time.html#Pa<wbr>usingTime</a> <<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#PausingTime" rel="noreferrer" target="_blank">http://www.web3d.org/document<wbr>s/specifications/19775-1/V3.3/<wbr>Part01/components/time.html#Pa<wbr>usingTime</a>><br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> "The time-dependent node then resumes generating its output events from the paused state at the simulation tick." is the spec. language.<br>
>><br>
>> 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 ?<br>
>><br>
>> 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.<br>
>><br>
>> -Andreas<br>
</blockquote>
<br>
all the best, Don<span class="gmail-HOEnZb"><font color="#888888"><br>
-- <br>
Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA <a href="tel:%2B1.831.656.2149" value="+18316562149" target="_blank">+1.831.656.2149</a><br>
X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzma<wbr>n</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>