<p dir="ltr">Leonard,</p>
<p dir="ltr">On Dec 16, 2016 8:52 PM, "Leonard Daly" <<a href="mailto:Leonard.Daly@realism.com">Leonard.Daly@realism.com</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.</p>
<p dir="ltr">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</p>
<p dir="ltr">fraction_changed = elapsedTime mod cycleInterval / cycleInterval</p>
<p dir="ltr">work to define fraction_changed ?</p>
<p dir="ltr">I did not test other x3d browsers resumeTime behavior. Is there a conformance test scene ?</p>
<p dir="ltr">> 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).</p>
<p dir="ltr">Ok, let's take the opportunity to review the time component. </p>
<p dir="ltr">> What would it take to eliminate the system time from TimeSensor?</p>
<p dir="ltr">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 ?</p>
<p dir="ltr">> 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).</p>
<p dir="ltr">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.</p>
<p dir="ltr">> 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.</p>
<p dir="ltr">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?).</p>
<p dir="ltr">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">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#PausingTime</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>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> -- <br>
>> Andreas Plesch<br>
>> 39 Barbara Rd.<br>
>> Waltham, MA 02453<br>
>><br>
>><br>
>> _______________________________________________ x3d-public mailing list <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a> <br>
><br>
><br>
><br>
> -- <br>
> Leonard Daly<br>
> 3D Systems & Cloud Consultant<br>
> LA ACM SIGGRAPH Chair<br>
> President, Daly Realism - Creating the Future<br>
</p>