[x3d-public] TimeSensor resumeTime field
Andreas Plesch
andreasplesch at gmail.com
Fri Dec 16 19:52:43 PST 2016
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/listinfo/x3d-public_web3d.org
>
>
>
> --
> Leonard Daly
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - Creating the Future
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161216/50b49c77/attachment.html>
More information about the x3d-public
mailing list