[x3d-public] FloatSequencer ? step functions and optimization, avoiding node bloat

Mon Oct 9 20:02:46 PDT 2017

Good points but consider:

Interpolators with step functions act almost like sequencers but do not
have the 'next' and 'previous' fields. These fields could be added,
however. 'next' would proceed to next keyValue interval, either to the
lower limit or to the equivalent interpolated value within that interval.
With these fields, I agree, there would be no need for more sequencers.

All event utility nodes (and many others) can be implemented as protos, so
there have to be other criteria. A ScalarSequencer is so useful that it
should be considered a candidate for a standard node because it provides
sequencer access to most other field types for very little implementation
and specification cost.

Atypical user interaction may require the flexibility of scripts but once
scripts are used for logic in a scene it is likely that it becomes
preferable to handle all logic in the scripts, eg. avoid the event
utilities.

Andreas

-- I noticed the x3dom TouchSensor requiring mouse movement between clicks
as well. Should be fixable.

On Oct 9, 2017 8:10 PM, "Don Brutzman" <brutzman at nps.edu> wrote:

On 10/6/2017 12:17 PM, Andreas Plesch wrote:

> Here is the
>
> http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09-E
> ventUtilitiesScripting/ScriptComplexStateEventsIndex.html
>

Thanks for looking at this example again Andreas.

I noticed that the 4-state cycle script was keeping track of state value
[0,1,2,3] as part of inputOutput field buttonPushCount, and so added some
text labels under a Switch node to help illustrate it.  Pretty simple
addition.

        http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09Ev
entUtilitiesScripting/ScriptComplexStateEventsIndex.html

        http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09Ev
entUtilitiesScripting/ScriptComplexStateEventsX_ITE.html

Also have applied background color-coding to the pretty-print html
documentation to help highlight what the purpose of each node.  Redeploying
pretty-print updates tonight (with thanks to Sung Min Kwon for helpful
discussions on this topic).
- (Light blue background: behavior node)
- (Grey background: inserted documentation)
- (Magenta background: X3D Extensibility)

        http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09Ev
entUtilitiesScripting/ScriptComplexStateEvents.html

converted using a ScalarSequencer (naming following ScalarInterpolator):
>
> https://quirky-winter.glitch.me/
>

Trouble report: the push button requires an irregular number of clicks
before the light changes. (Windows 10 Firefox)

And here are the relevant changes to the scene
>
> https://glitch.com/edit/#!/quirky-winter?path=index.html:75:7
>
> Replacing the script and its custom field declarations, there is now only
> one Sequencer node, one ColorInterpolator and one additional route, three
> lines.
>
> This pattern would be the main intended usage, eg. using sequencer
> fraction output to get interpolator typed output for use in the scene
> (colors, orientations, positions ..).
>
> How does that look ?
>
> -Andreas
>

Well the result is certainly simpler, which is good.  To be fair about such
a comparison though, it is good to realize that this example is intended to
illustrate such simple Script design for atypical user interaction.
Whatever works.

This case also illustrates the potential usefulness of prototypes,
certainly ScalarSequencer can be implemented in that fashion.

For the general case of sequencing Float Vec2f Vec3f Vec4f, we considered
adding such node(s) to the X3D specification.  However we decided against
that because the same effect is possible when putting adjacent values
together in the keyValue array, effectively creating step functions.  We
left it up to the X3D player to be able to avoid sending unchanging
intermediate values during a step, avoiding excess events.

Probably further prose about step functions is needed, this relates to
recent discussion about the piecewise-linear interpolating function f(t).

        19.2.2 Linear interpolation
        http://www.web3d.org/documents/specifications/19775-1/V3.3/
Part01/components/interp.html#ScalarInterpolator
and
        19.3.1 X3DInterpolatorNode
        http://www.web3d.org/documents/specifications/19775-1/V3.3/
Part01/components/interp.html#X3DInterpolatorNode

Perhaps we should add something to spec like:

        NOTE
        Identical adjacent entries in the keyValue array have the effect of
defining constant-value step functions.

Added a tooltip to the floating-point interpolators about step functions.
Further information on that term is available on Wikipedia.

        http://www.web3d.org/x3d/content/X3dTooltips.html#ScalarInterpolator

        https://en.wikipedia.org/wiki/Step_function

Such optimization of unchanging events might be good to consider further.
Perhaps add prose to 19.2.2 such as

"X3D players are not required to send unchanging intermediate values,
providing a performance enhancement by avoiding the passing excessive
superfluous events that have no effect."

Similarly added a tooltip hint about that issue to interpolator node
value_changed entries.

        http://www.web3d.org/x3d/tooltips/X3dTooltips.html#ColorInterpolator

If we add those clarifications to specification, then perhaps (as
originally expected) there is no need to add floating-point sequencers to
the specification.  Given eight floating point interpolator nodes that
possess such capabilities already in the specification, it is preferable to
keep the node vocabulary as terse and concise as possible.

The eight nodes in 19.2.2 are
ColorInterpolator
CoordinateInterpolator
CoordinateInterpolator2D
NormalInterpolator
OrientationInterpolator
PositionInterpolator
PositionInterpolator2D
ScalarInterpolator

We need to similarly handle the other X3DInterpolatorNode:

        25.3.7 GeoPositionInterpolator
        http://www.web3d.org/documents/specifications/19775-1/V3.3/
Part01/components/geodata.html#GeoPositionInterpolator

Thanks for considering these issues.  Anything that we do to support and
enhance author animation abilities is worthwhile and certainly holds broad
value.

p.s. of related interest: can build sequencers for nodes as well.  Examples:

        http://x3dgraphics.com/examples/X3dForAdvancedModeling/Anima
tion/ViewpointSequencerPrototypeIndex.html

        http://x3dgraphics.com/examples/X3dForAdvancedModeling/Anima
tion/CubeWithLabeledSidesViewpointSequencerIndex.html

        http://www.web3d.org/x3d/content/examples//Basic/Geospatial/
CaliforniaCampusesIndex.html

On Sun, Sep 17, 2017 at 11:25 PM, Andreas Plesch <andreasplesch at gmail.com
> <mailto:andreasplesch at gmail.com>> wrote:
>
>     I am thinking about how to convert this example of a 4 state button
> from
>     scripting to event utilities:
>
>     http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09-E
> ventUtilitiesScripting/ScriptComplexStateEventsIndex.html
>     <http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09-
> EventUtilitiesScripting/ScriptComplexStateEventsIndex.html>
>
>     Using a Switch driven by an IntegerSequencer driven by the TouchSensor
> using
>     the next field would work but requires 4 full Shape nodes.
>
>     If there were a FloatSequencer, it would be possible to use it to
> provide
>     fractions to a ColorInterpolator to be fed into the bulb material. This
>     would be closer to the script and overall a more direct, and perhaps
> elegant
>     solution.
>
>     In general, with a FloatSequencer it would be possible to use all the
>     Interpolators as typed output, in effect converting from boolean.
>
>     Since such a FloatSequencer is very straightforward to implement (in
> x3dom
>     almost identical to IntegerSequencer) I will try this but wonder if
> such a
>     node had been proposed in the past?
>
>     I suspect that it would be almost trivial to add such a node to any
> browser
>     and suggest that it would enhance the utility of the event utilities
>     substantially, pun notwithstanding.
>
>     Any feedback or comment very welcome,
>
>     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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20171009/35e97a95/attachment-0001.html>