[x3d-public] dynamic cycleInterval changes

Mon Nov 21 12:37:50 PST 2016

On Mon, Nov 21, 2016 at 10:53 AM, Don Brutzman <brutzman at nps.edu> wrote:

> Good point Patrick.  Thanks for your example too Holger.
>
> Perhaps even trickier is that events within a single event cascade are not
> guaranteed to be ordered.  This slight relaxation on Script semantics was
> necessary when we reconciled internal scripting with external EAI to
> produce the combined SAI.  Avoiding reliance on event ordering is also
> necessary if events are being produced by parallel processes.  They might
> all be available at the beginning of an event cascade, but such arrival
> ordering can't be guaranteed.
>
> Avoiding repetition of two values, please consider these variations on
> Holger's approach:
>
> # http://stackoverflow.com/questions/3830244/get-current-date-
> time-in-seconds
> timestamp = new Date().getTime() / 1000;
> timestamp = Date.now() / 1000; // apparently equivalent
>
>
There is also Performance.now() :
https://developer.mozilla.org/en-US/docs/Web/API/Performance/now

# stop then _start_
> timeSensor.stopTime = timestamp;
> timeSensor.cycleInterval = newValue;
> timeSensor.startTime = timestamp;
>

Ok, this is Holger's suggestion.

> timeSensor.enabled=false;
> timeSensor.cycleInterval = newValue;
> timeSensor.startTime = timestamp;
>
>
set_startTime = timeStamp will activate. ok.

> # reshuffled order of same events means (perhaps-ignored re)start then
> _stop_
>
> timeSensor.cycleInterval = newValue; // ignored if running
> timeSensor.startTime = timestamp;    // ignored if running
> timeSensor.stopTime = timestamp;
>
>
ok, since ordering is not guaranteed above approaches may not work.

> timeSensor.cycleInterval = newValue; // ignored if running
> timeSensor.startTime = timestamp;    // ignored if running
> timeSensor.enabled=false;
>
> Ouch.  Is the TimeSensor starting or stopping?  Coin flip.  No way to be
> consistent in one pass when event order isn't guaranteed.
>
> Workaround: one way for an author to avoid nondeterminism is to perform
> one step before the other.  Two-phase commit.
> a. first a script stop a TimeSensor (using either .enabled or .stopTime
> events),
> b. await confirmation that TimeSensor has stopped (by receiving either
> isActive=false or stopTime/elapsedTime event),
> c. then (meaning then in follow-on event-cascade loop) use that event as a
> trigger to change the cycleInterval and restart.
>

I started to try to do that using multiple scripts and routes but got
confused.

> This workaround either takes a custom Script or perhaps a carefully
> crafted combination of event-utility nodes, along with corresponding ROUTE
> connections. It can be done, but is fairly detailed/onerous and certainly
> error prone.  Of course erroneous response is also maddening - user
> frantically clicking "why won't it STOP??!"
>

Exactly what happened to me. I actually managed to freeze firefox a few
times (perhaps indicating that the loop breaking rule is not sufficient, or
not sufficiently implemented in cobweb). It may still be instructive to
come up with the actual solution using this approach but I had to give up.

> Back to X3D design, must wonder: why don't we just allow modifying
> cycleInterval while a TimeSensor cycle is active?  Avoids nondeterminism
> and programming overhead of two-phase commit.  Perhaps TimeSensor
> implementers could weigh in here...
>

I agree. Hopefully there is a simple solution like this.

In cobweb_dom I resolved to call a Browser.processEvents() cobweb method
explicitly after each triggered input event which I think completes the
cascade for this single event. It does not necessarily render a frame.
Doing this probably reduces performance a bit but makes code sequence such
as above possible which is what most would expect.

Are external SAI events delivered between .beginUpdate() and .endUpdate()
guaranteed to maintain their sequencing once the browser starts to process
them ?

-Andreas

> On 11/21/2016 6:48 AM, Patrick Dähne wrote:
>
>> Hello Andreas,
>>
>> Setting the cycleInterval does not work because your example javascript
>> code does not comply with X3D. Have a look at the following lines:
>>
>> time.enabled = false;
>> time.cycleInterval = 5;
>> time.enabled = true;
>>
>> And now have a look at the spec (X3D Language Bindings : ECMAScript
>> (JavaScript), 4.3.5.2.2 Accessing fields and readable fields of other
>> nodes):
>>
>> … Events generated by setting an input-capable field on a node are sent
>> at the completion of the initial function call made to the user code by the
>> browser. … Assigning to the inputOnly field multiple times during one
>> execution of the function still only sends one event and that event shall
>> be the last value assigned.
>>
>> So in X3D conformant browsers, the lines above send only two events:
>>
>> 1. time.enabled = true
>> 2. time.cycleInterval = 5
>>
>> The first assignment to time.enabled gets overwritten by the second
>> assignment, so the timer never gets disabled.
>>
>> Bye,
>>
>> Patrick
>>
>>
>>
>> Am 20.11.2016 um 21:36 schrieb Andreas Plesch <andreasplesch at gmail.com>:
>>>
>>> I want to change the cycleTime of a TimeSensor in a x3d script:
>>>
>>> https://raw.githubusercontent.com/andreasplesch/cobweb_dom/m
>>> aster/tests/dynamicCycleTime.x3d
>>>
>>> cycleTime input events are ignored when the TimeSensor is enabled. So it
>>> is necessary to disable it first, then change the cycleTime and then
>>> reenable it.
>>>
>>> However, in all tested browser the above does not work as expected.
>>> These are cobweb, instant player and bs contact. bs contact also has this
>>> console message:
>>> Script node speeder: parse error: line 16 "time.cycleInterval = 2;" ()
>>> and therefore does not get to change the color to grey.
>>> The javascript sai does not have a SFTime constructor and allows numbers.
>>>
>>> cobweb and instant player change the color but do not slow down the ball.
>>> I first thought that cobweb does not correctly work through the sequence
>>> of events but since no browser works sofar I start to think that I am
>>> missing something.
>>>
>>> Any help or feedback appreciated,
>>>
>>> -Andreas
>>>
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>>
>
> 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/brutzma
> n
>

-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161121/004ee23f/attachment-0001.html>