[x3d-public] Sequencer interval definition

Andreas Plesch andreasplesch at gmail.com
Thu Oct 5 07:24:02 PDT 2017


Here is a comprehensive test scene which goes through all key intervals of
an IntegerSequencer:

http://x3dom-sequencer-interval-test.glitch.me/IntegerKeyTest.x3d

I tested freeWrl, view3dscene, InstantPlayer, x-ite, Octaga, and BS Contact.

Most players show this result:

key < 0: value is 0
key = 0: value is 0
key = 0.25: value is 0
key = 0.5: value is 1
key = 1: value is 2
key > 1: value is 2

for sequence keys=0,0.5,1 and keyValues=0,1,2

This is consistent with left-closed intervals and my slightly revised
function definition:

f(t)   =  v_i, if t_{i} <= t < t_{i+1}  for  0 <= i < n-1
        = v_0, if t < t_0,
        = v_{n-1}, if t >= t_{n-1}

If there is no further comment, I may submit a spec. comment summarizing
and referencing this email thread.

view3dscene shows
key = 0.5: value is 0

So view3dscene may use right-closed intervals ? Submitted as github issue:
https://github.com/castle-engine/view3dscene/issues/2

and InstantPlayer shows
key < 0:
key = 0:

eg, no values for these two keys. This is the default switch choice so
somehow the switches never get routed choices in these cases with
InstantPlayer.

Given these results I will adjust the x3dom sequencers to follow the
behavior of most browsers, as done here:

http://x3dom-sequencer-interval-test.glitch.me/IntegerKeyTest.html

Andreas


On Oct 3, 2017 7:21 PM, "Andreas Plesch" <andreasplesch at gmail.com> wrote:



On Tue, Oct 3, 2017 at 12:51 PM, Andreas Plesch <andreasplesch at gmail.com>
wrote:

> continued ...
> On Tue, Oct 3, 2017 at 9:21 AM, Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> On Oct 2, 2017 2:26 PM, "Andreas Plesch" <andreasplesch at gmail.com> wrote:
>>
>> Ok, here is a non-interactive test for correct half-closedness of
>> sequencer intervals:
>>
>> http://x3dom-sequencer-interval-test.glitch.me/SequencerInterval_test.x3d
>>
>> In x3dom:
>>
>> https://x3dom-sequencer-interval-test.glitch.me/
>>
>> With the updated, correct X3DSequencer implementation for x3dom (
>> https://github.com/andreasplesch/x3dom/blob/IntegerSequence
>> r/src/nodes/EventUtilities/X3DSequencerNode.js) the cone is illuminated
>> in red.
>>
>> With the incorrect, earlier implementation for x3dom (
>> https://glitch.com/edit/#!/x3dom-sequencer-interval-test?pa
>> th=X3DSequencerNode.js:106:41) the cone stays grey.
>>
>> Testing x-ite it appears that x-ite interpreted intervals to be open on
>> the left and closed on the right (not the intended interpretation): the
>> cone stayed grey.
>>
>> Getting to other browser hopefully later when I have access to Windows.
>>
>>
>> I tested Octaga, BS Contact, view3dscene and InstantPlayer. All fail the
>> test, eg. the cone stays grey.
>>
>> Investigating, I changed the test by modifying the keyValues of the
>> BooleanSequencer to turn on the light when the key (0.2) is part of the
>> interval 0 to 0.2, or whatever the second interval is:
>>
>> <BooleanSequencer DEF='OnOffSequencer' key='0 0.2 0.4 1' keyValue='false
>> true false false' ></BooleanSequencer>
>>
>> http://x3dom-sequencer-interval-test.glitch.me/SequencerInte
>> rval_test_rightclosed.x3d
>>
>> This is the only change.
>>
>> For this test, Octaga, BS Contact and x-ite show a red cone.
>> InstantPlayer and view3dscene still show a grey cone, indicating perhaps
>> other issues with the scene (perhaps the routing order).
>>
>> One explanation is that the players consider the intervals to be closed
>> on the right, upper limit.
>>
>> Another explanation may be that the players consider t<0 to be part of
>> the first interval - 0 to 0.2 - . Then they would consider - 0.2 to 0.4 -
>> the second interval, thereby turning on the light. This is less likely
>> because the first interval is clearly specified as (−infinity, t0). This
>> can be tested as well by routing 0.1 to the sequencer. This should select
>> the second keyValue turning on the light.
>>
>> I will try this.
>>
>>
> http://x3dom-sequencer-interval-test.glitch.me/SequencerInte
> rval_test_inFirst.x3d
>
> is a test if the first (v0) or second keyValue (v1) is selected if the key
> falls into the interval [t0, t1)
>
> Octaga, InstantPlayer and x-ite all select v0 , unfortunately. I will also
> test BSContact but expect it to also select v0.
>

BSContact as well as view3dscene do select v0 (true) if the key (0.1) falls
into the interval [t0,t1) ( [0, 0.2) ).
So all tested players behave the same.


> I believe this is inconsistent with Vince's proposal for a corrected
> function as the proposal reserves v0 for the interval t<t0 .
>
> This behaviour is not inconsistent with the current spec. because the
> current spec. provides a function definition which must be incorrect and is
> therefore open to interpretation.
>
> For the sake of practical backward compatibility, therefore Vince's
> function definition may be altered to:
>
> f(t)   =  v_i, if t_{i} <= t < t_{i+1}  for  0 <= i < n-1
>         = v_0, if t < t_0,
>         = v_{n-1}, if t >= t_{n-1}
>
> It would be still possible to define a reserved value for the interval
> t<t0 by repeating the first key: key="0 0 1"
>
> How does that look ?
>
> -Andreas
>
>
>
>> -Andreas
>>
>>
>>
>>
>> On Sun, Oct 1, 2017 at 11:33 PM, Andreas Plesch <andreasplesch at gmail.com>
>> wrote:
>>
>>> Hi Vince,
>>>
>>> wolfram is good enough for me. Let me check at least my sequencer x3dom
>>> code, and perhaps come up with a simple test.
>>>
>>> -Andreas
>>>
>>>
>>>
>>> On Sun, Oct 1, 2017 at 9:42 PM, vmarchetti at kshell.com <
>>> vmarchetti at kshell.com> wrote:
>>>
>>>> For more on the [a,b) denoting an interval a <= x < b, see
>>>> http://mathworld.wolfram.com/Half-ClosedInterval.html
>>>>
>>>> However, I agree that for the practcal problem of clarifying the spec
>>>> language, we should know how existing browsers have interpreted the
>>>> currrent language.
>>>>
>>>> Vince Marchetti
>>>>
>>>> > On Sep 30, 2017, at 11:47 PM, Andreas Plesch <andreasplesch at gmail.com>
>>>> wrote:
>>>> >
>>>> >
>>>> >
>>>> > On Sep 30, 2017 7:49 PM, "vmarchetti at kshell.com" <
>>>> vmarchetti at kshell.com> wrote:
>>>> >
>>>> > > On Sep 4, 2017, at 11:45 AM, Andreas Plesch <
>>>> andreasplesch at gmail.com> wrote:
>>>> > >
>>>> > > Resending this without html formatting to ensure proper
>>>> transmission:
>>>> > >
>>>> > > 30.2.4 defines how sequencer values are assigned to key intervals:
>>>> > >
>>>> > > http://www.web3d.org/documents/specifications/19775-1/V3.3/P
>>>> art01/components/utils.html#SequencingEvents
>>>> > >
>>>> > > (−infinity, t0), [t0, t1), [t1, t2), ... , [tn-1, +infinity)
>>>> > >
>>>> > > are the intervals.
>>>> > >
>>>> > > The square bracket [ seems to indicate that the limiting value does
>>>> not belong to the interval. Is that the case ?
>>>> >
>>>> > I'm more used to the square bracket indicating a closed boundary, so
>>>> that the for the interval denoted [a,b) ; x is in the interval a <= x < b
>>>> > so a is an element of the interval but b is not. Take the view that
>>>> neither +infinity nor -infinity is a number; so (-infinity,a) is just
>>>> shorthand for the set x < a, while [a,+infinity) is x >= a.
>>>> >
>>>> > VRML97 seems to be when the bracket for the interval was introduced:
>>>> >
>>>> > http://tecfa.unige.ch/guides/vrml/vrml97/spec/part1/concepts
>>>> .html#4.6.8
>>>> >
>>>> > But it is not accompanied by an explanation. For interpolators it may
>>>> not matter if the limit is included in the interval since the function is
>>>> continuous.
>>>> >
>>>> > For sequencers, the function produces different values depending on
>>>> from which side an interval limit is approached.
>>>> >
>>>> > I guess it is time to look up how various browsers behave at
>>>> sequencer interval limits.
>>>> >
>>>> >
>>>> >
>>>> > >
>>>> > > For example, in the second interval [t0, t1) t0 does not belong to
>>>> the interval but t1 does.
>>>> > > I have seen other notations where this interval would be described
>>>> as ]t0, t1] which I would offer as a suggestion for an improvement.
>>>> > >
>>>> > > The next question is about the piecewise function definition:
>>>> > >
>>>> > > f(t) = v_n, if t_n <= t < t_(n-1)
>>>> > >
>>>> > > Given that the keys t_i are given in a monotonically non-decreasing
>>>> order, t_n is always larger (or equal to) than t_(n-1). Therefore, a t
>>>> larger than t_n can never be smaller than t_(n-1). But this is the
>>>> condition described in the function for value v_n. There is no possible t
>>>> which can fulfill this condition.
>>>> > > Presumably this condition was designed as:
>>>> > >
>>>> > > f(t) = v_n, if t_n >= t > t_(n-1)
>>>> > >
>>>> > > If this is the case I can submit a spec. comment but I very much
>>>> would appreciate additional eyes on that since it seems like a rather
>>>> fundamental oversight. Did I overlook something ?
>>>> > >
>>>> >
>>>> > My set of eyes agrees with yours that the formula form in the v 3.3
>>>> version of section 30.2.4 is incorrect, I would propose a corrected version:
>>>> >
>>>> > f(t)    =  v_i, if t_{i-1}   ≤ t < t_{i}  for  1 <= i < n-1
>>>> >         = v_0, if t < t_0,
>>>> >         = v_{n−1}, if t ≥ t_{n−1}
>>>> >
>>>> >
>>>> > Looks good to me if [ is meant to include the limit in the interval.
>>>> >
>>>> > Andreas
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > > The Interpolator component spec. may provide additional insight:
>>>> > >
>>>> > > http://www.web3d.org/documents/specifications/19775-1/V3.3/P
>>>> art01/components/interp.html#Linearinterpolation
>>>> > >
>>>> > > Here the equivalent piecewise function definition is:
>>>> > >
>>>> > > f(t) = linterp(t, v_i, v_(i+1)),    if t_i <= t <= t_(i+1),
>>>> > >
>>>> > > Note that the interval condition here is between t_i and t_(i+1)
>>>> and not t_(i-1). So this is correct. But why change for Sequencer to
>>>> t_(n-1) ? Perhaps there is a reason ?
>>>> > >
>>>> > > Also note that i is used rather than n which is also more correct
>>>> since n is reserved for the fixed, total number of keys, whereas i is the
>>>> variable index depending on the whatever time t is considered.
>>>> > >
>>>> > > -Andreas
>>>> > >
>>>> > > --
>>>> > > Andreas Plesch
>>>> > > Waltham, MA 02453
>>>> > > _______________________________________________
>>>> > > x3d-public mailing list
>>>> > > x3d-public at web3d.org
>>>> > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>> >
>>>> >
>>>>
>>>>
>>>
>>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>



-- 
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20171005/9136a78e/attachment-0001.html>


More information about the x3d-public mailing list