[x3d-public] IntegerTrigger [was: BooleanToggle output]

Andreas Plesch andreasplesch at gmail.com
Sun Sep 24 08:14:28 PDT 2017


Hi Don,

On Sun, Sep 24, 2017 at 2:57 AM, Don Brutzman <brutzman at nps.edu> wrote:

> Thanks for perseverance.  Important.
>
> On 9/23/2017 2:11 PM, Andreas Plesch wrote:
>
>> Just looking at IntegerTrigger http://www.web3d.org/x3d/conte
>> nt/X3dTooltips.html#IntegerTrigger <http://www.web3d.org/x3d/cont
>> ent/X3dTooltips.html#IntegerTrigger>
>> , I see in the tool tips this description:
>>
>> *"IntegerTrigger converts boolean true or time input events to an integer
>> value"*
>>
>> 1) IntegerTrigger does not accept time input events:
>>
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/components/utils.html#IntegerTrigger
>>
>> So why mention time input events ?
>>
>
> That was fixed previously, perhaps your browser needed a refresh?  Current
> prose:
>
>         "IntegerTrigger converts set_boolean true input events to an
> integer value (for example, useful when animating whichChoice in a Switch
> node)."
>
>
Just needed a refresh here.


> 2) Boolean True
>>
>> It is correct that IntegerTrigger convert boolean true events. But is
>> also converts boolean false events.
>>
>> The last paragraph in 30.4.6 IntegerTrigger explicitly allows for that:
>>
>> "Upon receiving a set_boolean event .. The value of /set_boolean/ shall
>> be ignored."
>>
>> So I believe having set_boolean false also trigger output was a
>> deliberate design decision. After all one could always use BooleanFilter to
>> suppress boolean false event if desired.
>>
>
> Mantis 519 (pending resolution) asks that false values be ignored.
> ==================================================================
> http://www.web3d.org/member-only/mantis/view.php?id=519
>
> Comment:
> Should add sentences to each node that "The value of set_boolean shall
> only be honored if a TRUE value is received." This default supports simpler
> scene logic for most cases, matches original design intent, and avoids
> several TRUE/FALSE pathologies that are common to TouchSensor. Author logic
> that is strictly dependent on the receipt of FALSE values can be easily
> constructed using other event utility nodes.
> ==================================================================
>
> The boolean logic of event chains are much much simpler if only true
> events are honored, because filters can be avoided in many/most cases and
> the logic is much less error prone.
>
> A good way to demonstrate convoluted/confounded logic is to describe nodes
> and ROUTE connections making up an event chain in plain language.  Then
> repeat the sentence when events are false... the logic is really twisted.
>
> A simpler example: TouchSensor is commonly used, and sends both true
> events when isOver/isActive and then false events when not
> isOver/isActive.  If both true and false events are sent and honored, then
> every user interaction is self-cancelling.  Not good!  So treating true as
> a valid event and false as an ignorable event makes sense.
>
> I hope this makes sense and is agreeable.  I think it is our likely
> result, since simplicity and clarity are fundamentally important.
> Otherwise I can mark everything related in tooltips and diagram as pending
> resolution of issue 519.  As you prefer.
>
>
http://x3dom-integertrigger.glitch.me/IntegerTrigger_test.x3d has now a way
to test set_boolean false:
Clicking on the left cone starts a timer which switches left text off right
away and after 2 seconds. So one can click on the right cone to switch left
text back on and see if it is switched off after 2 seconds. It is, for all
browsers I tested.

Octaga, view3dscene and x_ite all trigger on set_boolean false.

Apart from avoiding backwards incompatible changes, there are other
arguments but overall I agree restricting triggering to 'True' input adds
simplicity and clarity. I do think such would need to be considered as a
backwards incompatible change.

I would probably prefer to avoid confusion between spec. language and tool
tip language, meaning marking the set_boolean true explanations in the tool
tips somehow.

In terms of an IntegerTrigger node for x3dom, there just needs to be a
decision. I lean towards being compatible with other browsers and a
straight interpretation of the current spec. language. There also could be
a IntegerTrueTrigger to enable use of the new behaviour.


...
>
>>
>>

> Looking into TimeTrigger next.
>>
>
> same as point (2), only honoring true events for simplicity and logical
> clarity.
>
>
Agreed in general. Likely browsers currently also honor false events but
will test.


> Feels like we got another step closer, thanks...
>
> Once we have all this distilled in Mantis issue capturing best-effort
> prose, it will hopefully be straightforward to confirm resolution.
>
>
I do not have a sense of how widely the event utilities are used, eg. what
the impact of such a resolution would be. I think it would be a positive
change but a change nonetheless recognizing that this is the behaviour as
it was originally intended.

-Andreas


> On Sat, Sep 23, 2017 at 2:00 PM, Don Brutzman <brutzman at nps.edu <mailto:
>> brutzman at nps.edu>> wrote:
>>
>>     Made some further improvements to tooltips.  Also added
>> toggle_changed outputOnly event description to BooleanToggle.
>>
>>     When directly changing inputOutput fields, had mistaken
>> identification of output event names in previous posts.  Two corrections:
>>
>>              BooleanToggle
>>              [toggle] Hint: directly resetting the toggle field generates
>> a corresponding toggle_changed output event.
>>     http://www.web3d.org/x3d/content/X3dTooltips.html#BooleanToggle <
>> http://www.web3d.org/x3d/content/X3dTooltips.html#BooleanToggle>
>>
>>              IntegerTrigger
>>              [integerKey] Hint: directly resetting the integerKey field
>> generates a corresponding triggerValue output event.
>>     http://www.web3d.org/x3d/content/X3dTooltips.html#IntegerTrigger <
>> http://www.web3d.org/x3d/content/X3dTooltips.html#IntegerTrigger>
>>
>>              TimeTrigger
>>     http://www.web3d.org/x3d/content/X3dTooltips.html#TimeTrigger <
>> http://www.web3d.org/x3d/content/X3dTooltips.html#TimeTrigger>
>>
>>     For all three of these (but not for BooleanFilter):
>>
>>              [set_boolean] Hint: input event set_boolean false has no
>> effect.
>>
>>     Changed status of prior Mantis issues 519, 520 to indicated current
>> and related.
>>     http://www.web3d.org/member-only/mantis/view.php?id=519 <
>> http://www.web3d.org/member-only/mantis/view.php?id=519>
>>
>>     Also updated diagram notes:
>>
>>              X3D Event-Utility Node Diagrams
>>     http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09-E
>> ventUtilitiesScripting/X3dEventUtilityNodeEventDiagrams.pdf <
>> http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09-
>> EventUtilitiesScripting/X3dEventUtilityNodeEventDiagrams.pdf>
>>
>>     Subject to specification-team review and resolution of Mantis issues,
>> it appears that these are pretty well set now... hope so.
>>
>>     Further scrutiny remains welcome!
>>
>>     p.s. Roy, these corrections also pertain to the pending new mantis
>> issues when they get added.  I can apply them later if you prefer.
>>
>>
>>     On 9/22/2017 5:58 PM, Don Brutzman wrote:
>>
>>         On 9/22/2017 3:20 PM, Andreas Plesch wrote:
>>
>>             I agree, IntegerTrigger would also require such a statement.
>>
>>
>>         Very good, tooltips updated.
>>
>>         http://www.web3d.org/x3d/content/X3dTooltips.html#BooleanToggle <
>> http://www.web3d.org/x3d/content/X3dTooltips.html#BooleanToggle>
>>         toggle: "Persistent state value that gets toggled or reset.
>> Resetting the toggle field generates a corresponding toggle field output
>> event."
>>
>>         http://www.web3d.org/x3d/content/X3dTooltips.html#IntegerTrigger
>> <http://www.web3d.org/x3d/content/X3dTooltips.html#IntegerTrigger>
>>         integerKey: "integerKey is value for output when triggered.
>> Resetting the integerKey field generates a corresponding integerKey field
>> output event."
>>
>>
>>             Since I have implemented IntegerTrigger now for x3dom, and
>> recognize its utility for choosing a switch option, it is less obvious to
>> me that resetting its value should always also lead to output of that value.
>>
>>             The more conservative approach would be to leave this
>> decision to the author. If a new value is provided to the IntegerTrigger
>> node, the same new value can also always be provided to another node.
>>
>>             But since players currently do forward these inputs as
>> outputs, there may be a event cascade requirement or similar.
>>
>>
>>         It is this last case that pertains.  See discussion regarding
>> 4.4.8.1 Events below for requirement.
>>
>>         Since it is required, it is helpful for us to list this in
>> specification and tooltips so that implementations and expectations are all
>> consistent for everyone.
>>
>>         Spec feedback submissions follow.  Again thanks.
>>
>>
>>             On Sep 20, 2017 10:20 AM, "Don Brutzman" <brutzman at nps.edu
>> <mailto:brutzman at nps.edu> <mailto:brutzman at nps.edu <mailto:
>> brutzman at nps.edu>>> wrote:
>>
>>                  This is an excellent improvement, we should submit a
>> spec change.
>>
>>                  Am thinking that similar wording should be provided for
>> IntegerTrigger integerKey field, e.g.
>>
>>                           "Resetting the /integerKey/ field generates a
>>                  corresponding /integerKey/ field output event."
>>
>>             http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/components/utils.html#IntegerTrigger <
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/components/utils.html#IntegerTrigger> <
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/components/utils.html#IntegerTrigger <
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/components/utils.html#IntegerTrigger>>
>>
>>                  ==============================================
>>                  30.4.6 IntegerTrigger
>>
>>                  IntegerTrigger : X3DTriggerNode {
>>                     SFBool  [in]     set_boolean
>>                     SFInt32 [in,out] integerKey   -1   (-∞,∞)
>>                     SFNode  [in,out] metadata     NULL [X3DMetadataObject]
>>                     SFInt32 [out]    triggerValue
>>                  }
>>
>>                  IntegerTrigger handles single field Boolean events to
>> set an integer value for the output event. This is useful for connecting
>> environmental events to the Switch node's whichChoice field.
>>
>>                  Upon receiving a set_boolean event, the IntegerTrigger
>> node will generate a triggerValue event with the current value of
>> integerKey. The value of set_boolean shall be ignored.
>>                  ==============================================
>>
>>
>>                  On 9/18/2017 10:39 AM, Andreas Plesch wrote:
>>
>>                      Sending output fields upon value changes is how the
>> browsers I tested behaved. Although to me the sentence in 4.4.8.1 which
>> addresses this behaviour and begins with "Nodes also define output fields
>> .." is more explanatory than defining and seems to be intended to leave the
>> exact behavior specification to node definitions. Here is suggested wording
>> to help clarify 30.4.3:
>>
>>                      The BooleanToggle can be reset to a specific state
>> by directly setting the value of the inputOutput /toggle/ field. Resetting
>> the /toggle/ field generates a corresponding /toggle/ field output event.
>>
>>                      There is probably a better and/or more concise
>> phrase to add.
>>
>>                      -Andreas
>>
>>                      On Mon, Sep 18, 2017 at 12:46 PM, Brutzman, Donald
>> (Don) (CIV) <brutzman at nps.edu <mailto:brutzman at nps.edu> <mailto:
>> brutzman at nps.edu <mailto:brutzman at nps.edu>> <mailto:brutzman at nps.edu
>> <mailto:brutzman at nps.edu> <mailto:brutzman at nps.edu <mailto:
>> brutzman at nps.edu>>>> wrote:
>>
>>                           Thank you Andreas.  Looks like you have
>> identified an ambiguity in the spec
>>                           that might benefit from clarification.
>>
>>                           Since the first paragraph specifically
>> identified output events, and the
>>                           second paragraph on "reset" did not, my
>> interpretation was that no event was
>>                           sent as part of a reset.  That informed the
>> tooltips and diagram notes.     However, checking event model rules:
>>             http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/concepts.html#Events <http://www.web3d.org/document
>> s/specifications/19775-1/V3.3/Part01/concepts.html#Events> <
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/concepts.html#Events <http://www.web3d.org/document
>> s/specifications/19775-1/V3.3/Part01/concepts.html#Events>>
>>                           <http://www.web3d.org/document
>> s/specifications/19775-1/V3.3/Part01/concepts.html#Events <
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/concepts.html#Events> <http://www.web3d.org/document
>> s/specifications/19775-1/V3.3/Part01/concepts.html#Events <
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/concepts.html#Events>>>
>>
>>
>>                                   4.4.8 Event model
>>
>>                                     4.4.8.1 Events
>>
>>                               /Events/ are the primary means of
>> generating behaviors in the X3D run-time
>>                               environment. Events are used throughout
>> X3D: driving time-based
>>                               animations; handling object picking;
>> detecting user movement and
>>                               collision; changing the scene graph
>> hierarchy. The run-time environment
>>                               manages the propagation of events through
>> the system according to a
>>                               well-defined set of rules.
>>
>>                               Nodes define input fields (/i.e./, fields
>> with inputOutput or inputOnly
>>                               access) that trigger behavior. When a given
>> event occurs, the node
>>                               receives notification and can potentially
>> change internal state and the
>>                               value of one or more of its fields. *Nodes
>> also define output fields
>>                               (/i.e./, fields with inputOutput or
>> outputOnly access) that are sent upon
>>                               signal state changes or other occurrences
>> within the node.* Events sent to
>>                               input fields and events sent by output
>> fields are referred to collectively
>>                               in ISO/IEC 19775 as /Events/.
>>
>>
>>                           The bolded sentence (beginning with "Nodes also
>> define output fields... that
>>                           are sent upon signal state changes" ...)
>> indicates that a corresponding
>>                           output event should be sent when the value is
>> changed.
>>
>>                           Subject to review, am happy to make the
>> tooltips and diagram notes more
>>                           explicit in this matter.  We should likely also
>> add words to spec to avoid
>>                           indirect ambiguity and explicitly add clarity.
>>
>>                           all the best, Don
>>
>>
>>
>>                           On Sep 16, 2017, at 4:20 PM, Andreas Plesch <
>> andreasplesch at gmail.com <mailto:andreasplesch at gmail.com> <mailto:
>> andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>>
>>                           <mailto:andreasplesch at gmail.com <mailto:
>> andreasplesch at gmail.com> <mailto:andreasplesch at gmail.com <mailto:
>> andreasplesch at gmail.com>>>> wrote:
>>
>>             http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/components/utils.html#BooleanToggle <http://www.web3d.org/document
>> s/specifications/19775-1/V3.3/Part01/components/utils.html#BooleanToggle>
>> <http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/components/utils.html#BooleanToggle <http://www.web3d.org/document
>> s/specifications/19775-1/V3.3/Part01/components/utils.html#BooleanToggle
>> >>
>>                               <http://www.web3d.org/document
>> s/specifications/19775-1/V3.3/Part01/components/utils.html#BooleanToggle
>> <http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/components/utils.html#BooleanToggle> <
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/components/utils.html#BooleanToggle <http://www.web3d.org/document
>> s/specifications/19775-1/V3.3/Part01/components/utils.html#BooleanToggle
>> >>>
>>
>>
>>                               produces a toggle output event after it
>> receives a set_boolean event.
>>
>>                               Does it also produce a toggle output event
>> after it receives a toggle
>>                               input event (to reset the toggle field
>> value) ?
>>
>>             http://www.web3d.org/x3d/content/X3dTooltips.html#BooleanTog
>> gle <http://www.web3d.org/x3d/content/X3dTooltips.html#BooleanToggle> <
>> http://www.web3d.org/x3d/content/X3dTooltips.html#BooleanToggle <
>> http://www.web3d.org/x3d/content/X3dTooltips.html#BooleanToggle>>
>>                               <http://www.web3d.org/x3d/cont
>> ent/X3dTooltips.html#BooleanToggle <http://www.web3d.org/x3d/cont
>> ent/X3dTooltips.html#BooleanToggle> <http://www.web3d.org/x3d/cont
>> ent/X3dTooltips.html#BooleanToggle <http://www.web3d.org/x3d/cont
>> ent/X3dTooltips.html#BooleanToggle>>>
>>
>>                               does not mention this and the diagram at
>>             http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09-E
>> ventUtilitiesScripting/X3dEventUtilityNodeEventDiagrams.pdf <
>> http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09-
>> EventUtilitiesScripting/X3dEventUtilityNodeEventDiagrams.pdf> <
>> http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09-
>> EventUtilitiesScripting/X3dEventUtilityNodeEventDiagrams.pdf <
>> http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09-
>> EventUtilitiesScripting/X3dEventUtilityNodeEventDiagrams.pdf>>
>>                               <http://x3dgraphics.com/exampl
>> es/X3dForWebAuthors/Chapter09-EventUtilitiesScripting/X3dEve
>> ntUtilityNodeEventDiagrams.pdf <http://x3dgraphics.com/exampl
>> es/X3dForWebAuthors/Chapter09-EventUtilitiesScripting/X3dEve
>> ntUtilityNodeEventDiagrams.pdf> <http://x3dgraphics.com/exampl
>> es/X3dForWebAuthors/Chapter09-EventUtilitiesScripting/X3dEve
>> ntUtilityNodeEventDiagrams.pdf <http://x3dgraphics.com/exampl
>> es/X3dForWebAuthors/Chapter09-EventUtilitiesScripting/X3dEve
>> ntUtilityNodeEventDiagrams.pdf>>>
>>
>>                               also seems silent.
>>
>>                               Not sure if there are examples which reset
>> the internal value of the
>>                               toggle field ?
>>
>>                               Andreas
>>
>>
>>         all the best, Don
>>
>>
>>
>>     all the best, Don
>>     --     Don Brutzman  Naval Postgraduate School, Code USW/Br
>> brutzman at nps.edu <mailto:brutzman at nps.edu>
>>     Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
>> +1.831.656.2149 <tel:%2B1.831.656.2149>
>>     X3D graphics, virtual worlds, navy robotics
>> http://faculty.nps.edu/brutzman <http://faculty.nps.edu/brutzman>
>>
>>
>>
>>
>> --
>> Andreas Plesch
>> Waltham, MA 02453
>>
>
>
> 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
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170924/36a96e7f/attachment-0001.html>


More information about the x3d-public mailing list