<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 19, 2016 at 12:14 PM, Yves Piguet <span dir="ltr"><<a href="mailto:yves.piguet@gmail.com" target="_blank">yves.piguet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/time.html#TimeDependentNodesOverview" rel="noreferrer" target="_blank">http://www.web3d.org/<wbr>documents/specifications/<wbr>19775-1/V3.3/Part01/<wbr>components/time.html#<wbr>TimeDependentNodesOverview</a> and nodes related to physics models)<br></blockquote><div><br></div><div>In many cases it may be possible to use a single time source ? Lots of routes are not uncommon in scenes.</div><div>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).</div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Pausing correctly is important especially on mobile devices where the user wants to reduce power consumption without quitting the browser.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I haven't found pause/resume methods in 19775-2  (SAI). I'd suggest to add this functionality there.<br></blockquote><div><br></div><div>One would just set fields, no ?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yves<br>
<br>
> On 19 Dec 2016, at 17:36, Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br>
><br>
> 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>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>