[x3d-public] ScalarSequencer proto repo

[Andreas Plesch]

Since the ScalarSequencer proto works rather satisfactorily, I created
a dedicated repository here:

https://github.com/andreasplesch/ScalarSequencer

The proto is available here for viewing:

https://github.com/andreasplesch/ScalarSequencer/blob/master/Prototype/ScalarSequencerPrototype.x3d

and here for use as extern proto url:

https://raw.githubusercontent.com/andreasplesch/ScalarSequencer/master/Prototype/ScalarSequencerPrototype.x3d

Here is the push button example using the extern proto:

https://raw.githubusercontent.com/andreasplesch/ScalarSequencer/master/Examples/PushButton.x3d

It is a little expanded to show how a ScalarSequencer can be used to
step through other data types via an interpolator.

Finally, here is x_ite displaying the scene:

https://rawgit.com/andreasplesch/ScalarSequencer/master/Examples/pushbutton.html

Interestingly, it turns out that x_ite treated the extern proto a bit
differently than an internal proto. It called the set_fraction
function of the extern proto with an argument of 0 during
initialization or some early setup, perhaps because the extern proto
cannot define default field values.

Relatedly, for event utility sequencers, what should be the first key
and keyValue produced by the first next input event if there was no
previous set_fraction event (as a reference for next) ? Presumably the
first one in the key and keyValue arrays ?

Any feedback always welcome,

-Andreas


On Sat, Nov 4, 2017 at 9:13 AM, Andreas Plesch <andreasplesch at gmail.com> wrote:
> I developed a first ScalarSequence proto here:
>
> https://glitch.com/edit/#!/ripe-taxi?path=index.html:65:12
> https://ripe-taxi.glitch.me/
>
> and it works with x_ite. I will test it in other browsers as well.
>
> Looking through the examples, I see that persisting state is mostly
> managed by initializeOnly fields.
>
> Interestingly, the BooleanSequencerPrototype example
>
> http://www.web3d.org/x3d/content/examples/Basic/development/BooleanSequencerPrototypeIndex.html
>
> declares local variables outside of the functions:
>
> var key, keyValue;
>
> But this is rarely done, and I am not sure if this is covered by the spec.
>
> I also noticed that fields of accessType inputOutput are often
> substituted by the corresponding inputOnly/outputOnly fields.
> In theory, inputOutput type in a script should enable set_ and
> _changed events, so I am not sure why this splitting is necessary.
>
> For example, is it sufficient for an inputOutput key field to write
>
> function set_key(val) { key = val; }
>
> to achieve both assigning the new value to the field, and also
> outputting of a key_changed event ?
>
> I think in x_ite it is sufficient but I will need to test.
>
> -Andreas
>
> On Sat, Nov 4, 2017 at 12:39 AM, Andreas Plesch <andreasplesch at gmail.com> wrote:
>> Working on a ScalarSequencer proto ,I developed the script which
>> provides the functionality:
>>
>> https://ripe-taxi.glitch.me/
>>
>> It seems to work ok using x_ite. In order to maintain internal,
>> persisting state, the script uses an initializeOnly field:
>>
>> https://glitch.com/edit/#!/ripe-taxi?path=index.html:161:21
>>
>> Perhaps this is the intended use of such a field but I was wondering
>> if there are other standard ways to have such internal state storage.
>> For example, it may be convenient to use a javascript object for state
>> which could not be a field value.
>>
>> It is possible to just use a global variable, initialized in the
>> initialize() function. However, in an environment such as web page
>> this would intrude other script sharing the global context. One could
>> use a namespace then, say script1.globalA
>>
>> With x_ite it is possible declare a scoped variable in the script but
>> outside the functions which then persists and is in the scope of all
>> script functions but out of scope anywhere outside the script. A good
>> solution but likely this is not guaranteed to work in other browsers
>> since the spec. does not cover code execution outside the script
>> functions.
>>
>> Perhaps the namespaced global variable would be the most standard way
>> but it would be great if global variables could be avoided.
>>
>> -Andreas
>>
>> --
>> Andreas Plesch
>> Waltham, MA 02453
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453