[x3d-public] BooleanToggle output

Don Brutzman brutzman at nps.edu
Sat Sep 23 23:57:12 PDT 2017


Thanks for perseverance.  Important.

On 9/23/2017 2:11 PM, Andreas Plesch wrote:
> Just looking at IntegerTrigger http://www.web3d.org/x3d/content/X3dTooltips.html#IntegerTrigger <http://www.web3d.org/x3d/content/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)."

> 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.

> 3) set_boolean field description
> 
> Therefore in the tool tip the set_boolean description should read:
> "If set_boolean input is received, trigger output of integer value."

same response as preceding point, it is consistent.

> 4)  [integerKey] Hint: directly resetting the integerKey field generates a corresponding triggerValue output event.
> I also thought first that reset integerKey would generate a corresponding triggerValue output. But it turns out that all browsers only output a corresponding integerKey output event and not a triggerValue output. I think this behaviour is actually more what the event spec. language suggests and lets authors choose if they want to use triggered output after reset or not.

... OK very good, am agreeing with you on this one.  I was motivated earlier today by prose in Event models about state changes... but posting a change to triggerValue is overzealous if only resetting integerKey state without a corresponding input trigger.

Reverted to "Hint: directly resetting the integerKey field generates a corresponding integerKey output event."

Also adjusted diagram note to match.

> So the hint should become:
> 
> "directly resetting the integerKey field generates a corresponding integerKey output event."

Yes.

> Looking into TimeTrigger next.

same as point (2), only honoring true events for simplicity and logical clarity.

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.

> -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-EventUtilitiesScripting/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/documents/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/documents/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/documents/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/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/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/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/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/documents/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#BooleanToggle <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/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/content/X3dTooltips.html#BooleanToggle>>>
> 
>                               does not mention this and the diagram at
>             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/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/examples/X3dForWebAuthors/Chapter09-EventUtilitiesScripting/X3dEventUtilityNodeEventDiagrams.pdf <http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09-EventUtilitiesScripting/X3dEventUtilityNodeEventDiagrams.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/brutzman



More information about the x3d-public mailing list