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

[Don Brutzman]

Global time "source" is certainly an interesting idea to think through.  Issues:

- there is already clock time shared,
- one scene's global is another scene's Inline,
- good examples become good practices become design patterns.

suggest we keep it in mind, work through current issues, then see if there is anything an improved example set is unable to do well.

also good reminder that we indeed need to keep SAI up to date as well.

On 12/19/2016 12:56 PM, Andreas Plesch wrote:
>
>
> On Mon, Dec 19, 2016 at 12:14 PM, Yves Piguet <yves.piguet at gmail.com <mailto:yves.piguet at gmail.com>> wrote:
>
>     A global pause is more practical for pausing the whole scene, because otherwise you have to route a pause event to all time-related nodes (TimeSensor, other nodes enumerated in 19775 8.2.4.1 http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#TimeDependentNodesOverview <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#TimeDependentNodesOverview> and nodes related to physics models)
>
>
> In many cases it may be possible to use a single time source ? Lots of routes are not uncommon in scenes.
> Dick Tracy style, global time pausing may require another mechanism, presumably a field in a global node (WorldInfo??). Sensed time then could be relative to an initial scene time as a time origin. Pausing then may mean that the time origin keeps advancing (at the same rate as the simulation time) so that the sensed time appears to stay constant. Resuming may mean that the time origin becomes fixed again (at the current time).
> Hm, this could be probably done in a backwards compatible way, since the current situation is simply a fixed time origin of 0. This may work but would produce apparent pausing and no power savings. Apparent pausing would be a better fit to the fact time actually does not pause.
>
>     Pausing correctly is important especially on mobile devices where the user wants to reduce power consumption without quitting the browser.
>
>
> On web browsers this is solved by requestAnimationFrame which lets the web browser control when to stop running code, for example when a user switches to another tab. Pausing is great for standalone x3d browsers but they may have their own, external to x3d, mechanisms.
>
>
>     I haven't found pause/resume methods in 19775-2  (SAI). I'd suggest to add this functionality there.
>
>
> One would just set fields, no ?
>
>
>     Yves
>
>     > On 19 Dec 2016, at 17:36, Andreas Plesch <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>> 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


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