[x3d-public] BooleanFilter inputFalse output value true or false ?

[Andreas Plesch]

Here is a BooleanFilter implementation for x3dom:

https://github.com/andreasplesch/x3dom/blob/EventUtilities/src/nodes/EventUtilities/BooleanFilter.js

This is a fairly simple node to implement. It extends ChildNode directly,
and only implements the fieldChanged 'lifecycle' method. The postMessage
method produces output events.

It took a bit longer to put together a good test scene which exercises the
filter node fields:

https://x3dom-booleanfilter.glitch.me/

This is pretty standard x3d except for use of the x3dom 'render' SFBool
field which can be used to control rendering of a shape node. Is there a
standard conforming way to use a SFBool event to control rendering ?
'render' is certainly convenient.

An example scene like this may be useful to add to the web3d x3d example
archive.

The example uses TouchSensor as a source for boolean events but I keep
thinking about a non-interactive test without a script node. Perhaps
something with TimeSensor ?

I will submit this node as a PR to the x3dom github repository if there are
no obvious hickups.

Any feedback or comments welcome,

-Andreas






On Mon, Sep 4, 2017 at 3:14 PM, Andreas Plesch <andreasplesch at gmail.com>
wrote:

> freewrl also uses inputFalse with a false value but not without a
> dedicated comment:
>
> https://sourceforge.net/p/freewrl/git/ci/master/tree/freex3d
> /src/lib/scenegraph/Component_EventUtils.c#l45
> https://sourceforge.net/p/freewrl/git/ci/master/tree/freex3d
> /codegen/VRMLNodes.pm#l2644
>
> -Andreas
>
>
> On Mon, Sep 4, 2017 at 9:49 AM, Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> I agree, inputFalse should produce false since BooleanFilter is designed
>> as a pass through filter. It is just a matter of the spec. language being a
>> bit too concise.
>> 'based on the Boolean value received' mostly refers to which of the
>> possible output event should be generated, inputTrue or inputFalse. But the
>> phrase is ambiguous with regards to the associated values.
>>
>> What about
>>
>> 'When the set_boolean event is received, the BooleanFilter node generates
>> two events: either inputTrue with a value of true or inputFalse with a
>> value of false, depending on the Boolean value received;...' ?
>>
>> But since the question was raised, let's explore the design to see if is
>> possible to decide which behaviour may be more useful. How may
>> BooleanFilter be used ?
>> Sensors are probably the main sources of boolean outputs. Filtering a
>> sensor output makes it possible to selectively choose separate responses to
>> the output. It is a kind of branching. This branching is achieved by having
>> either inputTrue or inputFalse events but is independent of their values.
>> Considering a 'false' output value as something positive (true) may often
>> be appropriate but completely depends on the scene architecture. So I
>> follow Don's reasoning that it is best to keep it simple by forwarding the
>> input values.
>>
>> -Andreas
>>
>>
>> On Mon, Sep 4, 2017 at 12:39 AM, Don Brutzman <brutzman at nps.edu> wrote:
>>
>>> great question, thanks Andreas.  let's explore.
>>>
>>> On 9/3/2017 8:18 PM, Andreas Plesch wrote:
>>>
>>>> Looking at BooleanFilter (http://www.web3d.org/document
>>>> s/specifications/19775-1/V3.3/Part01/components/utils.html#B
>>>> ooleanFilter) I could not decide what the boolean output values for
>>>> the inputTrue and inputFalse events were.
>>>>
>>>> The spec. just has:
>>>>
>>>> 'BooleanFilter node generates two events: either inputTrue or
>>>> inputFalse, based on the Boolean value received; ...'
>>>>
>>>
>>> full prose:
>>>
>>> "BooleanFilter filters Boolean events, allowing for selective routing of
>>> TRUE or FALSE values and negation.
>>>
>>> When the set_boolean event is received, the BooleanFilter node generates
>>> two events: either inputTrue or inputFalse, based on the Boolean value
>>> received; and inputNegate, which contains the negation of the value
>>> received."
>>>
>>> Especially, the value for inputFalse is difficult to determine. I
>>>> actually was leaning towards the value true for inputFalse when the
>>>> received value is false since it is then true that the input value was
>>>> false.
>>>>
>>>
>>> yes the semantics of the spec phrasing is a bit ambiguous.  we should
>>> get more explicit.
>>>
>>> However, the tooltips here
>>>>
>>>> http://www.web3d.org/x3d/content/X3dTooltips.html#BooleanFilter
>>>>
>>>> claim that the inputFalse value should be false instead, passing on the
>>>> value of the input.
>>>>
>>>
>>> reviewing now, i think that is correct, since it is closely following
>>> the initial spec sentence clause "based on the Boolean value received".
>>>
>>> of additional note is the figure that was reviewed by a number of
>>> people, linked in tooltips:
>>>
>>>         Hint: X3D Event-Utility Nodes, Field Event Diagrams
>>>         http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09-E
>>> ventUtilitiesScripting/X3dEventUtilityNodeEventDiagrams.pdf
>>>
>>> attached is image excerpt showing BooleanFilter inputs/outputs, plus
>>> copy of diagram for convenience.
>>>
>>> Is that really what other x3d browsers do ?
>>>>
>>>
>>> yes it is good to check.  perhaps a more explicit test scene will help
>>> also.
>>>
>>> I think that [inputFalse passing FALSE] is indeed the right approach,
>>> for a few reasons:
>>>
>>> a. the node name BooleanFilter indicates a filtering action, i.e. only
>>> passing some things through, rather than changing them
>>>
>>> b. if an author filters an event stream to detect a FALSE event, it is
>>> detected and usable as such, rather than requiring yet-another negation.
>>>
>>> c. precise logic like this leads to more succinct and less error-prone
>>> event chains.
>>>
>>> Checking cobweb it appears that it rather uses inputFalse=true here:
>>>>
>>>> https://github.com/create3000/cobweb/blob/master/src/cobweb/
>>>> Components/EventUtilities/BooleanFilter.js#L110
>>>>
>>>
>>> good check, we need to make them all consistent.
>>>
>>> It looks like clarification is needed,
>>>>
>>>
>>> yes, further comment welcome.  once we're clear, let's
>>>
>>> d. have an explicit test scene,
>>> e. have specific spec prose and perhap add the diagrams,
>>> f. add an inputFalse Warning to ensure no ambiguity remains.
>>>
>>> -Andreas
>>>>
>>>
>>> thanks!
>>>
>>> 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
>>>
>>
>>
>>
>> --
>> Andreas Plesch
>> Waltham, MA 02453
>>
>
>
>
> --
> 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/20170915/9e4c616b/attachment.html>